Skip to main content
CVE-2026-86760VulnerabilityPublished 09/09/2026Updated 09/14/2026

CVE-2026-86760: Incorrect Authorization in grokability snipe-it

Affects grokability snipe-itSource CVE Database V5

0

Not known to be exploited · CVSS 5.3 Medium · fixed in 8.7.0 : update grokability snipe-it when convenient.

Data as of 10/25/2026, 04:40:14 UTC

CVSS 4.0 base score
5.3Medium
How severe the flaw is on the 0–10 CVSS scale.
Exploitation

Not in CISA KEV, no exploitation reported

EPSS
0.3% chance of exploitation in 30 days – higher than 31% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in 8.7.0
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N

What to do

Affected software

ProductAffectedFixed in
grokabilitysnipe-itAffected
  • >=8.2.0 <8.7.0
Fixed in
  • 8.7.0
GitHubgrokability/snipe-itpkg:github/grokability/snipe-itOther threatsAffected
  • =8.2.0
  • <8.7.0
Fixed in
  • 8.7.0

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

Upgrade Snipe-IT to version 8.7.0 or later, where this authorization flaw is fixed. Until then, restrict users.edit permissions carefully to trusted users only. No other mitigations are indicated by the vendor advisory.

Description

Snipe-IT versions 8.2.0 through 8.6.x (fixed in 8.7.0) contain an incorrect authorization flaw in app/Http/Controllers/Users/UsersController::update(). The single-user edit route assigned the activated field from the request payload before evaluating the canEditAuthFields authorization gate, so an authenticated non-admin user holding the users.edit permission in the target's company scope can submit a full valid PUT request to /users/{id} and toggle the activated flag on any user, including admin and superuser accounts. Deactivating an admin locks that account out of the application until another admin or superuser re-enables it. Only the activated field is affected; username, email, password and permissions remain protected by the gate, no data is disclosed, and the API (Api\UsersController::update) and bulk-edit paths are not affected.

Impact

An attacker with users.edit permission but without admin rights can deactivate any user account, including administrators and superusers, effectively locking them out of the application. This could disrupt administrative control but does not expose or modify sensitive data such as usernames, emails, passwords, or permissions. The vulnerability does not affect the API or bulk-edit functionality.

References

Community reviews

Loading reviews…