CVE-2026-116201 in Snipe-IT
Summary
by MITRE • 10/25/2026
Snipe-IT before 8.5.0 contains a SAML assertion replay vulnerability that allows attackers to reuse captured assertions by exploiting a non-atomic nonce check in the SAML acs handler. Attackers can send concurrent POST requests to /saml/acs with one captured assertion to obtain multiple authenticated victim sessions that evade IdP-driven revocation.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/25/2026
The vulnerability identified in Snipe-IT versions prior to 8.5.0 represents a critical authentication bypass rooted in the improper handling of SAML assertions, specifically within the Assertion Consumer Service handler. This flaw allows an attacker to perform assertion replay attacks by exploiting a race condition inherent in the nonce validation logic. In secure implementations, nonces are used as unique identifiers for each authentication request and response pair to ensure that a specific SAML assertion can only be processed once. However, due to the lack of atomicity in the check-and-set operation performed on these nonces during concurrent requests, multiple threads or processes can simultaneously validate the same nonce before any single instance has recorded its usage. This timing window enables an adversary to send parallel POST requests containing a previously captured SAML assertion, successfully authenticating as the victim across multiple sessions without triggering standard revocation mechanisms enforced by the Identity Provider.
From a technical perspective, this issue classifies under CWE-367, which describes Time-of-check to time-of-use vulnerabilities where the state of an object changes between its verification and its use. The specific mechanism involves the SAML ACS endpoint failing to lock or serialize access to the nonce storage during validation. When two requests arrive nearly simultaneously with identical nonces from a replayed assertion, both pass the validity check because neither has yet written the consumed status back to the database or cache. Consequently, the application treats each request as valid and distinct, granting session tokens for each successful authentication attempt. This behavior fundamentally undermines the security guarantees provided by SAML protocols, which rely on nonces to prevent replay attacks and ensure single-use integrity of assertions.
The operational impact of this vulnerability is severe, as it allows attackers to establish multiple active sessions under a compromised user account while evading detection through standard Identity Provider revocation logs. Since each session appears to be initiated by a fresh authentication event rather than a reuse of an old one, traditional monitoring tools may not flag the activity as anomalous immediately. Attackers can leverage these concurrent sessions to escalate privileges, exfiltrate sensitive inventory data managed by Snipe-IT, or perform unauthorized configuration changes across multiple endpoints simultaneously. The ability to bypass IdP-driven revocation means that even if a user logs out or an administrator invalidates their session at the identity provider level, the attacker retains access through the locally established sessions derived from the replayed assertion until they expire naturally.
This vulnerability aligns with MITRE ATT&CK technique T1528, which covers Steal Application Access Tokens, as well as aspects of T1078, Valid Accounts, since it involves abusing legitimate authentication flows to gain unauthorized access. It also reflects CWE-362 regarding concurrent execution using shared resources with insufficient synchronization. To mitigate this risk, organizations running Snipe-IT must upgrade immediately to version 8.5.0 or later, where the nonce check has been corrected to ensure atomicity and prevent race conditions during assertion validation. Additionally, administrators should enforce strict session timeout policies and monitor for unusual patterns of concurrent logins from single user accounts as a defensive measure against potential exploitation attempts in environments that have not yet patched this specific flaw.