GHSA-g7j7-h4q8-8w2f
CRITICALRancher API and cluster.management.cattle.io object vulnerable to plaintext storage and exposure of credentials
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
github.com/rancher/rancher🐹github.com/rancher/rancherReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Impact
An issue was discovered in Rancher versions up to and including 2.5.15 and 2.6.6 where sensitive fields, like passwords, API keys and Rancher's service account token (used to provision clusters), were stored in plaintext directly on Kubernetes objects like Clusters, for example cluster.management.cattle.io. Anyone with read access to those objects in the Kubernetes API could retrieve the plaintext version of those sensitive data.
The exposed credentials are visible in Rancher to authenticated Cluster Owners, Cluster Members, Project Owners, Project Members and User Base on the endpoints:
/v1/management.cattle.io.catalogs/v1/management.cattle.io.cluster/v1/management.cattle.io.clustertemplates/v1/management.cattle.io.notifiers/v1/project.cattle.io.sourcecodeproviderconfig/k8s/clusters/local/apis/management.cattle.io/v3/catalogs/k8s/clusters/local/apis/management.cattle.io/v3/clusters/k8s/clusters/local/apis/management.cattle.io/v3/clustertemplates/k8s/clusters/local/apis/management.cattle.io/v3/notifiers/k8s/clusters/local/apis/project.cattle.io/v3/sourcecodeproviderconfigs
Sensitive fields are now stripped from Clusters and other objects and moved to a Secret before the object is stored. The Secret is retrieved when the credential is needed. For objects that existed before this security fix, a one-time migration happens on startup.
Important:
- The exposure of Rancher's
serviceAccountTokenallows any standard user to escalate its privileges to cluster administrator in Rancher. - For the exposure of credentials not related to Rancher, the final impact severity for confidentiality, integrity and availability is dependent on the permissions that the leaked credentials have on their own services.
The fields that have been addressed by this security fix are:
Notifier.SMTPConfig.PasswordNotifier.WechatConfig.SecretNotifier.DingtalkConfig.SecretCatalog.Spec.PasswordSourceCodeProviderConfig.GithubPipelineConfig.ClientSecretSourceCodeProviderConfig.GitlabPipelineConfig.ClientSecretSourceCodeProviderConfig.BitbucketCloudPipelineConfig.ClientSecretSourceCodeProviderConfig.BitbucketServerPipelineConfig.PrivateKeyCluster.Spec.RancherKubernetesEngineConfig.BackupConfig.S3BackupConfig.SecretKeyCluster.Spec.RancherKubernetesEngineConfig.PrivateRegistries.PasswordCluster.Spec.RancherKubernetesEngineConfig.Network.WeaveNetworkProvider.PasswordCluster.Spec.RancherKubernetesEngineConfig.CloudProvider.VsphereCloudProvider.Global.PasswordCluster.Spec.RancherKubernetesEngineConfig.CloudProvider.VsphereCloudProvider.VirtualCenter.PasswordCluster.Spec.RancherKubernetesEngineConfig.CloudProvider.OpenstackCloudProvider.Global.PasswordCluster.Spec.RancherKubernetesEngineConfig.CloudProvider.AzureCloudProvider.AADClientSecretCluster.Spec.RancherKubernetesEngineConfig.CloudProvider.AzureCloudProvider.AADClientCertPasswordCluster.Status.ServiceAccountTokenClusterTemplate.Spec.ClusterConfig.RancherKubernetesEngineConfig.PrivateRegistries.PasswordClusterTemplate.Spec.ClusterConfig.RancherKubernetesEngineConfig.Network.WeaveNetworkProvider.PasswordClusterTemplate.Spec.ClusterConfig.RancherKubernetesEngineConfig.CloudProvider.VsphereCloudProvider.Global.PasswordClusterTemplate.Spec.ClusterConfig.RancherKubernetesEngineConfig.CloudProvider.VsphereCloudProvider.VirtualCenter.PasswordClusterTemplate.Spec.ClusterConfig.RancherKubernetesEngineConfig.CloudProvider.OpenstackCloudProvider.Global.PasswordClusterTemplate.Spec.ClusterConfig.RancherKubernetesEngineConfig.CloudProvider.AzureCloudProvider.AADClientSecretClusterTemplate.Spec.ClusterConfig.RancherKubernetesEngineConfig.CloudProvider.AzureCloudProvider.AADClientCertPassword
Patches
Patched versions include releases 2.5.16, 2.6.7 and later versions.
After upgrading to a patched version, it is important to check for the SecretsMigrated condition on Clusters, ClusterTemplates, and Catalogs to confirm when secrets have been fully migrated off of those objects and the objects scoped within them (Notifiers and SourceCodeProviderConfigs).
Workarounds
Limit access in Rancher to trusted users. There is not a direct mitigation besides upgrading to the patched Rancher versions.
Important:
- It is highly advised to rotate Rancher's
serviceAccountToken. This rotation is not done by the version upgrade. Please see the helper script below. - The local and downstream clusters should be checked for potential unrecognized services (pods), users and API keys.
- It is recommended to review for potential leaked credentials in this scenario, that are not directly related to Rancher, and to change them if deemed necessary.
The script available in rancherlabs/support-tools/rotate-tokens repository can be used as a helper to rotate the service account token (used to provision clusters). The script requires a valid Rancher API token, kubectl access to the local cluster and the jq command.
Credits
We would like to recognize and appreciate Florian Struck (from Continum AG) and Marco Stuurman (from Shock Media B.V.) for the responsible disclosure of this security issue.
For more information
If you have any questions or comments about this advisory:
- Reach out to SUSE Rancher Security team for security related inquiries.
- Open an issue in Rancher repository.
- Verify our support matrix and product support lifecycle.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/rancher/rancher | ≥ 2.5.0&&< 2.5.16 | 2.5.16 |
| 🐹Go | github.com/rancher/rancher | ≥ 2.6.0&&< 2.6.7 | 2.6.7 |
Research use only. For defensive security, authorized penetration testing, and academic research only. Never execute exploit code against systems without explicit written authorization.
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/rancher/rancher. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update github.com/rancher/rancher to 2.5.16 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-g7j7-h4q8-8w2f is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-g7j7-h4q8-8w2f is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-g7j7-h4q8-8w2f. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-g7j7-h4q8-8w2f in your dependencies?
O3 detects GHSA-g7j7-h4q8-8w2f across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.