Overview of CVE-2026-88811: SUSE Rancher Manager Meta Proxy Leaks Rancher Credentials to Allow-Listed Cloud Hosts

Introduction

On affected Rancher Manager builds, a signed-in user simply opening the Amazon EC2 provisioning form could send their live Rancher session to a host outside the installation. The flaw, tracked as CVE-2026-88811, lives in the Rancher Manager meta proxy. During ordinary provisioning work, the proxy forwarded the caller's own session cookie or API token to allow-listed external hosts, with no attacker activity against Rancher required.

SUSE Rancher is a Kubernetes management platform that centralizes authentication, access control and monitoring across clusters created through cloud services as well as imported clusters built with other distributions or installers. The project began in 2014 and became part of SUSE in 2020. SUSE reports that Rancher Labs was named a Leader in the Forrester Wave: Multicloud Container Development Platforms, Q3 2020 evaluation. Because Rancher typically sits above many downstream clusters, a credential issued by Rancher can carry access well beyond any single workload.

SUSE's CNA assessment, displayed by NVD, scores the issue CVSS 3.1 9.1 (Critical). The weakness is CWE-201, Insertion of Sensitive Information Into Sent Data. The supplied NVD description lists the vendor as unknown and omits two affected branches (2.12 and 2.11). The vendor advisory is the authoritative source for version ranges.

Technical Information

What the meta proxy does

The Rancher UI uses the meta proxy (/meta/proxy) to query cloud provider APIs for information such as regions, machine sizes and images while a user fills in a provisioning form. The proxy forwards requests only to the installation's allowed destinations:

• the whitelist-domain setting
• domains declared by cluster and node drivers
• ProxyEndpoint resources, beginning with Rancher 2.14

By default the list holds forums.rancher.com plus the public API endpoints of the built-in cloud providers. Custom drivers and administrator-configured proxy endpoints make it longer.

Root cause: two header-handling bugs

The proxy builds the outgoing request by copying the inbound headers into a new header set, skipping any name present in a deny map of "bad headers". Before the fix, that map blocked the proxy's own control headers (x-api-auth-header, x-api-cattleauth-header), content-length and Cloudflare headers. It did not block authorization or cookie, which are precisely the two headers that carry a Rancher identity. As a result, the browser's R_SESS session cookie and any Authorization: Bearer token value sent by an API client were copied into the request bound for the third-party host.

The second bug was ordering. replaceCookies(req) rewrites the outgoing Cookie from the proxy's dedicated cookie header, but it ran at the end of proxy(), after the authentication branches. Some of those branches, including the credential signer paths, return early, so on those paths cookie cleanup never executed at all.

Being an authorized destination does not make a host an authorized recipient of a credential. A host can legitimately be on the allow list and still have no business receiving a Rancher session or token.

Two exposure paths

Browser path. A signed-in user opens a provisioning view that performs a lookup through the proxy. Documented examples are the Amazon EC2, DigitalOcean, Linode and phoenixNAP forms, plus UI extensions that call the proxy with a cloud credential signer. Default configurations are affected, and no optional feature needs to be enabled.

API path. A client authenticates to Rancher with an API token, then calls the meta proxy without the expected credential selection headers (X-API-Auth-Header or X-API-CattleAuth-Header). Its Rancher token is forwarded to the destination. The advisory distinguishes this from the Rancher UI's own API behavior, which already sets X-API-Auth-Header.

Disclosure flow

Based on the advisory, the sequence looks like this:

1. A user signs in to Rancher and holds an R_SESS session cookie, or an automation client holds a Rancher API token.
2. The user opens an affected provisioning form, or the client calls /meta/proxy without a credential selection header.
3. The proxy copies inbound headers into the outgoing request. Authorization and Cookie pass through because they are not on the deny list, and on signer paths the late cookie replacement never runs.
4. The request reaches an allow-listed host carrying the Rancher credential.
5. Whoever operates that host, anyone able to read its request logs, or a TLS-terminating intermediary in front of it can obtain the live credential.
6. That credential can then be presented to the Rancher API with the victim's permissions until it expires or is revoked. Long-lived API tokens extend this window considerably.

Some secondary coverage frames this as an exposure of cloud provider credentials. The advisory describes the disclosure of a Rancher credential. Its impact depends on the user's permissions and can include administrative access to the Rancher control plane and managed downstream clusters, but not every disclosed token grants unrestricted access.

Severity assessments

The sources present different scores, and they should not be collapsed into one figure attributed to NIST:

• NVD (SUSE CNA data): CVSS 3.1 9.1, Critical, vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. NIST has not supplied its own assessment.
• Rancher GitHub advisory: CVSS 4.0 8.8, High, vector CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N, which models passive user interaction, present attack requirements and subsequent system impact.
• SUSE CVE page: Moderate, overall state Resolved, without explanation of the difference.

Exploitation status

The CISA SSVC entry in the CVE record, dated November 2, 2026, records Exploitation: none, Automatable: yes, Technical Impact: total. The Automatable value is an assessment, not evidence of observed automated exploitation. The reviewed primary records establish no named threat actor, victim or campaign. The retrieved CISA KEV snapshot is dated October 30, 2026, before NVD publication, so current KEV status is unconfirmed. A secondary report dated November 2, 2026 stated that no standalone public exploit had been published at that time.

Because normal navigation transmits the credential without any hostile request, a lack of confirmed exploitation is not the same as a lack of disclosure.

Patch Information

SUSE fixed the issue in upstream pull request rancher/rancher#58223, "Fix meta proxy header handling", merged into main on October 22, 2026 as merge commit ad907b74f54b60afedb20224c49eb533f1c474c9. Backport pull requests followed for every supported branch: #58224 (v2.15), #58225 (v2.14), #58226 (v2.13), #58227 (v2.12) and #58229 (v2.11). The fix shipped in v2.15.3, v2.14.7, v2.13.11, v2.12.15 and v2.11.19, and the advisory was published on October 29, 2026.

The change touches 2 files, adding 97 lines and removing 2. Almost all of the additions are tests. The production fix is a five-line change in pkg/httpproxy/proxy.go that does two things.

1. Treating Authorization and Cookie as bad headers

 		"content-length":          true,
 		"x-api-auth-header":       true,
 		"x-api-cattleauth-header": true,
+		"authorization":           true,
+		"cookie":                  true,
 		"cf-connecting-ip":        true,
 		"cf-ray":                  true,

This is a deny-by-default fix at the copy step. Neither header can come through the copy any more, regardless of which branch runs afterwards. Flows that legitimately need an outgoing Authorization header still work because they set it themselves after the copy, namely the explicit X-API-Auth-Header value and the cloud credential signers selected through X-API-CattleAuth-Header.

2. Moving cookie replacement ahead of the early returns

 	req.URL = destURL
 	req.Header = headerCopy
 
+	// Runs before the branches below, some of which return early.
+	replaceCookies(req)
+
 	if auth != "" { // non-empty AuthHeader is noop
 		req.Header.Set(AuthHeader, auth)
 	} else if cAuth != "" {
@@
 		req.Header.Set(AuthHeader, cAuth)
 	}
 
-	replaceCookies(req)
-
 	return nil

The advisory credits this reordering for the fix applying on all request paths. One side effect: a cookie value that a client deliberately supplies through the proxy's cookie header is now forwarded on signer paths too, where it was previously dropped silently.

What the tests assert

The new TestProxyOutgoingHeaders table test starts each case with a realistic Rancher identity, Authorization: Bearer token-abc:secret and Cookie: R_SESS=token-abc:secret; other=1, and runs it through each auth path: no selection headers, X-API-Auth-Header, CattleAuth without a known signer, an arbitrary signer, and a failing bearer signer. Every case asserts that the outgoing Cookie is empty and that Authorization is either absent or exactly the value the selected path should produce, never the caller's Rancher token. TestProxyAPICookieWithSigner confirms that a client-supplied cookie (mine=1) reaches the upstream on a signer path while R_SESS does not, and TestIsBadHeader now covers both capitalisations of the two new headers.

Behavior change

The fix is not a breaking change for the Rancher UI. However, a client calling /meta/proxy without either credential selection header now reaches the upstream with no Authorization header and receives that host's own authentication error. Integrations that relied on their Authorization header passing through must send the value in X-API-Auth-Header instead. The release notes summarize it as the proxy now stripping "the caller's credentials on every request path."

Credential cleanup after upgrading

Patching stops future forwarding but does not revoke anything already sent. The vendor explicitly recommends that, after upgrading, administrators rotate or delete long-lived Rancher API tokens used against the meta proxy and invalidate existing user sessions, requiring affected users to sign in again.

If the upgrade has to wait

The vendor lists measures that reduce exposure, while stating there is no complete workaround other than upgrading:

1. Remove unnecessary entries from whitelist-domain, custom cluster and node driver domains, and custom ProxyEndpoint resources (2.14 and later). Built-in driver hosts are restored at startup and cannot be removed this way.
2. Create cloud credentials, node templates and machine configurations through the API or kubectl rather than the Amazon EC2, DigitalOcean, Linode and phoenixNAP UI forms.
3. Do not call the meta proxy with a Rancher API token unless the request also sets X-API-Auth-Header.
4. Lower auth-user-session-ttl-minutes and auth-token-max-ttl-minutes, and avoid long-lived administrative tokens in workflows that reach the meta proxy.

Detection Methods

No YARA, Sigma, Snort/Suricata or Nuclei signature exists for this CVE, and none of the reviewed sources contain one. That is expected, because nothing malicious is sent to Rancher. The proxy leaks the caller's own credentials to an allow-listed host during normal use. Detection therefore comes down to four questions.

1. Are you running a vulnerable build?

Rama Digital tested its check scripts against the official rancher/rancher:v2.15.2 (vulnerable) and v2.15.3 (fixed) images, and describes two manual ways to read the version. The /rancherversion endpoint answers without a login, which helps for servers you lack kubectl access to:

curl -sk https://rancher.example.com/rancherversion
kubectl get settings.management.cattle.io server-version fleet-version

A patched version does not mean credentials never leaked. The flaw was silent before the upgrade, so the remaining steps apply to every instance, including those already patched.

2. Which hosts could have received credentials?

The allow list defines where credentials could have gone and which receiving logs you might review. The Rama Digital settings script inventories this with kubectl: the whitelist-domain value, the .spec.whitelistDomains of active nodedrivers.management.cattle.io, counts of built-in versus admin-added proxyendpoints.management.cattle.io, and the number of cloud credential secrets in cattle-global-data (evidence that provisioning forms were used). It also reports auth-user-session-ttl-minutes, auth-token-max-ttl-minutes, and how many tokens are valid for more than 30 days or never expire, which indicates how long a leaked credential could remain usable. In its default 2.15.2 test install, the maximum token lifetime was 129600 minutes (90 days).

3. Can you see the leak in traffic or receiving host logs?

Wiz derives these indicators from the advisory:

• Egress traffic: outbound requests from the Rancher server to allow-listed hosts carrying Authorization or Cookie headers with Rancher credential values. This is only visible where TLS is inspected or where you operate the outbound proxy.
• Receiving host logs: access log entries showing inbound Authorization: Bearer <rancher-token> or Cookie: R_SESS=... headers. You can review these directly for custom driver endpoints, internal ProxyEndpoint targets and corporate TLS inspection proxies you control. Public cloud provider API logs are usually not available to you, so assume exposure there.

Watch the two triggers: the browser path (users opening the Amazon EC2, DigitalOcean, Linode or phoenixNAP forms, or a UI extension calling the proxy with a credential signer) and the API token path (automation calling the proxy without X-API-Auth-Header).

Patching also produces a useful signal. The fixed proxy forwards such clients without an Authorization header, so they receive the third-party host's own authentication error. A burst of upstream auth failures from a script or CI job right after the upgrade marks a client that was probably leaking its Rancher token before. Rotate those tokens first.

4. Has anyone used a leaked credential?

Hunt in Rancher audit logs for:

• API access from unusual source IPs or user agents using session or API tokens that were recently active in provisioning workflows
• access from IP addresses associated with cloud provider endpoints or other allow-listed hosts
• use from locations or ranges inconsistent with the user's normal pattern, especially shortly after they opened a provisioning form
• cluster configuration changes, new workloads or RBAC changes not made by a known administrator

To build a list of tokens to review and rotate, Rama Digital lists each token's TTL and last use:

kubectl get tokens.management.cattle.io -o custom-columns=NAME:.metadata.name,DESCRIPTION:.description,TTL:.ttl,LAST-USED:.lastUsedAt

Its signs-of-use script also flags tokens whose lastUsedAt falls after a chosen start date. Rancher 2.12 and later have a second token API, which you can check with kubectl get tokens.ext.cattle.io. Before rotating any token that never expires, or that was used against the meta proxy while the instance was vulnerable, correlate it with audit log activity. Rama Digital also cautions that an attacker can delete logs, so finding nothing is not proof of safety.

Affected Systems and Versions

SUSE Rancher Manager in default configuration is affected in the following ranges, excluding the listed fixed releases:

• 2.15: 2.15.0 through 2.15.2, fixed in 2.15.3
• 2.14: 2.14.0 through 2.14.6, fixed in 2.14.7
• 2.13: 2.13.0 through 2.13.10, fixed in 2.13.11
• 2.12: 2.12.0 through 2.12.14, fixed in 2.12.15
• 2.11: 2.11.0 through 2.11.18, fixed in 2.11.19

Exposure is broadest on installations where users use the Amazon EC2, DigitalOcean, Linode or phoenixNAP provisioning forms, run UI extensions that use a cloud credential signer, have automation calling /meta/proxy with Rancher tokens but without X-API-Auth-Header, or have expanded the allow list with custom drivers, whitelist-domain entries or ProxyEndpoint resources (2.14 and later).

Vendor Security History

The closest historical parallel is CVE-2021-25320, published by Rancher on July 15, 2021. Its proxy API failed to validate cloud credentials properly. A logged-in Rancher user who knew a valid cloud credential ID could invoke the cloud provider API through the proxy, which attached that credential. The issue was limited to valid Rancher users, was patched in 2.5.9 and 2.4.16, and had no direct mitigation besides upgrading.

The two flaws share a sensitive integration boundary but differ in kind. CVE-2021-25320 let users borrow cloud credentials they should not have been able to use; CVE-2026-88811 lets Rancher's own credentials travel outward. The record does not establish a common underlying defect or a regression.

The October 29, 2026 advisory set also includes CVE-2026-88809 (ineffective proxy destination allowlist enforcement) and CVE-2026-88810 (insufficient privilege escalation validation for inheritedNamespacedRules in a GlobalRole). These are separate findings, and no demonstrated chain with CVE-2026-88811 is documented. The finder credited in the CVE record is Peter Matseykanets.

References

• NVD: CVE-2026-88811
• CVE record (cveawg.mitre.org)
• NVD API record
• Rancher advisory GHSA-x82x-2qj6-5rm2
• GitHub API: GHSA-x82x-2qj6-5rm2
• SUSE CVE page for CVE-2026-88811
• SUSE Rancher Manager v2.15 Security Advisories and CVEs
• Pull request #58223: Fix meta proxy header handling
• GitHub API: pull request #58223
• GitHub API: pull request #58223 files
• Rancher Manager v2.14.7 release notes
• Wiz vulnerability database entry
• Rama Digital detection guidance
• CISA Known Exploited Vulnerabilities feed
• CIRCL Vulnerability Lookup
• SecurityOnline coverage
• TheHackerWire coverage
• Rancher advisory GHSA-gqf8-rvrh-g7w6 (CVE-2021-25320)
• SUSE Rancher Manager overview
• About Rancher
• SUSE blog: Rancher recognized as a Leader in Forrester Wave
• Futurum Group: SUSE updates Harvester and Rancher