CVE-2026-48507 - Snipe-IT bulk user lockout privilege escalation

Snipe-IT before 8.6.0 let a non-admin user with only the granular users.edit permission bulk edit security-sensitive account fields, specifically activated and ldap_import. That allowed the user to disable other accounts’ login capability and password-reset behavior, including locking administrators out of the instance.

This is an authorization failure in bulk user administration, not just a UI misconfiguration.

When to use it

  • A repository deploys, packages, forks, or configures Snipe-IT before 8.6.0.
  • Non-admin roles can hold users.edit or equivalent granular user-management permission.
  • Bulk user edit routes, APIs, jobs, plugins, or forks can modify activation, directory, reset, role, or other lockout-capable fields.
  • You need a bounded PR or triage note that upgrades Snipe-IT and proves backend authorization, not just UI hiding.

Inputs

  • Composer files, package/image manifests, deployment manifests, SBOMs, generated reports, plugins, forks, and role/permission configuration.
  • Bulk user edit controllers, request validators, policies, services, jobs, and API routes.
  • Role assignments for users.edit, privileged account inventory, audit logs, and recovery workflow ownership.
  • Available tests, build, image build, deployment render, SBOM, and dependency scan commands.

Affected versions

Package Vulnerable versions Fixed versions
snipe/snipe-it <8.6.0 8.6.0

Indicator-of-exposure

  • The repository deploys Snipe-IT <8.6.0.
  • Non-admin roles can hold users.edit or equivalent granular user-management permissions.
  • Bulk user edit APIs or admin pages are exposed to those roles.
  • Bulk edit handlers accept or apply activated, ldap_import, or similar security-sensitive fields without a stronger admin permission check.

Quick checks:

rg -n "users\.edit|bulk.*user|activated|ldap_import|permission check|authorize" .
composer show snipe/snipe-it

Windows:

rg -n "users\.edit|bulk.*user|activated|ldap_import|permission check|authorize" .
composer show snipe/snipe-it

Remediation strategy

  • Upgrade Snipe-IT to 8.6.0+.
  • Enforce stronger authorization for any bulk edit of login, reset, directory, role, or activation-related fields.
  • Prefer allow-listing safe bulk-editable fields rather than blocking a short deny-list.
  • Add tests proving users.edit alone cannot disable accounts or change password-reset relevant flags.

The prompt

Model context: this prompt was generated by GPT 5.5 Extra High reasoning.

You are remediating CVE-2026-48507 / GHSA-6f75-x745-xcpr in Snipe-IT. Bulk user
editing lets a low-privilege operator with only `users.edit` modify
security-sensitive account fields and lock out admins. Produce exactly one
output:

- A reviewer-ready PR/change request that upgrades Snipe-IT, hardens bulk user
  authorization, adds regression tests, and documents recovery actions, or
- TRIAGE.md if this repository does not control an affected Snipe-IT runtime.

## Rules

- Scope only CVE-2026-48507 and directly related bulk-user authorization.
- Do not disable real user accounts or password-reset flows in shared
  environments.
- Treat user identities, role mappings, MFA status, reset settings, and audit
  logs as sensitive.
- Do not rely on front-end hiding of fields while backend bulk handlers still
  accept them.
- Do not auto-merge.

## Steps

1. Inventory every Snipe-IT package, image, manifest, and deployment controlled
   by this repository.
2. Confirm whether any deployment runs `<8.6.0`.
3. Trace bulk user edit controllers, requests, service classes, and policies to
   identify which fields `users.edit` can currently modify.
4. Search for adjacent user-management flows that apply security-sensitive
   fields without full admin authorization.
5. If the repository does not control the affected runtime, stop with
   `TRIAGE.md` naming the owning team, vulnerable version, and required fixed
   version `8.6.0+`.
6. Upgrade to `8.6.0+` and refresh lockfiles, images, manifests, SBOMs, and
   deployment documentation.
7. Restrict bulk-editable user fields with a server-side allow-list and require
   stronger admin permission checks for activation, directory, reset, or other
   lockout-capable fields.
8. Add regression tests proving `users.edit` alone cannot toggle `activated`,
   `ldap_import`, or similar security-sensitive flags for other users.
9. Add a PR body section named `CVE-2026-48507 operator actions` covering:
   - versions before and after;
   - which roles previously held `users.edit`;
   - whether any locked accounts need review or recovery;
   - adjacent user-management flows reviewed;
   - validation that passed.
10. Run available validation: tests, build, image build, deployment render, and
    dependency/security scans.
11. Use PR title:
    `fix(sec): block Snipe-IT bulk user lockout privilege escalation`.

## Stop conditions

- No affected Snipe-IT runtime is controlled by this repository.
- Recovery of previously impacted accounts requires live operator intervention.
- Multiple plugins or forks override bulk user editing and their ownership is
  outside this repository; capture that in `TRIAGE.md`.
- Validation fails for unrelated pre-existing reasons; document those failures.

Verification - what the reviewer looks for

  • No controlled Snipe-IT deployment resolves <8.6.0.
  • Roles with only users.edit cannot modify activation or password-reset relevant flags in bulk operations.
  • Regression tests cover lockout attempts against privileged accounts.
  • Operator notes cover account recovery review if the system was previously exposed.

Output contract

  • Reviewer-ready PR upgrading controlled Snipe-IT deployments to 8.6.0+ and refreshing lockfiles, images, manifests, SBOMs, and docs.
  • Server-side allow-list or authorization checks for bulk-editable fields, with tests proving users.edit alone cannot change lockout-capable account flags.
  • Operator notes for roles reviewed, locked-account recovery, adjacent flows, plugins/forks, and validation commands.
  • TRIAGE.md when the affected runtime, plugins, or recovery workflow are not controlled by this repository.

Watch for

  • Blocking activated and ldap_import but leaving similar high-impact fields bulk-editable.
  • Fixing the UI action while API or job-based bulk update routes remain open.
  • Custom plugins or forks that reintroduce the old bulk-edit behavior.

References