SURIQ
Patching Rancher to 2.14.4 or 2.13.8 this week closes a plaintext credential leak, but it does not undo the leak. That distinction is the whole job here.
On July 31 SUSE disclosed CVE-2026-55997, a high-severity flaw (CVSS 8.8) in Rancher, the Kubernetes management platform SUSE maintains. The MITRE record went live on August 5. The short version: the tokens that authenticate a machine when it joins one of your clusters were stored and written in plaintext, and they never expired. Anyone who got hold of one could use it at any point in the future to register a brand new node into the cluster, and give that node control-plane or etcd roles. A node with those roles is not a tenant. It is the cluster: its PKI, its etcd data, its secrets, its workloads.
What actually leaked, and from where
A Rancher registration token is a long-lived bearer credential. Present it, and the control plane trusts the machine on the other end enough to enroll it as a cluster member. Two things went wrong at once. First, Rancher kept the token in cleartext in the status.Token field of the ClusterRegistrationToken object, readable through the Rancher API and anything with visibility into the backing etcd. Second, on nodes provisioned through the newer v2prov path, the install script that carried bootstrap credentials was written to disk world-readable, mode 0644, so any local non-root account on that host could read it.
That makes the exposure surface wider than an "attacker needs cluster-admin" summary suggests. Reading the token straight from the API does need privileged Rancher access. But the same never-expiring secret also lives in quieter places: an etcd snapshot sitting in an object-storage bucket, a Terraform state file or a CI/CD job log that captured the registration command, a copy-pasted enrollment command in someone's shell history, or the install script on any node an attacker gets a low-privilege foothold on. The token does not care where it was copied from. Because it had no expiry, a token that leaked into a build log six months ago still works today.
| Release line | Affected versions | Fixed in |
|---|---|---|
| Rancher 2.14 | 2.14.0 through 2.14.3 | 2.14.4 |
| Rancher 2.13 | 2.13.0 through 2.13.7 | 2.13.8 |
Upgrade closes the door; rotating the tokens is the other half
Here is the trap. The fix moves tokens into Kubernetes Secrets, hardens the install-script permissions to 0600, and adds optional time-based token rotation. All good. But upgrading does nothing to the tokens that already left. If one was captured while you were running an affected version, it stays valid after you patch, and it still registers a rogue admin node.
Treat the upgrade as step one of two:
- Upgrade every Rancher management server to 2.14.4 or 2.13.8. Do the internet-reachable ones first.
- Delete the existing cluster registration tokens to force regeneration, and redeploy the cluster agents so nodes re-enroll against fresh secrets. Rancher's fix ships the rotation machinery; use it.
- Lock down the passive copies you cannot un-leak. Restrict who can read etcd backups, infrastructure-as-code state, and CI/CD configuration, and scrub registration commands out of logs and shell history.
- On existing nodes, if you cannot repave immediately, tighten the provisioning script yourself:
chmod 0600on the install script and limit local shell access to downstream nodes.
We covered the previous SUSE Rancher batch in July, a pair of critical command-injection and cross-tenant flaws. This one is quieter but has the same shape: a small foothold, or a stale artifact, turning into control of the whole cluster.
How you would know
No public exploit is circulating, and the flaw is not on CISA's Known Exploited Vulnerabilities list as of August 5. That is the window to act in, not a reason to wait.
Detection here lives at the control plane, not the workload. Watch Rancher's own audit trail for node registrations you did not initiate, and for new nodes appearing with control-plane or etcd roles outside your provisioning pipeline. A managed detection setup that ingests cluster audit events and maps them to attacker techniques would flag an unexpected control-plane node joining as exactly the anomaly it is. The signal is not subtle once you look for it. Legitimate nodes join through your pipeline, on your schedule; a rogue enrollment does not.
The recurring lesson is older than this CVE. Bootstrap and join credentials get treated as configuration, not as secrets, so they end up in plaintext files, state, and logs with no lifetime. Puppet did a version of this by storing the very passwords it was told to hide in cleartext on managed nodes; an OpenShift tunnel accepted a stranger because one setting was missing. Long-lived bearer tokens sitting in readable places is the pattern. Rancher's move to Secrets storage and optional rotation is the right correction. The part it cannot do for you is invalidate what already leaked. That part is yours.