CVE-2024-22030 — rancher
HIGHCVE-2024-22030 is a high-severity (CVSS 8) CWE-295 vulnerability in github.com/rancher/rancher. A fix is available for github.com/rancher/rancher — see the affected versions and patch details below.
Rancher agents can be hijacked by taking over the Rancher Server URL
Exploitation Status
No confirmed exploitation observed yet
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2024-22030.
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.
How urgent is this, really
CVE-2024-22030 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 378,156 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
github.com/rancher/rancher🐹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
A vulnerability has been identified within Rancher that can be exploited in narrow circumstances through a man-in-the-middle (MITM) attack. An attacker would need to have control of an expired domain or execute a DNS spoofing/hijacking attack against the domain to exploit this vulnerability. The targeted domain is the one used as the Rancher URL.
SUSE is unaware of any successful exploitation of this vulnerability, which has a high complexity bar.
Please consult the associated MITRE ATT&CK - Technique - Adversary-in-the-Middle for further information about this attack category.
Patches
A new setting, agent-tls-mode, was added, which allows users to specify if agents will use strict certificate verification when connecting to Rancher. The field can be set to strict (which requires the agent to verify the certificate using only the Certificate Authority in the cacerts setting) or system-store (which allows the agent to verify the certificate using any Certificate Authority in the operating system's trust store). This setting will default to strict on new installs of Rancher v2.8.6, v2.9.0, and newer versions. When upgrading from a prior version, the current value will be kept. If updating from older versions, the settings must be manually configured.
Important: For non-Windows nodes, this is fixed since v2.8.6 and v2.9.0. For Windows nodes, this is fully fixed starting with v2.8.8 and v2.9.2
Patched versions include releases v2.8.8 and v2.9.2.
For non-Windows nodes, the fix was released with v2.7.15. However, if you are running Rancher v2.7.x and have Windows nodes, you must follow the below workaround to address this issue on those nodes.
Workarounds
If you can't update, please follow the standard security practices including:
- Properly control the expiration and ownership of the domain used as the Rancher URL (the
server-urlof the Rancher cluster). - Enabling DNSSEC as a way to protect against DNS spoofing or hijacking attacks.
- Properly clean up and decommission unused clusters and downstream clusters, instead of leaving them behind. For example, downstream clusters which are alive while the main Rancher server is no longer available.
In some cases, Windows nodes added to RKE2 clusters may not be automatically updated with the desired agent-tls-mode. Windows clusters running at least the August patches (v1.27.16, v1.28.13, v1.29.8, v1.30.4) will be automatically updated. For Windows nodes running older versions of RKE2, this issue can be manually resolved by following these instructions.
If you are running Rancher v2.7.x Windows nodes will not automatically update, and you must follow the above instructions, with the following notes:
- This needs to be done for all existing Windows nodes and any new nodes provisioned.
- You must omit the
DownloadWinsflag, and must instead manually download therancher-winsversion 0.4.18, or greater, from its GitHub repository and place it in the required directories: a.c:\Windowsb.c:\user\local\bin - You must restart the nodes after running the script, simply restarting
rancher-winsor RKE2 will result in pod networking errors. The only scenario where you do not need to completely restart the node is if the cluster is running versionv1.27.16or higher.
Credits
This issue was found and reported by Jarkko Vesiluoma from Redtest Security.
For more information
If you have any questions or comments about this advisory:
- Reach out to the SUSE Rancher Security team for security related inquiries.
- Open an issue in the Rancher repository.
- Verify with our support matrix and product support lifecycle.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/rancher/rancher | ≥ 2.7.0&&< 2.7.15 | 2.7.15go get github.com/rancher/rancher@v2.7.15 |
| 🐹Go | github.com/rancher/rancher | ≥ 2.8.0&&< 2.8.8 | 2.8.8go get github.com/rancher/rancher@v2.8.8 |
| 🐹Go | github.com/rancher/rancher | ≥ 2.9.0&&< 2.9.2 | 2.9.2go get github.com/rancher/rancher@v2.9.2 |
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, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/rancher/rancher to 2.7.15 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2024-22030 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 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2024-22030 can be triaged on real exposure rather than presence alone.
Tailored to CVE-2024-22030. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2024-22030 in your dependencies?
O3 Security finds CVE-2024-22030 across Go dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.