Siderolabs Omni CVE-2026-45720
HIGHSeverity by source
AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H
Primary rating from GitHub Advisory · only source for this CVE.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H
Lifecycle Timeline
2DescriptionGitHub Advisory
Summary
SAML.getSession (internal/pkg/auth/interceptor/saml.go) checks the Used flag on a SAMLAssertion resource and then marks it used in two separate state operations. Because the check and the update are not atomic, concurrent requests carrying the same saml-session token can both observe Used == false, both pass validation, and both return a successful authentication context. An attacker who obtains a valid saml-session token can exploit this window to authenticate as the token's owner multiple times, defeating the one-time-use guarantee.
Severity
- Attack Vector: Local: the attacker needs to either be able to intercept the local, unencrypted traffic or needs access to user's browser.
- Attack Complexity: High: the attacker must first obtain a valid
saml-sessiontoken belonging to the victim (requires a separate interception step; the token is ephemeral and single-use by design). - Privileges Required: None: no Omni account is required to carry out the race once the session token is in hand.
- User Interaction: Required: the victim must initiate a SAML authentication flow to produce the session token that the attacker intercepts.
- Scope: Unchanged: the impact stays within Omni's authorization boundary.
- Confidentiality Impact: High: successful exploitation authenticates the attacker as the victim's email identity, granting read access to any resource accessible to that identity.
- Integrity Impact: High: the attacker can confirm one or more public keys under the victim's identity (via
ConfirmPublicKey), establishing persistent access credentials tied to the victim's account. - Availability Impact: High: if the attacker can successfully perform the attack and if the victim is a privileged Omni user, e.g., an Omni Operator or Admin, they can take Omni down.
Impact
- Session replay: A stolen
saml-sessiontoken can be used more than once, defeating its single-use guarantee. - Multiple public key confirmations: An attacker who steals the session can confirm N attacker-controlled public keys under the victim's identity in a single stolen session window, creating N persistent long-lived API credentials tied to the victim's account.
- Authentication as victim: Any gRPC endpoint gated by the SAML interceptor can be reached as the victim's email identity during the race window.
- Audit log pollution: Each raced call generates an audit entry attributed to the victim's email, obscuring the attacker's actions.
Credit
This vulnerability was discovered and reported by bugbunny.ai.
AnalysisAI
Authentication bypass via SAML session replay in Siderolabs Omni stems from a TOCTOU race condition in the SAML interceptor (internal/pkg/auth/interceptor/saml.go), where the SAMLAssertion 'Used' flag is checked and updated non-atomically. Concurrent requests bearing the same saml-session token can each observe Used==false, allowing an attacker who has intercepted a victim's token to authenticate multiple times as the victim and persist access by registering attacker-controlled public keys. No public exploit identified at time of analysis; the issue was reported by bugbunny.ai and fixed in Omni v1.6.6 and v1.7.3.
Technical ContextAI
Omni is Sidero Labs' SaaS/self-hosted management plane for Talos Linux Kubernetes clusters, written in Go and exposing a gRPC API. Authentication relies on a SAML SSO flow that issues a single-use saml-session token represented by a SAMLAssertion COSI resource with a 'Used' boolean. The vulnerable getSession routine performs a read-then-write sequence (check Used, then mark Used) without a compare-and-swap or transactional update, which is the classic CWE-294 (Authentication Bypass by Capture-replay) / TOCTOU pattern. Because the resource update is not atomic with the validation check, two goroutines servicing parallel gRPC requests can both pass the 'unused' check before either commits the update, producing duplicate successful auth contexts tied to the victim's email identity.
RemediationAI
Vendor-released patch: upgrade to Omni 1.6.6 (https://github.com/siderolabs/omni/releases/tag/v1.6.6) on the 1.6.x line or 1.7.3 (https://github.com/siderolabs/omni/releases/tag/v1.7.3) on the 1.7.x line; note that 1.6.6 also removes several deprecated SQLite-migration flags (--audit-log-dir, --secondary-storage-path, --machine-log-* and related config keys) that must be stripped from configs before upgrade or startup will fail, and pre-1.4.0 installs must hop through 1.4.x first to complete data migrations. If immediate patching is not possible, enforce TLS end-to-end so saml-session tokens cannot be intercepted on local network segments, audit recent ConfirmPublicKey calls and revoke any unexpected public keys tied to user identities (the primary persistence mechanism abused by this bug), restrict Operator/Admin role assignment to reduce blast radius, and monitor audit logs for the same SAML assertion identifier producing multiple authenticated calls within a short window. Per the GHSA, no documented workaround replaces the fix - these are compensating controls only, with trade-offs of operational overhead and incomplete coverage of the race window.
Same weakness CWE-294 – Authentication Bypass by Capture-replay
View allSame technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today
GHSA-5x9f-6vg5-qg4m