CVE-2026-48507: Admin Lockout in Snipe-IT via Bulk User Editing
| CVE | CVE-2026-48507 |
|---|---|
| Advisory | GHSA-6f75-x745-xcpr |
| Severity | High CVSS v3.1 base score 7.1 |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H |
| Weakness | CWE-863 — Incorrect Authorization |
| Product | Snipe-IT (open-source IT asset management, by Grokability) |
| Affected | All versions before 8.6.0 |
| Fixed in | 8.6.0 |
| Reported by | Louis Sanchez — Voke Cyber |
| Disclosure | Coordinated. Advisory published May 27, 2026; CVE record published June 8, 2026. |
Summary
A Snipe-IT user with only the granular users.edit permission, not an administrator, could use bulk user editing to flip protected account flags, including the one that controls whether a user can log in. By turning that flag off on the admin accounts, a low-privilege user could lock every administrator out of the instance.
Voke Cyber found this issue during a review of Snipe-IT and reported it through the project's private vulnerability reporting process. The Snipe-IT maintainers confirmed it, assigned CVE-2026-48507, and shipped the fix in version 8.6.0. This page is our advisory writeup, drawn from the published GHSA and CVE record.
What Snipe-IT is
Snipe-IT is a widely used open-source IT asset management platform. Organizations run it to track hardware, licenses, accessories, and consumables, and to manage the people those assets are assigned to. It ships with a granular permission model, so you can grant a help-desk user the ability to edit user records without making them a full administrator.
That granularity is the point of the system, and it is also where this bug lives.
The vulnerability
This is an incorrect authorization flaw (CWE-863). The permission to edit users was checked. The permission to change security-relevant fields on those users was not.
Snipe-IT's bulk user editing lets you update several user records at once. The problem was that the bulk path did not restrict which fields a low-privilege user could change. A user holding only the users.edit permission could use it to modify two fields that should be reserved for administrators:
- activated — controls whether an account is allowed to log in.
- ldap_import — affects how the account handles password resets.
Set activated to off on every administrator account through a single bulk edit, and those admins can no longer log in. The instance is still running, but nobody with the authority to fix it can get back in. Changing ldap_import on top of that interferes with the normal password-reset path, making recovery slower and messier.
In short, the application confirmed "you are allowed to edit users" and never asked the more important question: "are you allowed to change this particular field on this user?"
Impact
The CVSS v3.1 vector lines up with the behavior: C:N / I:L / A:H.
- No confidentiality impact. This is not about reading data the attacker should not see.
- High availability impact. Locking every administrator out is a denial of service against the people who run the system. Recovery means database-level intervention or vendor support, not a quick click in the UI.
- Low integrity impact. The attacker can tamper with specific account flags, but not arbitrarily rewrite records.
- Privileges required: low (PR:L). The attacker needs an authenticated account that holds the users.edit permission. That is a routine help-desk or operator grant, which makes this an insider-threat and compromised-account problem, not a remote-anonymous one.
The maintainers rated it High, with a CVSS base score of 7.1.
Affected and fixed versions
- Affected: Snipe-IT, all versions before 8.6.0.
- Fixed: 8.6.0.
What to do
- Upgrade to Snipe-IT 8.6.0. That is the fix and the durable remediation.
- Until you upgrade, tighten the users.edit grant. Treat it as a privileged capability and limit who holds it.
- Watch for unexpected changes to the activated and ldap_import flags on administrator accounts, and keep a known-good admin recovery path in case you need it.
Disclosure timeline
- May 21, 2026 — CVE-2026-48507 reserved.
- May 27, 2026 — GitHub Security Advisory GHSA-6f75-x745-xcpr published; the fix shipped in Snipe-IT 8.6.0.
- June 8, 2026 — CVE-2026-48507 record published on cve.org.
Coordinated disclosure throughout. Credit to the Snipe-IT maintainers for a clean process and for crediting the report.
Why it matters
Granular permissions are good security design, but they create a quiet assumption: that every code path enforces them the same way. Bulk operations are where that assumption tends to break. The per-field authorization check that guards the normal edit screen often does not get repeated on the bulk edit path, and a permission that looks harmless on paper ("can edit users") turns into "can disable every admin."
A scanner cannot reason about which fields a role should be allowed to touch. That takes a human testing the authorization model by hand. Broken access control is consistently one of the most common and most damaging categories of finding in the work we do, and this is a textbook example.
For the story behind this finding, read How we found CVE-2026-48507.
References
- GitHub Security Advisory: GHSA-6f75-x745-xcpr
- CVE Record: CVE-2026-48507 (cve.org)
- NVD: CVE-2026-48507 (NVD)
- Snipe-IT project & releases: github.com/grokability/snipe-it
Found and reported by Louis Sanchez, Founder & Principal Security Consultant at Voke Cyber (OSCP, OSWA, CISSP, CCSK).
We find the bugs tools miss
Authorization flaws like this do not show up in automated scans. They take a human testing the logic by hand. That is how we test for our clients across the Charlotte, NC area and nationwide.
Get a Quote