SUSE Rancher Flaw Lets Unauthenticated Attackers Plant Login-Page Script and Seize Kubernetes Fleets (CVE-2026-88804)

SUSE has fixed a critical flaw in Rancher Manager that turns an unauthenticated web request into control of every Kubernetes cluster Rancher manages. Tracked as CVE-2026-88804 (CVSS 3.1 score 9.6, published by SUSE as advisory GHSA-992f-xh8r-jg2f), the bug lets anyone who can reach the Rancher server rewrite a set of public UI settings. One of those settings is rendered as raw HTML on the login page. The attacker's script then runs in the Rancher origin for the next administrator who opens the login page, which can expose the local admin bootstrap password or hijack an admin session. Default deployments are affected. Upgrade to v2.15.2, v2.14.6, v2.13.10, v2.12.14 or v2.11.18 now, and check the listed settings for tampering.

Attack mechanics: read-only routes that could be written to

According to SUSE's advisory, Rancher Manager exposes API routes that serve "a small set of public UI settings without authentication." These are the values the login page needs before anyone has signed in, such as branding and banners. The routes were meant to be read-only. However, "a request-parsing behavior in the underlying Norman API framework allowed a remote, unauthenticated user with network access to the Rancher server to modify the values of those public settings."

The fix shows what that behaviour was. SUSE says patched releases strip "request parameters that could reinterpret the effective HTTP method of a request" before the request reaches the management API handler. In other words, an unauthenticated read request could be turned into a write through an HTTP method-override parameter. SUSE has not published the exact parameter or request format, and we do not reproduce one here.

The flaw is classified as CWE-862 (Missing Authorization) and CWE-79 (Cross-site Scripting). It is serious because of what sits in the settings store:

1. The attacker sends an unauthenticated request to a public /v3/settings/* route that the Norman router processes as a write.
2. The attacker stores HTML and script in a setting that "is rendered as raw HTML on the Rancher login page."
3. A legitimate user opens the login page. No other action is needed, and the stored content runs in the Rancher origin.
4. The script can capture the local administrator bootstrap password or hijack an active administrator session. SUSE says this leads to "full administrative control of the Rancher installation and of the downstream clusters it manages."

SUSE lists only two preconditions: network access to the Rancher endpoint, and a legitimate user later opening the login page. No Rancher account, credentials or prior privileges are needed, and "no non-default feature or setting needs to be enabled." The CVSS vector reflects this: network attack, low complexity, no privileges, user interaction required, and a changed scope, because control of Rancher extends to every managed cluster.

Severity scoring

Exploitation status

SUSE's advisory makes no statement about in-the-wild exploitation, and CVE-2026-88804 was not in CISA's Known Exploited Vulnerabilities catalog at the time of writing. The advisory was published on GitHub on 23 September 2026, and the CVE record was published on 28 September. SUSE credits the researcher @StopWar with the discovery.

Rancher is often exposed to the internet so that developers and CI systems can reach it, and the attack needs no credentials. Once the advisory is public, attackers can work out the general technique from the description of the fix. Treat any internet-reachable Rancher server that is still unpatched as at risk.

Affected and fixed Rancher versions

SUSE says the change is server-side only and does not alter the values or behaviour of the settings, so no user action beyond upgrading is required. Versions older than 2.11 are not listed in the advisory. Check SUSE's support matrix and lifecycle pages if you run an end-of-life line.

Defensive playbook

1. Confirm your Rancher version

Run this against the Rancher local (management) cluster:

# Helm release and chart version
helm list -n cattle-system

# Image tag of the running Rancher deployment
kubectl -n cattle-system get deploy rancher \
  -o jsonpath='{.spec.template.spec.containers[0].image}{"\n"}'

2. Upgrade to a fixed release

Follow Rancher's documented Helm upgrade procedure, with a backup taken first using the Rancher Backups operator. Use the chart repository you originally installed from, and the fixed version for your release line:

helm repo update
helm upgrade rancher <your-rancher-chart-repo>/rancher \
  --namespace cattle-system \
  -f values.yaml \
  --version 2.15.2   # or 2.14.6 / 2.13.10 / 2.12.14 / 2.11.18

3. Check the public UI settings for tampering

SUSE names ui-pl, first-login, ui-banners, ui-brand, ui-issues and ui-default-landing as settings to review. Rancher stores settings as cluster-scoped settings.management.cattle.io resources in the local cluster:

for s in ui-pl first-login ui-banners ui-brand ui-issues ui-default-landing; do
  echo "===== $s"
  kubectl get settings.management.cattle.io "$s" -o yaml
done

Look for unexpected value content, especially HTML tags, <script>, event-handler attributes such as onerror=, or external URLs, and for recent changes in metadata.managedFields timestamps. Compare the values with your known branding configuration and restore anything unexpected.

4. If tampering is suspected

1. Restore the affected settings to known-good values.
2. Rotate the local administrator password.
3. Invalidate existing administrator tokens and sessions, as SUSE recommends. Review API tokens created around the suspected tampering window.
4. Audit downstream clusters for changes made with Rancher admin credentials since the earliest suspicious setting change: new cluster role bindings, new users or tokens, and unfamiliar workloads.

5. Interim mitigations if you cannot upgrade immediately

SUSE says no workaround fully addresses the issue, but exposure can be reduced:

• Restrict network access to the Rancher server endpoint to trusted networks and clients.
• Put Rancher behind a reverse proxy, WAF or ingress policy that rejects requests to the unauthenticated /v3/settings/* endpoints if they carry HTTP method-override parameters or request bodies, allowing only plain read requests.
• Monitor the public UI settings listed above for unexpected changes.

6. Log-hunting starting points

SUSE has published no IOCs. The following ingress or proxy log searches are based only on the request characteristics the advisory describes. Expect noise from authenticated administrators who change settings legitimately, and correlate hits with authentication context:

# Requests to settings routes that carry a query string (possible method override)
grep -E '"(GET|HEAD|POST|PUT) /v3/settings/[^ "]*\?' /var/log/ingress/access.log

# Non-GET requests to settings routes
grep -E '"(POST|PUT|PATCH|DELETE) /v3/settings/' /var/log/ingress/access.log

Adjust the log path for your ingress controller or load balancer.