GHSA-mhc6-2gfq-xx62 CVE-2026-44939 GO-2026-5875
Rancher vulnerable to command injection through unsanitized YAML parameter
- Severity
- 0.0 / 10
- Critical · CVSS 4.0
- Exploit chance (EPSS)
- 1.28%
- Chance of exploitation in the next 30 days. Higher than 70.00% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-95 Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')
- Fix
2.14.2- Upgrade github.com/rancher/rancher to this version or later
Description
Impact
A critical command injection vulnerability has been identified in the Rancher Manager cluster import endpoint /v3/import/{token}_{clusterId}.yaml through unsanitized YAML parameters. This endpoint accepts an authImage query parameter that is rendered without sanitization into a generated Kubernetes manifest template. By including URL-encoded newlines in the parameter value, an attacker can break out of the image: field to inject arbitrary YAML keys and malicious configurations, such as commands to execute malicious containers.
Exploitation of this vulnerability requires the following conditions to be met:
- Attackers must obtain a valid cluster registration token (these tokens may be exposed, for example, through documentation, screenshots, or insecure communication channels).
- The victim’s cluster operator must execute
kubectl applyagainst a maliciously crafted URL.
When a victim applies this compromised manifest using kubectl apply, a DaemonSet is deployed with the injected configuration. This DaemonSet:
- Runs on all control-plane nodes with
hostNetwork: trueenabled. - Uses the
cattleservice account, which possessescluster-adminprivileges. - Mounts
/etc/kubernetesdirectly from the host. - Executes attacker-controlled commands via the injected
command:field.
An attacker who successfully exploits this vulnerability could:
- Achieve full control over downstream Kubernetes clusters.
- Execute arbitrary code on control-plane nodes with elevated privileges.
- Access sensitive cluster secrets and configurations via the privileged service account.
- Disrupt cluster operations by manipulating critical control-plane workloads.
- Establish persistent access through the deployed DaemonSet.
Note: If you believe that you might have been impacted by this vulnerability, it's highly advised to review your clusters' logs and deployment logs for signs of malicious deployments and to rotate all service accounts and credentials that might have been exposed in such a scenario.
Please refer to the associated MITRE ATT&CK - Technique - Deploy Container for further information about this category of attack.
Patches
This vulnerability is addressed by validating the authImage parameter to ensure it contains only valid OCI image reference characters, rejecting any input containing newlines, whitespace, or other characters that could break YAML syntax.
Patched versions of Rancher include release v2.14.2, v2.13.6, v2.12.10, v2.11.14 and v2.10.12.
Workarounds
If upgrading to a patched version immediately is not feasible, users are encouraged to apply the following workaround:
- Review the
kube-api-authDaemonSet: Inspect downstream clusters for thekube-api-authDaemonSet within thecattle-systemnamespace (which targets control-plane nodes). Review this resource configuration carefully for:- Unexpected
command:orargs:fields in the container specification. - References to non-standard or suspicious container images.
- Any modifications occurring after the initial cluster import.
- Unexpected
- Validate manifest integrity: Before running
kubectl applyon any import manifests, verify that the source URLs originate from trusted sources and match expected patterns.
Credits
This security issue was reported by the following collaborators according to our responsible disclosure policy:
- Radisauskas Arnoldas from NATO and the NATO Cyber Security Centre (NCSC).
- Michael Wollner from Deutsche Telekom AG.
References
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 versions
Go
| Package | Vulnerable | Fixed in |
|---|---|---|
| github.com/rancher/rancher | >= 2.14.0, < 2.14.2 |
2.14.2 |
| github.com/rancher/rancher | >= 2.13.0, < 2.13.6 |
2.13.6 |
| github.com/rancher/rancher | >= 2.12.0, < 2.12.10 |
2.12.10 |
| github.com/rancher/rancher | >= 2.11.0, < 2.11.14 |
2.11.14 |
| github.com/rancher/rancher | >= 2.10.0, < 2.10.12 |
2.10.12 |
| github.com/rancher/rancher | < 0.0.0-20260617231817-2aa77eb283e7 |
0.0.0-20260617231817-2aa77eb283e7 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
github.com/rancher/rancher Go → 2.14.2
- go
go get github.com/rancher/rancher@v2.14.2 && go mod tidy
Severity breakdown
CVSS 4.0 0.0
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
- Attack vector
- Network
- Attack complexity
- Low
- Attack requirements
- None
- Privileges required
- None
- User interaction
- Passive
- Confidentiality (vulnerable system)
- High
- Integrity (vulnerable system)
- High
- Availability (vulnerable system)
- High
- Confidentiality (subsequent systems)
- High
- Integrity (subsequent systems)
- High
- Availability (subsequent systems)
- High
CVSS 3.1 9.6
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- None
- User interaction
- Required
- Scope
- Changed
- Confidentiality
- High
- Integrity
- High
- Availability
- High
Weakness
CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes code syntax before using the input in a dynamic evaluation call (e.g. "eval").
How to prevent it
- Architecture and Design, Implementation: If possible, refactor your code so that it does not need to use eval() at all.
- Implementation: Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
- Implementation: Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180, CWE-181). Make sure that your application does not inadvertently decode the same input twice (CWE-174). Such errors could be used to bypass allowlist schemes by introducing dangerous inputs after they have been checked. Use libraries such as the OWASP ESAPI Canonicalization control. Consider performing repeated canonicalization until your input does not change any more. This will avoid double-decoding and similar scenarios, but it might inadvertently modify inputs that are allowed to contain properly-encoded dangerous content.
- Implementation: For Python programs, it is frequently encouraged to use the ast.literal_eval() function instead of eval, since it is intentionally designed to avoid executing code. However, an adversary could still cause excessive memory or stack consumption via deeply nested structures [REF-1372], so the python documentation discourages use of ast.literal_eval() on untrusted data [REF-1373].
References
Advisories
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-4j6x-2764-m8gh Rancher has over-inclusive team membership expansion in GitHub App authentication provider | High | Also affects github.com/rancher/rancher |
| GHSA-vx8h-4prv-g744 Rancher has Privilege Escalation from Project Owner to Host | High | Also affects github.com/rancher/rancher |
| GHSA-5v3h-x4wf-5c35 Rancher Extensions have arbitrary file access via path traversal | High | Also affects github.com/rancher/rancher |
| GHSA-gqf8-rvrh-g7w6 Rancher cloud credentials can be used through proxy API by users without access | Critical | Also affects github.com/rancher/rancher |
| GHSA-hwm2-4ph6-w6m5 Rancher's restricted PodSecurityPolicy does not prevent containers from running as a privileged user | High | Also affects github.com/rancher/rancher |
| GHSA-mc24-7m59-4q5p Rancher CLI skips TLS verification on Rancher CLI login command | Medium | Also affects github.com/rancher/rancher |
| GHSA-mw39-9qc2-f7mg Rancher exposes sensitive information through audit logs | Medium | Also affects github.com/rancher/rancher |
| GHSA-j4vr-pcmw-hx59 Rancher user retains access to clusters despite Global Role removal | Medium | Also affects github.com/rancher/rancher |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor