SUSE Rancher CVE-2026-88811

Two concrete paths, both confirmed by the advisory. (1) Session-credential exposure: a signed-in Rancher user opens a UI provisioning view that looks up cloud data through the meta proxy - explicitly the Amazon EC2, DigitalOcean, Linode, or phoenixNAP provisioning forms, or a UI extension using a credential signer; default configurations are affected the moment such a form is opened, with no non-default feature required and no attacker action against Rancher. (2) API-token exposure: a non-browser client authenticates with a Rancher API token and calls the meta proxy without supplying the proxy's credential-selection headers (the Rancher UI itself does not do this). The key limiting factor is destination scope: a forwarded request only reaches hosts on the installation's allow-list - the whitelist-domain setting, cluster/node driver domains, and (Rancher 2.14+) ProxyEndpoint resources - which by default is forums.rancher.com plus built-in cloud providers' public API endpoints, so meaningful adversarial capture generally requires the attacker to operate, observe, or sit as a TLS-terminating intermediary in front of one of those allow-listed hosts (risk grows with custom drivers/ProxyEndpoints). Exposure window is extended by long-lived API tokens.

This is a genuine high-priority issue, consistent with its 9.1 CVSS score, the vuln.today 'act_now' decision label, and SUSE's own GHSA advisory. The CVSS vector (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:N) captures the worst-case severity well: a live Rancher credential - potentially an administrative session cookie or a long-lived API token carrying control-plane and downstream-cluster permissions - leaks to a third-party host during ordinary operation, with no attacker action required against Rancher itself. The critical nuance the raw vector omits is the exploitation model: this is a passive credential-disclosure flaw (CWE-200/201), not a classic remote-attacker exploit. The credential leaves the installation on its own whenever a signed-in user opens an affected provisioning form, and is received by whoever operates or observes an allow-listed destination host (and any TLS-terminating intermediary in front of it). By default that destination set is forums.rancher.com and the built-in cloud providers' public API endpoints, so in the default case the receiving party is a legitimate cloud provider rather than a hostile actor - real risk rises sharply where administrators have added custom cluster/node drivers or (in 2.14+) ProxyEndpoint resources pointing at attacker-controllable or lower-trust hosts. No EPSS score and no KEV status are provided in the input, and no PoC reference is listed; absence of those signals does not lower the priority here because the 'act_now' label and silent-exposure-during-normal-use nature mean credentials may already have been forwarded even without any adversary targeting the instance.

An administrator configures a custom node driver (or ProxyEndpoint) whose whitelisted host is operated or observed by an attacker. A signed-in Rancher user then opens a cloud provisioning form that performs a credential-backed lookup; the meta proxy forwards the request to that host without stripping the user's Rancher session cookie or API token, and the attacker reads the live credential from the host's request logs and replays it for administrative access to the Rancher control plane and managed clusters. No public exploit was identified in the input at time of analysis; exploitation requires no attacker activity against Rancher and no non-default feature, only a receiving host the attacker can see.