Snipe-IT has an Improper Privilege Management issueGHSA-j5g3-42wp-gqm3
MEDIUMFix: grokability/snipe-it@1cff2d6GHSA-j5g3-42wp-gqm3 is a medium-severity (CVSS 6.5) Improper Privilege Management vulnerability in snipe/snipe-it. A fix is available for snipe/snipe-it — see the affected versions and patch details below.
Exploitation Status
No confirmed exploitation observed yet
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-j5g3-42wp-gqm3.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-j5g3-42wp-gqm3 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 385,738 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
snipe/snipe-itReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
Impact
The update() method in UsersController passes the permission request field unconditionally to NormalizePermissionsPayloadAction, which returns an empty array when the field is absent. The result is passed to PreserveUnauthorizedPrivilegedPermissionsAction, which selectively restores only the superuser key (when the editor is not a superuser) and the admin key (when the editor is neither admin nor superuser). All other permissions — including the admin flag itself when the editing user is an admin — are discarded and $user->permissions is overwritten with the sparse result.
The canEditAuthFields gate permits admins to update other non-superuser accounts (including other admins). When an admin sends a PUT /users/{id} request for another admin without including the permission field, the target's admin flag and all granular permissions are permanently destroyed. The target loses administrative access entirely with no error, warning, or out-of-band notification.
A secondary, lower-impact path exists for non-admin users holding the users.edit permission: they may target regular (non-admin, non-superuser) accounts and wipe all granular permissions in the same way.
Patches
Patched in https://github.com/grokability/snipe-it/commit/1cff2d67aabd00ee51d864c1d7fb717494c1d6ad
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | snipe/snipe-it | all versions | 8.6.0composer require snipe/snipe-it:^8.6.0 |
Affected Products
snipe-itsnipeitappDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for snipe/snipe-it, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update snipe/snipe-it to 8.6.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-j5g3-42wp-gqm3 is resolved across your whole dependency graph.
Workarounds
Close the privilege gap rather than the entry point: audit which accounts, roles and service identities can reach the affected operation, drop the component to the least privilege it actually needs, and review file and directory permissions created by earlier installs — a default left in place is what makes this reachable.
Frequently Asked Questions
Is GHSA-j5g3-42wp-gqm3 in your dependencies?
Find it across Packagist, including transitive dependencies.