A valet who hands your house keys to every taxi company you call
CVE-2026-88811 is a missing filtering flaw in the SUSE Rancher Manager meta proxy, the component the Rancher UI uses to query cloud provider APIs on behalf of a user during cluster or node provisioning. When the proxy forwards a request to a configured third-party host, it does not reliably strip the caller’s own Rancher credentials from the outgoing request. The result is that Rancher session cookies, API tokens, or other credentials supplied in the request can be transmitted to the cloud provider alongside the intended API call. Affected versions per the official record are SUSE Rancher 2.15.0 through 2.15.2, 2.14.0 through 2.14.6, and 2.13.0 through 2.13.10; the GitHub security advisory also lists 2.12.0–2.12.14 and 2.11.0–2.11.18. Fixed releases are 2.15.3, 2.14.7, 2.13.11, plus 2.12.15 and 2.11.19.
The vendor rates this CRITICAL 9.1 using CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. That severity is directionally correct because Rancher Manager is a Kubernetes fleet control plane: a leaked admin token can become fleet-scale cluster and cloud account compromise. However, the PR:N component is optimistic. The leaked credentials belong to a signed-in Rancher user, so an attacker either needs an existing low-privilege session or must control or compromise the third-party cloud provider host. No active exploitation or public PoC exists yet, but the high-value deployment role keeps this at CRITICAL rather than HIGH.
6 steps from start to impact.
Reach the Rancher meta proxy
/v3 or /meta path. The attacker can use curl or a browser to interact with the API if the management plane is reachable.- Network route from attacker to Rancher management server
- Meta proxy service deployed and enabled
- Rancher management console is not typically internet-facing; it should sit behind VPN or an NGFW
- Many enterprises block external access to port 8443
Trigger a proxied request to a third-party host
Burp Collaborator or a custom HTTP listener receive the forwarded request.- Meta proxy accepts the request without robust target-host filtering
- Attacker can set or influence the destination host, or controls a malicious cloud provider endpoint
- If Rancher restricts destinations to registered cloud provider FQDNs, then only compromised or malicious cloud providers receive the leaked credentials
- Most legitimate cloud provider endpoints are highly controlled
Meta proxy forwards caller credentials
Authorization header, Cookie: R_SESS, or X-Api-Token into the outbound request because filtering is incomplete. The leak occurs server-side and requires no victim interaction if the attacker can craft the request. A standard HTTP debugger can observe the outbound headers.- Vulnerable Rancher version where header stripping is incomplete
- Attacker’s request includes a Rancher token or session cookie
- Modern WAF or API gateway may rewrite Authorization headers
- Some token headers may be stripped by reverse proxy settings
Receive leaked Rancher credentials
- Destination host logs or forwards the full request to the attacker
- Credentials are not expired
- Legitimate cloud providers will not forward credentials to an external attacker
- TLS termination is at the destination, not in Rancher
Authenticate to Rancher with stolen token
kubectl with the stolen kubeconfig token, rancher cli, or direct curl requests to /v3. The attacker inherits the victim’s Rancher role.- Rancher API is reachable
- Token has not been revoked or expired
- Token lifetime may be short
- Rancher audit logs record unusual new client IPs
Escalate to fleet or cloud account takeover
- Victim has high Rancher privileges
- Cloud credentials linked in Rancher allow cloud API access
- Rancher RBAC may limit non-admin tokens
- EDR and Kubernetes admission control may block lateral movement
/meta/ and /v3 paths at the reverse proxy. For a CRITICAL verdict, apply this within 3 days under the noisgate mitigation SLA.- Network IDS/IPS signatures for SSRF may not fire because the meta proxy traffic looks like legitimate application API calls to cloud providers.
- MFA at user login does not protect already-issued session tokens or API keys from being forwarded.
- Cloud provider audit logs may only show the leak after the fact; they do not prevent credential disclosure.
The supporting signals.
| In-the-wild status | No known active exploitation. Mallory tracks 0 exploitation reports; no ransomware or campaign activity observed as of 2026-11-01. |
|---|---|
| CISA KEV status | Not listed in CISA Known Exploited Vulnerabilities; no federal deadline. |
| PoC availability | No public PoC found on GitHub, pocindex.io, ExploitDB, or Nuclei templates for CVE-2026-88811 at analysis time. |
| EPSS score and percentile | EPSS not yet published or below FIRST reporting threshold; VulDB shows 0.00+ trend, indicating negligible mass-exploitation likelihood. |
| CVSS vector interpretation | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N — remote, low complexity, no privileges, no user interaction, high confidentiality and integrity impact, no availability impact. |
| Affected version ranges | Official: 2.15.0–2.15.2, 2.14.0–2.14.6, 2.13.0–2.13.10. GitHub SA adds 2.12.0–2.12.14 and 2.11.0–2.11.18. |
| Fixed versions | 2.15.3, 2.14.7, 2.13.11; GitHub SA also lists 2.12.15 and 2.11.19. |
| Disclosure date | NVD published 2026-11-02; GitHub advisory published 2026-10-28. |
| Scanning / exposure data | No public GreyNoise/Shodan/Censys mass-scan data shows broad exposure of Rancher meta proxy; Rancher management UI is usually not internet-facing. |
| Reporting researcher / org | No individual researcher credited; disclosed through SUSE/GitHub security advisory channels. |
Sources.
- NVD — CVE-2026-88811
- GitHub Security Advisory — Rancher credentials disclosed to third-party hosts by the Rancher Manager meta proxy
- Rapid7 vulnerability database — CVE-2026-88811
- Tenable — CVE-2026-88811
- VulDB — CVE-2026-88811
- Launchpad Bugs — CVE-2026-88811
- CCN-CERT vulnerability bulletin — CVE-2026-88811
- Mallory — Credential Disclosure in SUSE Rancher Manager Meta Proxy
Why this verdict
- Role multiplier: SUSE Rancher Manager is the control plane for Kubernetes fleets and cloud credentials. A leaked admin token gives fleet-wide cluster, namespace, and cloud-account compromise, so the floor is CRITICAL for any plausible high-value role outcome.
- Vendor baseline: CRITICAL 9.1 is credible because impact is high for confidentiality and integrity. We accept the impact but shave one point for real-world exploitability.
- Friction audit: The attack path requires either an existing Rancher session or a malicious/compromised cloud provider. That narrows the reachable attacker population, but not enough to break the critical floor for a control-plane component.
Why not higher?
No availability impact, no public PoC, no KEV listing, and the leak goes to a third-party host rather than directly to an arbitrary attacker. There is no evidence of active exploitation, so 10.0 is not warranted.
Why not lower?
Rancher Manager is canonically a high-value management plane. Even if internet exposure is low, signed-in admin credentials can leak to cloud providers during routine provisioning, and a malicious or compromised cloud provider can turn that into full fleet takeover. Patched versions exist and close the flaw cleanly.
Crowdsourced verification payload.
Run on a jump host with kubectl access to the Rancher management cluster, or from the Rancher server console. Example: bash check_cve-2026-88811.sh https://rancher.example.com <RANCHER_TOKEN>. If the optional token is omitted, the script will attempt kubectl -n cattle-system to fetch the Rancher deployment image tag. Cluster-admin privileges are needed only for the kubectl path; the API token path uses the supplied Rancher token.
#!/bin/bash
# CVE-2026-88811 SUSE Rancher Manager meta proxy credential leak check
# Usage: ./check_cve-2026-88811.sh [RANCHER_URL] [RANCHER_TOKEN]
# Exit codes: 0=VULNERABLE, 1=PATCHED, 2=UNKNOWN
set -u
RANCHER_URL="${1:-}"
TOKEN="${2:-}"
VERSION=""
if [ -n "$TOKEN" ] && [ -n "$RANCHER_URL" ]; then
resp=$(curl -sk -m 15 -H "Authorization: Bearer $TOKEN" "$RANCHER_URL/v3/settings/server-version" 2>/dev/null || true)
VERSION=$(echo "$resp" | sed -n 's/.*"value":"\([^"]*\)".*/\1/p' | head -1)
elif command -v kubectl >/dev/null 2>&1; then
img=$(kubectl -n cattle-system get deployment rancher -o jsonpath='{.spec.template.spec.containers[0].image}' 2>/dev/null || true)
VERSION="${img##*:}"
fi
if [ -z "$VERSION" ]; then
echo UNKNOWN
exit 2
fi
VERSION="${VERSION#v}"
vuln=0
if [[ "$VERSION" =~ ^([0-9]+)\.([0-9]+)\.([0-9]+) ]]; then
major="${BASH_REMATCH[1]}"
minor="${BASH_REMATCH[2]}"
patch="${BASH_REMATCH[3]}"
if { [ "$major" -eq 2 ] && [ "$minor" -eq 11 ] && [ "$patch" -lt 19 ]; } || \
{ [ "$major" -eq 2 ] && [ "$minor" -eq 12 ] && [ "$patch" -lt 15 ]; } || \
{ [ "$major" -eq 2 ] && [ "$minor" -eq 13 ] && [ "$patch" -lt 11 ]; } || \
{ [ "$major" -eq 2 ] && [ "$minor" -eq 14 ] && [ "$patch" -lt 7 ]; } || \
{ [ "$major" -eq 2 ] && [ "$minor" -eq 15 ] && [ "$patch" -lt 3 ]; }; then
vuln=1
fi
fi
if [ "$vuln" -eq 1 ]; then
echo VULNERABLE
exit 0
else
echo PATCHED
exit 1
fi