Description

A flaw was found in Rancher Manager. The SAML assertion replay protection introduced by the fix for CVE-2026-44946 recorded consumed assertion IDs in a per-process cache, so each replica only detected replays that reached the same pod. In a high-availability deployment, an attacker holding a captured assertion could replay it once against every other replica to obtain additional authenticated sessions as the victim. This issue affects Rancher: before 2.15.1.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.4",
  "pubDate": "2026-09-03T16:18:22.343Z",
  "pubdate": "2026-09-03T16:18:22.343Z",
  "executiveSummary": "This vulnerability involves an ineffective SAML assertion replay protection mechanism within Rancher Manager. The flaw stems from a localized, per-process cache implementation for storing consumed SAML assertion IDs, which fails to account for high-availability (HA) deployment architectures.\nIn multi-replica environments, this oversight allows an attacker who has captured a valid SAML assertion to circumvent the intended replay protection. By replaying the same assertion against different pods/replicas within the cluster, the attacker can successfully establish multiple authenticated sessions as the victim.\nThe vulnerability affects Rancher versions prior to 2.15.1. The risk is significant, as it enables unauthorized session hijacking and authentication bypass across distributed deployments. Exploitation does not require elevated privileges but necessitates the interception of a valid SAML assertion, typically through network-level monitoring or logging. This issue effectively renders the existing security fix for CVE-2026-44946 incomplete in distributed environments, necessitating a centralized state management solution to ensure global assertion tracking.",
  "technicalDetails": "The root cause of this vulnerability is the implementation of a local, in-memory cache for SAML assertion ID tracking. During the initial remediation of CVE-2026-44946, the developers introduced a mechanism to record consumed assertion identifiers (Assertion IDs) to prevent replay attacks. However, this state was maintained strictly within the scope of the individual process or pod running the Rancher Manager instance.\nIn a standard high-availability Rancher deployment, the cluster is comprised of multiple replicas sitting behind a load balancer. When a user authenticates via SAML, the assertion is processed by the specific pod that receives the request. Because the cache is not synchronized or centralized across the cluster, a successfully consumed assertion ID is only 'known' to the pod that processed the initial request.\nThe attack flow proceeds as follows: 1) An attacker intercepts or captures a valid, non-expired SAML assertion from a legitimate user. 2) The attacker submits the captured assertion to the Rancher load balancer. 3) The load balancer routes the request to Pod A. 4) Pod A verifies the assertion, logs the Assertion ID in its local cache, and grants the attacker an authenticated session. 5) The attacker then re-submits the identical, captured assertion to the load balancer. 6) The load balancer routes the request to Pod B. 7) Pod B, possessing its own independent and empty assertion cache, validates the assertion as 'new' and grants the attacker a second authenticated session.\nThis behavior results in a successful bypass of the SAML replay protection mechanism. Because each replica operates in isolation regarding the assertion cache, the 'protection' is limited to a per-pod granularity. The vulnerable component is the SAML authentication handler within Rancher Manager. This issue is categorized as an improper state synchronization flaw, where security-critical session metadata is not shared across the distributed application layer. To reach a state of full protection, the application must shift from local in-memory caching to a global, distributed store (such as Redis or a shared database) capable of atomic operations to ensure that once an assertion ID is consumed, it is globally invalidated across all nodes in the cluster."
}