CVE-2026-88811: 
Analyse et atténuation de la vulnérabilité

CVE-2026-88811 is a credential disclosure vulnerability in the Rancher Manager meta proxy component, which the Rancher UI uses to query cloud provider APIs on behalf of users during cluster or node provisioning. The flaw causes the proxy to fail to consistently strip the caller's own Rancher credentials (browser session cookies or API tokens) from outgoing requests forwarded to configured third-party hosts. Affected versions span Rancher 2.11.0–2.11.18, 2.12.0–2.12.14, 2.13.0–2.13.10, 2.14.0–2.14.6, and 2.15.0–2.15.2. The vulnerability was disclosed on October 29, 2026, with a CVSS v4.0 base score of 8.8 (High) (GitHub Advisory).

The root cause is classified under CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) and CWE-201 (Insertion of Sensitive Information Into Sent Data). The meta proxy component copied inbound Authorization and Cookie headers from the caller's request into outgoing requests to third-party hosts without stripping them first; additionally, cookie replacement logic ran after authentication handling rather than before it, meaning some code paths bypassed the sanitization entirely. Two distinct exposure paths exist: (1) a signed-in browser user navigating a provisioning form (e.g., Amazon EC2, DigitalOcean, Linode, phoenixNAP) causes their session cookie to be forwarded to the cloud provider's API endpoint, and (2) a non-browser API client calling the proxy without the proxy's credential-selection headers causes its Rancher API token to be forwarded to the third-party host. No attacker activity against Rancher itself is required for the credential to leave the installation in the browser-session scenario (GitHub Advisory).

Any party able to operate or observe the receiving third-party host — including its request logs or any TLS-terminating intermediary — receives a live Rancher credential carrying the full permissions of the affected user, potentially including administrative access to the Rancher Manager control plane and all managed Kubernetes clusters. Because Rancher API tokens can be long-lived, the window of exposure may extend well beyond the initial forwarding event. Successful exploitation could enable an attacker to pivot from a compromised cloud provider endpoint to full administrative control of the Rancher environment and downstream clusters, representing a severe confidentiality and integrity impact across the entire managed infrastructure (GitHub Advisory).

The CVE status is currently Reserved and no public exploit code, PoC, or in-the-wild exploitation has been reported as of the disclosure date. The browser-session exposure scenario requires only passive user interaction — a signed-in user navigating a provisioning form — with no deliberate attacker action against Rancher required, making it particularly insidious. Deployments in a default configuration are affected as soon as a user opens one of the affected provisioning forms. No EPSS score or CISA KEV catalog entry has been identified for this CVE at this time (GitHub Advisory).

1. Position on a third-party host: An attacker gains the ability to operate or observe a host on Rancher's proxy allow-list (e.g., a custom cloud provider endpoint, a custom cluster/node driver domain, or a ProxyEndpoint resource configured by an administrator).
2. Wait for victim interaction: The attacker waits for a signed-in Rancher user to open a provisioning form (e.g., Amazon EC2, DigitalOcean, Linode, or phoenixNAP node provisioning) in the Rancher UI, which triggers the meta proxy to forward a cloud provider API lookup to the attacker-controlled or attacker-observable host.
3. Harvest forwarded credentials: The attacker inspects the incoming HTTP request headers on the third-party host (e.g., via access logs or a TLS-terminating proxy) and extracts the Cookie or Authorization header containing the victim's live Rancher session credential or API token.
4. Authenticate to Rancher: The attacker uses the harvested credential to authenticate directly to the Rancher Manager API, inheriting the victim's permissions — potentially full administrative access.
5. Lateral movement: With administrative Rancher access, the attacker can enumerate and access all managed Kubernetes clusters, extract secrets, deploy workloads, or escalate privileges further within the managed infrastructure (GitHub Advisory).

• Network: Unexpected or anomalous authentication requests to the Rancher API originating from IP addresses associated with cloud provider API endpoints or other proxy allow-listed hosts; outbound requests from the Rancher server to allow-listed third-party hosts containing Authorization or Cookie headers with Rancher credential values.
• Logs: Rancher audit logs showing API access from unusual source IPs or user agents using session tokens or API tokens that were recently active in provisioning workflows; access log entries on third-party/cloud provider hosts showing inbound requests with Authorization: Bearer <rancher-token> or Cookie: R_SESS=... headers.
• Credential Activity: Rancher API tokens or session cookies used from geographic locations or IP ranges inconsistent with the legitimate user's normal access patterns, particularly shortly after a provisioning form was opened in the UI.
• Administrative Actions: Unexpected cluster configuration changes, new workload deployments, or RBAC modifications in Rancher or managed clusters that cannot be attributed to known administrative activity (GitHub Advisory).

Rancher has released patched versions: 2.15.3, 2.14.7, 2.13.11, 2.12.15, and 2.11.19, which strip Authorization and Cookie headers from all outgoing proxy requests before forwarding. After upgrading, administrators should treat previously forwarded credentials as potentially compromised: rotate or delete long-lived Rancher API tokens used against the meta proxy, and invalidate existing user sessions to force re-authentication. For installations that cannot upgrade immediately, partial mitigations include: reviewing and pruning the proxy allow-list (whitelist-domain, custom driver domains, and ProxyEndpoint resources) to the minimum required set; creating cloud credentials via API or kubectl instead of the Rancher UI provisioning forms; ensuring API clients always supply the X-API-Auth-Header when calling the meta proxy; and reducing auth-user-session-ttl-minutes and auth-token-max-ttl-minutes to limit the validity window of any exposed credential. Note that built-in driver host entries cannot be removed from the allow-list (GitHub Advisory).