How We Found CVE-2026-48507 in Snipe-IT

Here is the story behind CVE-2026-48507, a vulnerability we recently reported and published in Snipe-IT. It is a small permissions oversight with an outsized blast radius, and it is a good reminder of where access control tends to break in real applications.

A program of reading other people's code

We run an ongoing effort to read the source of widely used open-source software and report what we find through coordinated disclosure. It is the most honest proof of skill a penetration testing firm can offer. Anyone can list certifications. A CVE with your name on it in the public record is harder to argue with. CVE-2026-48507 came out of that program, and it will not be the last.

Why Snipe-IT

Snipe-IT is a popular open-source IT asset management platform. Teams use it to track hardware, licenses, and the people those assets belong to. What makes it interesting to look at is its permission model. It is granular by design, so you can hand a help-desk user a narrow slice of access, like the ability to edit user records, without making them an administrator.

Granular permission systems are exactly where authorization bugs hide. The more finely you slice access, the more places a single code path can forget to ask whether the current user is really allowed to do the specific thing they are about to do.

What we found

Snipe-IT lets you edit several users at once through a bulk editing feature. The normal, one-at-a-time edit screen is careful about which fields a low-privilege user can touch. The bulk path was not.

A user holding only the users.edit permission could use bulk editing to change fields that should have been off limits. Two of them matter a lot:

• activated, which decides whether an account can log in at all.
• ldap_import, which changes how password resets behave.

Put those together and a low-privilege user has a clean path to a full lockout. Select the administrator accounts, bulk-edit activated to off, and the people who run the system can no longer sign in. The application is still up. The admins are just locked out of their own instance, and getting back in means going to the database or to vendor support. At the standards level this is CWE-863, Incorrect Authorization: the app checked that you could edit users, but not that you were allowed to change that field.

Coordinated disclosure

We reported the issue privately, and the Snipe-IT maintainers handled it the way the process should work. They confirmed the bug, assigned CVE-2026-48507, shipped the fix in version 8.6.0, and credited the report. The advisory went public on May 27, 2026, and the CVE record followed on June 8. Clean, professional, and credit where it is due.

Why a scanner would have missed it

This is the part worth sitting with if you buy security testing rather than perform it.

A vulnerability scanner matches what it sees against a database of known issues and version signatures. It is good at telling you that you are running an outdated, known-vulnerable build. It has no idea what your permission model is supposed to mean. It cannot reason that "can edit users" should not also mean "can disable every administrator." That is business logic, and logic is invisible to pattern matching.

Bulk operations make it worse. The careful authorization check on the normal edit path is easy to skip on the bulk path, because the bulk path is a different piece of code that looks like it is doing the same safe thing. The only way to catch this is for a human to test the authorization model by hand, with a low-privilege account, and watch what it is actually allowed to do. Broken access control is consistently one of the most common and most damaging categories of finding in the work we do, and almost none of it is caught by a tool.

If you run Snipe-IT

Upgrade to 8.6.0. Until you do, limit who holds the users.edit permission and keep an eye out for unexpected changes to the activated and ldap_import flags on your admin accounts. The full advisory has the version details and CVSS breakdown.