Skip to content

GHSA-mhc6-2gfq-xx62 CVE-2026-44939 GO-2026-5875

Rancher vulnerable to command injection through unsanitized YAML parameter

Critical Go
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 apply against 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: true enabled.
  • Uses the cattle service account, which possesses cluster-admin privileges.
  • Mounts /etc/kubernetes directly 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-auth DaemonSet: Inspect downstream clusters for the kube-api-auth DaemonSet within the cattle-system namespace (which targets control-plane nodes). Review this resource configuration carefully for:
    • Unexpected command: or args: fields in the container specification.
    • References to non-standard or suspicious container images.
    • Any modifications occurring after the initial cluster import.
  • Validate manifest integrity: Before running kubectl apply on 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:

Affected versions

Go

PackageVulnerableFixed 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

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy 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
Is this in your code?

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