Plaintext Rancher registration tokens enable rogue node registration

Rancher issues long-lived registration tokens to authenticate nodes and agents joining a downstream cluster. These tokens were stored and exposed in plaintext with no expiration, so a malicious user could obtain one either through the Rancher API, etcd, stored automation, or direct file access on a node, and could use it at any time to register a rogue node into the cluster.

The affected package is github.com/rancher/rancher. The normalized record marks the default status as unaffected outside the listed ranges:

• 2.14 branch: versions from 2.14.0 through before 2.14.4 are affected. The advisory identifies 2.14.4 as patched.
• 2.13 branch: versions from 2.13.0 through before 2.13.8 are affected. The advisory identifies 2.13.8 as patched.

The supplied record does not establish the status of branches outside these ranges. Do not treat every unlisted version as independently verified safe.

Rancher issues registration tokens to authenticate nodes and agents joining a downstream cluster. In affected versions, ClusterRegistrationToken credentials were stored in the plaintext status.Token field of the CRD and returned through the Rancher API. The same class of credential could also persist in copied registration commands in shell history, CI/CD systems, infrastructure-as-code, etcd, or etcd backups.

For the v2prov provisioning path used with RKE2/K3s, the system agent install script at /usr/local/custom_script/install.sh was written to the downstream node with 0644 permissions and embedded CATTLE_TOKEN, the server URL, and the CA checksum. A local user or process without root privileges could therefore read the credential when it had suitable local access.

The attacker must first obtain a valid registration token. The advisory identifies cluster-admin-level Rancher API access, etcd, stored automation, copied registration commands, or non-root local code execution on a node provisioned with v2prov as possible acquisition paths. The attacker can then use the token to register a rogue node with controlplane or etcd roles, potentially gaining full administrative control of the affected downstream cluster. The available evidence does not establish that every deployment uses both exposure surfaces.

The record characterizes the attack as local, with low complexity, low required privileges, and no user interaction. However, the token may also be obtained through administrative or stored-data surfaces such as the Rancher API, etcd, automation, shell history, and infrastructure-as-code, so practical reachability depends on the access available in the deployment.

The attacker must possess a valid token before registering a node; the available evidence does not describe a credential-free registration path. Because the token does not expire, a copied token can remain usable until it is deleted or replaced. The supplied record marks public exploit as false and has no known-exploited designation, but that does not prove that abuse has not occurred.

An attacker who obtains a valid token can register a node in the downstream cluster with a controlplane or etcd role. The advisory states that this can provide full administrative control of the affected cluster, including potential access to or modification of PKI, etcd data, secrets, and workloads.

Possible consequences include loss of confidentiality, unauthorized changes to data or configuration, and service disruption. The impact can cross from the token's storage location into downstream infrastructure managed by Rancher. The key limitation is that the attacker still needs a valid token; the evidence does not show that network access to Rancher alone is sufficient.

If a registration token is exposed, an organization may lose control of the downstream cluster to which that token grants access. A rogue node with controlplane or etcd privileges could potentially:

• Access or modify etcd data, secrets, workloads, and cluster PKI.
• Alter Kubernetes configuration or workloads, affecting data and service integrity.
• Disrupt cluster operations and reduce service availability.
• Extend the impact from the location where the token was exposed to downstream resources managed by Rancher.

These are possible consequences of registering a node with the stated roles, not evidence that a particular organization or cluster was breached. Incident review should include token copies in etcd, automation, CI/CD, infrastructure-as-code, and shell history.

1. Upgrade according to the deployed branch: update the 2.14 branch to 2.14.4, or update the 2.13 branch to 2.13.8. These are the confirmed fixes.
2. While patching is pending, reduce token exposure. Set /usr/local/custom_script/install.sh on v2prov-provisioned nodes to 0600, while noting that containers with a host path mount to /usr/local may still read the file as root.
3. Restrict local access on downstream nodes, especially untrusted workload access to host paths. Limit access to etcd backups, infrastructure-as-code, CI/CD configuration, and shell history.
4. If a system CRT is known or suspected to be compromised, delete it to force a new token, update the cluster agent credential, and redeploy the agent. New connections using the old token are rejected after rotation, but an existing tunnel is not immediately dropped; restarting the agent alone does not fetch the replacement credential.
5. Treat these measures as risk reduction rather than a complete workaround. After remediation, recheck existing CRTs and bootstrap files because a token may have been copied outside Rancher.

Review the following evidence sources:

1. Inventory the version of github.com/rancher/rancher and determine whether the deployment falls within an affected branch.
2. Inspect ClusterRegistrationToken resources to determine whether status.Token contains the real credential in plaintext or only the {token} placeholder. In patched deployments, the real value is stored in a Kubernetes Secret and access is controlled through RBAC.
3. On downstream nodes provisioned with v2prov, check the existence, permissions, and contents of /usr/local/custom_script/install.sh, including whether it contains CATTLE_TOKEN. World-readable permissions require remediation, but do not by themselves prove that the token was retrieved.
4. Review access to and changes in etcd, etcd backups, infrastructure-as-code repositories, CI/CD configuration, and shell history where registration commands may have been stored.
5. Compare the downstream cluster inventory and node roles with approved state, looking for unexpected controlplane or etcd nodes. This is precautionary monitoring, not a confirmed indicator from the advisory.

The absence of suspicious logs or unexpected nodes does not prove that a registration token was not exposed.