CVE-2026-116199: 
Snipe-IT vulnerability analysis and mitigation

CVE-2026-116199 is an authentication bypass vulnerability in Snipe-IT's Google SSO login flow, specifically in GoogleAuthController::handleGoogleCallback. The flaw allows deactivated users with email-shaped usernames and still-live Google identities to sign in via Google SSO and regain sessions at their original permission level, including administrative access. It affects all Snipe-IT versions before 8.6.3, developed by Grokability, Inc. The vulnerability was published on October 25, 2026, with a patch released in version 8.6.3. It carries a CVSS v3.1 score of 8.1 (High) and a CVSS v4.0 score of 9.2 (Critical) (GitHub Advisory, Snipe-IT Advisory).

The root cause is CWE-285 (Improper Authorization) and CWE-287 (Improper Authentication). The vulnerable code in app/Http/Controllers/GoogleAuthController.php::handleGoogleCallback performed a user lookup via User::where('username', $socialUser->getEmail())->first() and immediately called Auth::login($user, true) if a matching record was found, without checking the activated flag. Every other authentication path in Snipe-IT (SAML, LDAP, REMOTE_USER, local-password) enforced activated = 1 in its query, but the Google SSO path did not. Exploitation requires three preconditions: Google SSO must be enabled on the instance, the target user account must have an email-shaped username (matching their Google account email), and the user must have been deactivated in Snipe-IT while their Google Workspace identity remains active. Notably, default Snipe-IT installations using the firstname.lastname username format are not affected because the username/email mismatch causes the lookup to return NULL (Snipe-IT Advisory).

A deactivated user — including former administrators — can exploit this vulnerability to silently regain a fully authenticated session in Snipe-IT at their original permission level without any password or MFA challenge. If the deactivated account held administrative privileges, the attacker gains full control over the IT asset management platform, including access to sensitive asset inventory, user data, license keys, and configuration details. The offboarding window between deactivating a user in Snipe-IT and revoking their Google Workspace identity constitutes the effective attack window, creating a persistent risk during routine employee offboarding processes (Snipe-IT Advisory, GitHub Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the time of disclosure (GitHub Advisory). The EPSS score is 0.0, reflecting low current exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported. Despite the absence of a public PoC, the attack mechanism is straightforward for any deactivated user who retains access to their associated Google identity, requiring no special tooling beyond a standard browser.

1. Identify a target instance: Locate a Snipe-IT deployment with Google SSO enabled (typically accessible via a public or internal URL with a "Login with Google" option on the login page).
2. Identify a deactivated account: Determine whether a previously deactivated Snipe-IT user account has an email-shaped username (e.g., john.doe@company.com) that matches a still-active Google Workspace identity — this may be known to a former employee or insider.
3. Initiate Google SSO flow: Navigate to the Snipe-IT instance and click "Login with Google" to trigger the OAuth2 flow, which redirects to Google's authentication endpoint.
4. Authenticate with the Google identity: Complete Google authentication using the credentials of the deactivated account's associated Google identity (e.g., the former employee's Google account, if not yet revoked).
5. Bypass activation check: Upon callback to GoogleAuthController::handleGoogleCallback, the application matches the Google email to the deactivated username and calls Auth::login($user, true) without verifying activated = 1, establishing a valid authenticated session.
6. Access at original privilege level: The attacker is now logged in with the deactivated account's original permissions, including admin access if applicable, and can browse assets, modify records, or exfiltrate data (Snipe-IT Advisory).

• Logs: Snipe-IT application logs showing successful authentication events (Auth::login) for user accounts with activated = 0 status; Google SSO callback requests (/auth/google/callback) followed by session creation for accounts that should be inactive.
• Network: HTTP GET/POST requests to the Snipe-IT Google OAuth callback endpoint (e.g., /auth/google/callback) from unexpected IP addresses or geolocations associated with former employees.
• Application Behavior: Active sessions in Snipe-IT for user accounts that are marked as deactivated in the admin user management panel; unexpected logins appearing in Snipe-IT's audit log for deactivated accounts.
• Google Workspace: Google Workspace sign-in logs showing OAuth token grants to the Snipe-IT application for accounts that have been offboarded or deactivated in Snipe-IT (Snipe-IT Advisory).

Upgrade Snipe-IT to version 8.6.3 or later, which fixes the issue in commit 5fea2fadc0 by adding an activated check after the user lookup — redirecting with auth/message.account_not_activated instead of calling Auth::login for deactivated accounts (Snipe-IT Advisory). As an immediate workaround prior to patching, organizations should promptly revoke Google Workspace identities for any deactivated Snipe-IT users, eliminating the attack window. Additionally, review all deactivated accounts with email-shaped usernames and administrative privileges, and consider disabling Google SSO temporarily if immediate patching is not feasible. Monitor Google SSO authentication logs for login attempts by deactivated accounts.

The vulnerability was reported by researcher builtbybrayden and remediated by the Snipe-IT development team (snipe), as credited in the official GitHub Security Advisory (Snipe-IT Advisory). VulnCheck assigned and disclosed the CVE identifier alongside a dedicated advisory (GitHub Advisory). No significant broader media coverage or notable social media commentary beyond standard CVE tracking feeds has been observed at this time.