← Back to Feed CACHED · 2026-11-03 02:08:07 · CACHE_KEY CVE-2026-88811
CVE-2026-88811 · CWE-201 · Disclosed 2026-11-02

SUSE Rancher Manager meta proxy missing filtering discloses Rancher credentials to cloud providers

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

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.

"Rancher’s meta proxy can leak signed-in credentials to cloud providers—critical for anyone running Rancher as fleet control plane."
02 · The Attack Path

6 steps from start to impact.

STEP 01

Reach the Rancher meta proxy

An attacker sends a request to the Rancher management UI/API endpoint that invokes the meta proxy. In many deployments this is the /v3 or /meta path. The attacker can use curl or a browser to interact with the API if the management plane is reachable.
Conditions required:
  • Network route from attacker to Rancher management server
  • Meta proxy service deployed and enabled
Where this breaks in practice:
  • Rancher management console is not typically internet-facing; it should sit behind VPN or an NGFW
  • Many enterprises block external access to port 8443
Detection/coverage: Shodan/Censys/GreyNoise would see low exposure of Rancher endpoints; NGFW logs can show access attempts.
STEP 02

Trigger a proxied request to a third-party host

The attacker supplies a request that causes the meta proxy to forward to a cloud provider endpoint—or, if the proxy does not restrict the destination, to an attacker-controlled host. The request may be a normal-looking cloud credential lookup or a crafted URL parameter. Tools like Burp Collaborator or a custom HTTP listener receive the forwarded request.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: WAF or API gateway logs may show unusual URL parameters; egress proxy logs can show unexpected outbound targets.
STEP 03

Meta proxy forwards caller credentials

The vulnerable proxy copies the caller’s 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.
Conditions required:
  • Vulnerable Rancher version where header stripping is incomplete
  • Attacker’s request includes a Rancher token or session cookie
Where this breaks in practice:
  • Modern WAF or API gateway may rewrite Authorization headers
  • Some token headers may be stripped by reverse proxy settings
Detection/coverage: Egress DLP or forward proxy can flag Rancher bearer tokens leaving to non-Rancher hosts.
STEP 04

Receive leaked Rancher credentials

The attacker-controlled third-party host or compromised cloud provider receives the outbound request containing valid Rancher credentials. The attacker now possesses the caller’s session or API token.
Conditions required:
  • Destination host logs or forwards the full request to the attacker
  • Credentials are not expired
Where this breaks in practice:
  • Legitimate cloud providers will not forward credentials to an external attacker
  • TLS termination is at the destination, not in Rancher
Detection/coverage: Cloud provider traffic logs may show unexpected headers; SIEM can alert on Rancher tokens leaving the trust boundary.
STEP 05

Authenticate to Rancher with stolen token

The attacker uses the leaked token or session cookie to access the Rancher API. Commands include kubectl with the stolen kubeconfig token, rancher cli, or direct curl requests to /v3. The attacker inherits the victim’s Rancher role.
Conditions required:
  • Rancher API is reachable
  • Token has not been revoked or expired
Where this breaks in practice:
  • Token lifetime may be short
  • Rancher audit logs record unusual new client IPs
Detection/coverage: Rancher audit log and Kubernetes audit log can show new sessions from unexpected IPs.
STEP 06

Escalate to fleet or cloud account takeover

If the leaked credentials belong to an admin or owner, the attacker can create new users, extract secrets, deploy malicious workloads, and pivot to managed Kubernetes clusters or cloud accounts. This is the blast radius that keeps the verdict critical.
Conditions required:
  • Victim has high Rancher privileges
  • Cloud credentials linked in Rancher allow cloud API access
Where this breaks in practice:
  • Rancher RBAC may limit non-admin tokens
  • EDR and Kubernetes admission control may block lateral movement
Detection/coverage: Kubernetes audit logs, EDR, and cloud provider CloudTrail can detect abnormal workload creation or secret access.
03 · Compensating Control

1
CRITICAL 9.0→IGNORE 0.0
SEVERITY REDUCED
Apply the vendor patch immediately — Upgrade to 2.15.3, 2.14.7, 2.13.11 (and 2.12.15, 2.11.19 from GitHub SA). This is the permanent fix. Deploy within the noisgate remediation SLA of ≤90 days; if active exploitation appears, treat as immediate.
2
CRITICAL 9.0→HIGH 7.5
SEVERITY REDUCED
Restrict access to the Rancher management plane and meta proxy — Place Rancher behind VPN, IP allowlists, or an identity-aware proxy. Block direct external access to /meta/ and /v3 paths at the reverse proxy. For a CRITICAL verdict, apply this within 3 days under the noisgate mitigation SLA.
3
CRITICAL 9.0→HIGH 8.4
SEVERITY REDUCED
Rotate all Rancher tokens, session cookies, and cloud credentials — Assume leaked credentials may already have been received by a third party. Rotate Rancher API tokens, clear session cookies, and rotate cloud credentials used by the meta proxy immediately.
4
CRITICAL 9.0→MEDIUM 6.5
SEVERITY REDUCED
Egress-allowlist Rancher server nodes to known cloud provider FQDNs — Restrict outbound HTTP/HTTPS from Rancher servers and pods to only trusted cloud provider endpoints. This breaks attacker-controlled destination hosts if the meta proxy can be coerced to arbitrary targets.
What doesn't work
  • 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.
04 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo known active exploitation. Mallory tracks 0 exploitation reports; no ransomware or campaign activity observed as of 2026-11-01.
CISA KEV statusNot listed in CISA Known Exploited Vulnerabilities; no federal deadline.
PoC availabilityNo public PoC found on GitHub, pocindex.io, ExploitDB, or Nuclei templates for CVE-2026-88811 at analysis time.
EPSS score and percentileEPSS not yet published or below FIRST reporting threshold; VulDB shows 0.00+ trend, indicating negligible mass-exploitation likelihood.
CVSS vector interpretationCVSS: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 rangesOfficial: 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 versions2.15.3, 2.14.7, 2.13.11; GitHub SA also lists 2.12.15 and 2.11.19.
Disclosure dateNVD published 2026-11-02; GitHub advisory published 2026-10-28.
Scanning / exposure dataNo public GreyNoise/Shodan/Censys mass-scan data shows broad exposure of Rancher meta proxy; Rancher management UI is usually not internet-facing.
Reporting researcher / orgNo individual researcher credited; disclosed through SUSE/GitHub security advisory channels.

Sources.

  1. NVD — CVE-2026-88811
  2. GitHub Security Advisory — Rancher credentials disclosed to third-party hosts by the Rancher Manager meta proxy
  3. Rapid7 vulnerability database — CVE-2026-88811
  4. Tenable — CVE-2026-88811
  5. VulDB — CVE-2026-88811
  6. Launchpad Bugs — CVE-2026-88811
  7. CCN-CERT vulnerability bulletin — CVE-2026-88811
  8. Mallory — Credential Disclosure in SUSE Rancher Manager Meta Proxy
05 · The Call

Final Verdict
= UNCHANGED to CRITICAL (9.0/10)

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.

06 · Verification

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.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/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