Summary
Snipe-IT contains an authentication bypass in its Google SSO callback handling that can authenticate a user based on a matching Google account email without checking whether the local account remains activated. If a deactivated account has an email-shaped username and its Google identity is still usable, the user may regain access with the account's original permissions, including administrative privileges.
Snipe-IT contains an authentication bypass in its Google SSO callback handling that can authenticate a user based on a matching Google account email without checking whether the local account remains activated. If a deactivated account has an email-shaped username and its Google identity is still usable, the user may regain access with the account's original permissions, including administrative privileges.
Affected context
The issue occurs in Snipe-IT deployments that use Google SSO and process callbacks through GoogleAuthController::handleGoogleCallback. It is relevant when a local account has been deactivated but its username matches the email address of an active Google identity. In that condition, the callback logic may establish a session without enforcing the local account's activation state.
The issue occurs in Snipe-IT deployments that use Google SSO and process callbacks through GoogleAuthController::handleGoogleCallback. It is relevant when a local account has been deactivated but its username matches the email address of an active Google identity. In that condition, the callback logic may establish a session without enforcing the local account's activation state.
Exploit preconditions
- Attack surface: Google SSO authentication callback
- Required access: Control of, or access to, a Google identity whose email matches the target local username
- Trigger point: Successful processing of the Google authentication callback
- Account state: The matching Snipe-IT account is deactivated but retains its prior permissions
- Why exploitation is possible: The callback authenticates the matching account without consistently enforcing its activated status
- Attack surface: Google SSO authentication callback
- Required access: Control of, or access to, a Google identity whose email matches the target local username
- Trigger point: Successful processing of the Google authentication callback
- Account state: The matching Snipe-IT account is deactivated but retains its prior permissions
- Why exploitation is possible: The callback authenticates the matching account without consistently enforcing its activated status
Why this happens
The underlying flaw is an authorization and account-state validation failure. The SSO callback uses an external identity-to-username match as sufficient evidence to establish a local session, while omitting a required check that the corresponding local account is active. This maps to CWE-285: Improper Authorization, because access-control decisions do not fully enforce the account's current authorization state before granting access.
The underlying flaw is an authorization and account-state validation failure. The SSO callback uses an external identity-to-username match as sufficient evidence to establish a local session, while omitting a required check that the corresponding local account is active. This maps to CWE-285: Improper Authorization, because access-control decisions do not fully enforce the account's current authorization state before granting access.
Potential impact
- A deactivated user may regain access to the application
- An attacker with control of the matching Google identity could inherit the local account's permissions
- Administrative accounts could be reactivated in practice through session establishment
- Sensitive assets, tickets, users, or configuration data could be accessed or modified
- Security controls based on local account deactivation could be bypassed
- A deactivated user may regain access to the application
- An attacker with control of the matching Google identity could inherit the local account's permissions
- Administrative accounts could be reactivated in practice through session establishment
- Sensitive assets, tickets, users, or configuration data could be accessed or modified
- Security controls based on local account deactivation could be bypassed
General mitigation guidance
Mitigation generally focuses on treating local account state as a mandatory authorization condition for every SSO login.
Common defensive patterns include:
- Require the matching local account to be active before creating or restoring a session
- Apply authorization and account-status checks after external identity verification and before session issuance
- Use explicit, trusted identity mappings rather than relying solely on username or email equality
- Revalidate account status during session refresh and sensitive authorization decisions
- Apply least privilege to administrative roles and separate SSO identity management from local authorization
- Record and alert on SSO logins involving inactive, disabled, or recently changed accounts
Mitigation generally focuses on treating local account state as a mandatory authorization condition for every SSO login.
Common defensive patterns include:
- Require the matching local account to be active before creating or restoring a session
- Apply authorization and account-status checks after external identity verification and before session issuance
- Use explicit, trusted identity mappings rather than relying solely on username or email equality
- Revalidate account status during session refresh and sensitive authorization decisions
- Apply least privilege to administrative roles and separate SSO identity management from local authorization
- Record and alert on SSO logins involving inactive, disabled, or recently changed accounts
How teams detect issues like this
Organizations can assess for this class of issue through:
- Static analysis and code review checks for authentication callbacks that issue sessions before local account-state validation
- Review of identity-mapping logic that treats email or username equality as sufficient authorization
- Tests confirming that disabled, suspended, or deactivated accounts cannot authenticate through any configured identity provider
- Integration tests covering account deactivation followed by SSO login and session refresh
- Monitoring for successful SSO sessions associated with inactive accounts or unexpected administrative identities
- Policy enforcement requiring centralized checks for account status before session creation
Automated security review tools may help identify missing authorization checks, but behavioral tests are important because the issue depends on the interaction between external identity validation and local account state.
Organizations can assess for this class of issue through:
- Static analysis and code review checks for authentication callbacks that issue sessions before local account-state validation
- Review of identity-mapping logic that treats email or username equality as sufficient authorization
- Tests confirming that disabled, suspended, or deactivated accounts cannot authenticate through any configured identity provider
- Integration tests covering account deactivation followed by SSO login and session refresh
- Monitoring for successful SSO sessions associated with inactive accounts or unexpected administrative identities
- Policy enforcement requiring centralized checks for account status before session creation
Automated security review tools may help identify missing authorization checks, but behavioral tests are important because the issue depends on the interaction between external identity validation and local account state.
