Advisory · CVE-2026-116199
Snipe-IT Google SSO signs deactivated users back in
Snipe-IT before 8.6.3 contains an authentication bypass in the Google SSO callback, which logs in the user whose username matches the Google account email without enforcing the activated flag, so deactivated users with email-shaped usernames and still-live Google identities regain sessions at their original permission level, including admin. CVSS 3.1 8.1.
- Vendor
- Snipe-IT
- Product
- Snipe-IT
- Identifier / CWE
- CVE-2026-116199
CWE-285 - Action timing
- Immediate
Explain it like I’m five
Snipe-IT checks that an account is still active on every sign-in door except the Google one, so a person who was switched off can walk back in through Google if their Google account still works.
- 01User is deactivated
An administrator deactivates a user in Snipe-IT, but their Google Workspace identity remains live.
- 02Conditions line up
Google SSO is enabled and the Snipe-IT username is the person email address, so the Google callback lookup finds the account.
- 03Activated flag skipped
The Google callback logs the matched user in without checking the activated flag that every other authentication path enforces.
- 04Old permissions return
The deactivated user holds an authenticated session at their original permission level, including admin where that applied.
What happened
Snipe-IT disclosed CVE-2026-116199 in its GitHub security advisory. The Google authentication callback looked up the local user whose username matches the Google account email and logged that user in if a row was returned. Every other authentication path in Snipe-IT (SAML, LDAP, REMOTE_USER, and local password) enforced the activated flag in its lookup; the Google path did not. A deactivated user could therefore sign in via Google and obtain an authenticated session at their original permission level.
The vendor advisory scopes the affected versions to 8.6.2 and earlier and states the issue is patched in 8.6.3 and later, where the controller now rejects users who are not activated. It also states the preconditions plainly: Google SSO enabled, a username that matches the Google email, and a Google identity that is still live; default installations using the firstname.lastname username format were not affected, because the lookup returned no match.
What to do
- Inventory Snipe-IT instances with Google SSO enabled and note which use email addresses as usernames.
- Upgrade affected instances to Snipe-IT 8.6.3 or later using the project release guidance.
- List deactivated accounts whose usernames are email-shaped and check Google sign-in and session records for any of them after their deactivation date.
- Revoke active sessions for any deactivated account that signed in through Google, and review actions taken in those sessions.
- Align offboarding so the Google Workspace identity and the Snipe-IT account are disabled together, not in sequence with a gap.
Management note
Offboarding is only as strong as its weakest sign-in path. If deactivation is your control for leavers, every SSO route has to honor it; audit the gap between Snipe-IT deactivation and identity-provider revocation, not just the patch.