CVE-2026-86770 Overview
Snipe-IT versions before 8.7.0 contain an authentication bypass vulnerability in the SAML login path. The application fails to enforce case-sensitive and accent-sensitive username matching during federated authentication. Attackers who can register accounts at a configured Identity Provider (IdP) can create usernames that differ only in case or diacritics from a victim account. The default MySQL utf8mb4_unicode_ci collation treats these variants as equivalent, allowing the attacker to authenticate as the victim. The flaw also affects LDAP and OAuth login flows that rely on the same username lookup logic. This issue is tracked under CWE-178: Improper Handling of Case Sensitivity.
Critical Impact
Attackers with the ability to register IdP accounts can take over arbitrary Snipe-IT accounts, including administrator accounts, through SAML, LDAP, or OAuth federated login.
Affected Products
- Snipe-IT versions prior to 8.7.0
- Snipe-IT deployments using SAML single sign-on
- Snipe-IT deployments using LDAP or OAuth with the default utf8mb4_unicode_ci MySQL collation
Discovery Timeline
- 2026-09-09 - CVE-2026-86770 published to NVD
- 2026-09-09 - Last updated in NVD database
Technical Details for CVE-2026-86770
Vulnerability Analysis
Snipe-IT resolves incoming federated identities to local user records by querying the users table on the username column. When MySQL is configured with the default utf8mb4_unicode_ci collation, string comparisons are case-insensitive and accent-insensitive. The application layer does not perform an additional binary comparison to confirm the exact byte sequence of the incoming SAML NameID or asserted username attribute.
An attacker who registers a username such as Admin, admín, or ADMIN at the configured IdP can therefore be matched to a local Snipe-IT record for admin. Snipe-IT then issues an authenticated session bound to the victim account. Because Snipe-IT manages IT asset inventories, hardware assignments, license keys, and often integrates with procurement systems, account takeover can expose sensitive organizational data and manipulate asset records.
Root Cause
The root cause is a mismatch between application-level trust assumptions and the underlying database collation. The federated authentication handler treats a successful username lookup as proof of identity, but the lookup itself is not case- or accent-sensitive. No canonicalization or binary comparison is applied to the asserted username before session issuance.
Attack Vector
Exploitation requires the ability to register or control an account at the IdP federated with the target Snipe-IT instance. This is a practical scenario in multi-tenant IdPs, self-service registration environments, or where the IdP allows Unicode in username fields. The attacker registers a username that collates equal to a target Snipe-IT user, completes the SAML flow, and receives an authenticated session for the victim account. No user interaction from the victim is required. See the GitHub Security Advisory GHSA-w3vv-5wxh-xg4h and the VulnCheck advisory for additional technical detail.
Detect Identity Attacks the Moment Authentication Fails
Singularity™ Identity surfaces credential misuse, lateral movement, and privilege escalation in real time, so you can contain the breach before it spreads.
Stop Identity AttacksDetection Methods for CVE-2026-86770
Indicators of Compromise
- Successful SAML, LDAP, or OAuth logins where the asserted username differs in case or diacritics from the resolved local Snipe-IT username.
- New IdP account registrations that share a case-insensitive or accent-insensitive match with an existing Snipe-IT username.
- Snipe-IT audit log entries showing privileged actions from sessions immediately following a federated login by a low-privilege or unfamiliar identity.
Detection Strategies
- Compare the raw asserted username in SAML NameID or OAuth sub/preferred_username claims against the resolved Snipe-IT username field using a binary comparator, and alert on mismatches.
- Query the Snipe-IT users table for records that collate equal but differ byte-for-byte using WHERE username = 'target' COLLATE utf8mb4_bin variants to identify potential collision candidates.
- Correlate IdP account creation events with subsequent Snipe-IT logins that grant elevated privileges.
Monitoring Recommendations
- Forward Snipe-IT authentication and audit logs to a centralized logging platform for retention and correlation with IdP logs.
- Alert on Snipe-IT administrator role changes, API token creation, and bulk asset modifications performed within a short window after a federated login.
- Monitor IdP self-registration for usernames containing non-ASCII characters or that normalize to existing privileged Snipe-IT accounts.
How to Mitigate CVE-2026-86770
Immediate Actions Required
- Upgrade Snipe-IT to version 8.7.0 or later, which enforces case- and accent-sensitive username matching during federated authentication.
- Audit the Snipe-IT users table for username collisions under the current database collation and rename any conflicting accounts.
- Review IdP registration policies to restrict who can create accounts federated with Snipe-IT and enforce username normalization at the IdP.
Patch Information
The vendor released a fix in Snipe-IT 8.7.0. Details are published in the GitHub Security Advisory GHSA-w3vv-5wxh-xg4h. Administrators should follow the standard Snipe-IT upgrade procedure and verify the deployed version after patching.
Workarounds
- If immediate upgrade is not possible, disable SAML, LDAP, and OAuth login paths and require local authentication until the patch is applied.
- Alter the users.username column to use the utf8mb4_bin collation so username comparisons are byte-exact, then verify no existing collisions remain.
- Enforce strict username allowlists at the IdP that reject non-ASCII characters and duplicates that normalize to existing Snipe-IT usernames.
# Example: change username column to binary collation to enforce exact matching
ALTER TABLE users
MODIFY username VARCHAR(255)
CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL;
# Verify no colliding usernames exist before applying
SELECT LOWER(username) AS u, COUNT(*) AS c
FROM users
GROUP BY u
HAVING c > 1;
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

