On 23 September 2026 Rancher shipped v2.15.2, v2.14.6, v2.13.10, v2.12.14 and v2.11.18 and published CVE-2026-88804, rated critical. Rancher serves a few UI settings without authentication so the login page can render before anyone signs in. Those routes were meant to be read-only, but a request-parsing behavior in the Norman API framework let an unauthenticated request change them. One of those settings is rendered as raw HTML on the login page.
The same day, Rancher published a second advisory, CVE-2026-88805: logging out didn't revoke the server-side session for users of OIDC-style providers.
What's affected
CVE-2026-88804 (GHSA-992f-xh8r-jg2f, critical, CVSS 4.0 vector AV:N/AC:L/AT:N/PR:N/UI:P):
| Line | Affected | Fixed |
|---|---|---|
| 2.15 | v2.15.0 to before v2.15.2 | v2.15.2 |
| 2.14 | v2.14.0 to before v2.14.6 | v2.14.6 |
| 2.13 | v2.13.0 to before v2.13.10 | v2.13.10 |
| 2.12 | v2.12.0 to before v2.12.14 | v2.12.14 |
| 2.11 | v2.11.0 to before v2.11.18 | v2.11.18 |
The advisory says default configurations are affected and no special setting is needed. The attacker needs network access to the Rancher server and nothing else. A legitimate user then has to open the login page. From there, the advisory lists the consequences: disclosure of the local administrator bootstrap password or hijacking of an active administrator session, "and therefore to full administrative control of the Rancher installation and of the downstream clusters it manages." The reporter is @StopWar.
CVE-2026-88805 (GHSA-6vpq-mf48-9794, high) affects only v2.15.0 to before v2.15.2. When a user logged out, the browser cookies were cleared but the server-side session token stayed valid until its TTL or idle timeout. It matters only if an attacker already has a stolen session token, and only for auth providers that issue external session tokens, such as Generic OIDC, Keycloak or Azure AD. Legacy Rancher API tokens were revoked correctly.
How to check if you're exposed
Rancher version, from the local cluster:
kubectl -n cattle-system get deploy rancher \
-o jsonpath='{.spec.template.spec.containers[0].image}{"\n"}'
Check the public UI settings the advisory names for values you didn't set. These are the ones an attacker could have rewritten:
kubectl get settings.management.cattle.io \
ui-pl first-login ui-banners ui-brand ui-issues ui-default-landing \
-o custom-columns=NAME:.metadata.name,VALUE:.value
Anything containing HTML tags, script, or an unfamiliar URL in a setting that should hold a product name or a JSON banner config is a red flag. Compare against a known-good export or your Helm values.
Then check your ingress or load balancer logs for requests to /v3/settings/ that were not plain reads: any method other than GET, any request with a body, or query parameters that override the HTTP method. The advisory names method-override parameters as the vector its proxy workaround should block.
What to do now
- Upgrade to v2.15.2, v2.14.6, v2.13.10, v2.12.14 or v2.11.18. The fix is server-side and needs no configuration change.
- If any public setting looks wrong, treat it as a compromise. The advisory's guidance: restore the values, rotate the local administrator password, and invalidate existing administrator tokens and sessions. Then review downstream cluster access, since Rancher holds credentials for every managed cluster.
- Until you can upgrade, restrict who can reach Rancher. The advisory suggests limiting network access to trusted clients, and putting a reverse proxy, WAF or ingress rule in front that only allows plain read requests to the unauthenticated
/v3/settings/endpoints. - For CVE-2026-88805 on 2.15.0 or 2.15.1, shorten the session TTL and idle timeout, and if you suspect a stolen session, delete the user's tokens through the Rancher API or disable the account. Logging out won't do it on those versions.
- Keep Rancher off the public internet where you can. The bug needed nothing but a network path, and a management plane for many clusters is worth hiding behind a VPN or identity-aware proxy.
Why it matters
Unauthenticated endpoints are where small parsing differences become critical. A route that only ever serves a GET looks harmless, so it gets little review. If the framework underneath honors a method override, that GET route becomes a write route, and nobody wrote the permission check because nobody expected a write. Any framework feature that changes the meaning of a request before routing deserves a deliberate decision on public paths.
Rancher's position makes it a high-value target. It holds admin credentials for every downstream cluster, so one stored script on the login page is a path to all of them. Management planes deserve the network isolation and monitoring you'd give a domain controller.
Try it yourself
Export the six settings above to a file today and commit it somewhere private. Write a small scheduled job that runs the same kubectl get and diffs the output against your saved copy, alerting on any change. It's a cheap tripwire for this bug class, and it will also catch ordinary unreviewed changes.
Click through it at your own pace, or open it full screen.
Quick check
Does CVE-2026-88804 require a Rancher account?
No. The advisory says no account, credentials or prior privileges are needed, only network access to the Rancher server. A legitimate user then has to open the login page for the stored content to run.
Which Rancher versions are affected by the logout issue, CVE-2026-88805?
Only v2.15.0 and v2.15.1. It's fixed in v2.15.2, and only affects auth providers that issue external session tokens, such as OIDC-based providers.
What should you do if a public UI setting was changed before you upgraded?
Restore the setting, rotate the local administrator password, and invalidate administrator tokens and sessions, as the advisory recommends. Then review access to the downstream clusters Rancher manages.
