Like a building inspector who stamps any blueprint handed to them — even one with a hidden bomb shelter nobody asked for
CVE-2026-44939 is a command injection flaw in Rancher Manager's cluster import endpoint (/v3/import/{token}_{clusterId}.yaml). The authImage query parameter is rendered directly into a generated Kubernetes manifest template with zero sanitization. An attacker who obtains a valid cluster registration token can inject URL-encoded newlines (%0a) into authImage, breaking out of the image: YAML field to inject arbitrary keys — including command:, hostNetwork: true, and privileged container specs. When a cluster administrator runs kubectl apply -f against the poisoned URL, a malicious DaemonSet deploys across every node in the downstream cluster with full host-level privileges. Affected versions span Rancher 2.10.0–2.10.11, 2.11.0–2.11.13, 2.12.0–2.12.9, 2.13.0–2.13.5, and 2.14.0–2.14.1. Patched releases are 2.10.12, 2.11.14, 2.12.10, 2.13.6, and 2.14.2.
The GHSA advisory rates this CVSS 9.6 (v3.1) / 9.4 (v4.0) CRITICAL, and that is largely justified. The UI:R (user interaction required) component might tempt you to downgrade, but in the Rancher operational model, administrators *routinely* copy-paste kubectl apply commands from runbooks, Slack channels, wikis, and shared documentation — exactly the surfaces an attacker can poison. Moreover, Rancher registration tokens are long-lived, have historically leaked through audit logs (CVE-2024-58269) and plaintext storage (GHSA-7r53-jvhg-9jq4), and are embedded directly in the import URL itself. The 'social engineering' bar here is lower than a phishing email — it's 'swap a URL on a wiki page.' The blast radius — full compromise of every downstream Kubernetes cluster Rancher manages — is fleet-scale by definition. This is a real CRITICAL.
5 steps from start to impact.
Obtain a valid cluster registration token
/v3/import/{token}_{clusterId}.yaml), are long-lived by default, and have multiple documented leakage vectors. CVE-2024-58269 showed they leak through audit logs; GHSA-7r53-jvhg-9jq4 documented plaintext storage with no expiration. Tokens also surface in internal wikis, Slack messages, CI/CD pipelines, and screenshots shared in documentation.- Access to a leaked, shared, or intercepted cluster registration token
- The token must still be valid (default: no expiration)
- Tokens are not publicly enumerable — attacker needs an information disclosure path
- Organizations that rotate tokens or restrict API access reduce the attack surface
clusterregistrationtokens API calls for anomalous access patterns.Craft the poisoned import URL
authImage query parameter. The payload breaks out of the image: field and injects arbitrary YAML keys — typically a command: array, securityContext.privileged: true, and hostNetwork: true. This transforms the benign import manifest into a weaponized DaemonSet specification. No specialized tooling is needed; curl and a text editor suffice.- Knowledge of YAML injection technique (publicly documented in the GHSA)
- A valid token from Step 1
- Attack complexity is genuinely low — any competent attacker can craft this payload
- No public PoC automates the full chain yet, but the GHSA description is a recipe
Deliver the poisoned URL to a cluster administrator
kubectl apply. Attack vectors include modifying a shared wiki/runbook, intercepting a Slack or Teams message, compromising a CI/CD pipeline that automates cluster imports, or a targeted phishing message with the URL embedded. The key insight is that Rancher's import workflow *by design* involves copy-pasting a kubectl apply -f <URL> command.- Ability to modify a documentation source, intercept a communication channel, or send a convincing message to a Rancher admin
- Target admin must execute
kubectl applyagainst the URL
- Requires social engineering — not a fire-and-forget exploit
- Security-conscious teams that verify manifests before applying will catch the injection
- Kubectl warnings about applying from external URLs may alert careful operators
/v3/import/*.Malicious DaemonSet deploys across the downstream cluster
kubectl apply, Kubernetes creates the injected DaemonSet in the cattle-system namespace. Because it uses the cattle service account (which has cluster-admin equivalent privileges in downstream clusters), the DaemonSet deploys to every node with hostNetwork: true and a privileged security context. The attacker's container now has root-level access to the host network stack and filesystem on every node.- The victim executed
kubectl applyin Step 3 - The downstream cluster accepts the manifest (default behavior)
- Admission controllers (OPA Gatekeeper, Kyverno) that block privileged DaemonSets in
cattle-systemwould stop this - Pod Security Admission in
Restrictedmode oncattle-systemwould block it, but almost no one does this because Rancher's own agents require elevated privileges in this namespace
cattle-system. kubectl get ds -n cattle-system reveals the injected workload.Full cluster compromise and lateral movement
/var/run/secrets, accesses etcd data, and exfiltrates secrets from the Kubernetes API. Because Rancher manages multiple downstream clusters from a single control plane, the attacker can pivot to other clusters using the cattle service account's cross-cluster management credentials. The blast radius is every Kubernetes cluster managed by the compromised Rancher instance.- Successful DaemonSet deployment from Step 4
- Defense-in-depth: workload identity federation, short-lived tokens (bound service account tokens), and encrypted etcd reduce the value of harvested credentials
- Network segmentation between management and downstream clusters limits lateral movement speed
cattle-system service accounts, unexpected exec into cattle pods, and unusual egress traffic from cluster nodes should trigger SIEM alerts.clusterregistrationtokens and issue new short-lived replacements. Disable unused tokens. This directly breaks Step 1 of the attack path — without a valid token, the import endpoint returns a generic error and no manifest is rendered. Deploy within the noisgate mitigation SLA of 3 days for CRITICAL. Use kubectl delete clusterregistrationtokens --all -n <cluster-namespace> and re-issue through the Rancher UI with documentation to avoid sharing tokens via insecure channels.cattle-system namespace unless the image matches a known-good allowlist of official Rancher agent images. This breaks Step 4 — even if the poisoned manifest is applied, the admission controller rejects the injected container. Deploy within the noisgate mitigation SLA of 3 days. Caution: test thoroughly, as Rancher's own agents require elevated privileges in this namespace./v3/import/* paths. Only allow access from trusted internal networks or VPN-connected hosts where cluster imports are performed. This limits the attack surface for URL poisoning by requiring the attacker to also compromise internal network access. Deploy within the noisgate mitigation SLA of 3 days.authImage parameter is validated against a strict OCI image reference character set, rejecting all injection payloads. Complete within the noisgate remediation SLA of 90 days for CRITICAL. Test in staging first, as Rancher upgrades affect cluster management plane availability.cattle-system that does not match known Rancher agent signatures. Also alert on containers with hostNetwork: true and explicit command: overrides in this namespace. This provides detection-in-depth while patching proceeds. Deploy within 3 days.- Pod Security Admission (PSA) on cattle-system in Restricted mode — While this would block the injected privileged container, it would also break Rancher's own cattle-agent and cluster-agent deployments, which require privileged access by design. Applying Restricted PSA to
cattle-systemwill cause cluster management failures. - Kubernetes NetworkPolicy on cattle-system — The injected DaemonSet uses
hostNetwork: true, which bypasses NetworkPolicy enforcement entirely. The container operates on the host network stack, not a pod network. - Rotating only the Rancher admin password — The import endpoint authenticates via the registration token in the URL path, not via Rancher user credentials. Changing admin passwords has no effect on this attack vector.
The supporting signals.
| In-the-Wild Exploitation | No confirmed exploitation. Not listed on CISA KEV. No campaigns attributed. EPSS probability of 1.313% (70th percentile) indicates elevated — but not imminent — exploitation likelihood. |
|---|---|
| Proof-of-Concept Availability | No public PoC found. Checked pocindex.io, GitHub repos, ExploitDB, and nuclei-templates — no dedicated PoC repository for CVE-2026-44939 exists as of 2026-09-27. However, the GHSA advisory description is effectively a *recipe*: it documents the exact parameter (authImage), the injection technique (URL-encoded newlines), and the resulting YAML breakout. Weaponization is trivial for any attacker familiar with YAML. |
| EPSS Score | 0.01313 (1.313%) — 70th percentile. Above-average exploitation probability relative to the general CVE population. |
| KEV Status | Not listed. CISA Known Exploited Vulnerabilities catalog does not include this CVE as of 2026-09-27. |
| CVSS Vector (v3.1) | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H — 9.6 Critical. Network-reachable, low complexity, no privileges (token-in-URL), user interaction required, scope changed (downstream cluster compromise). CVSS v4.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 — 9.4 Critical. |
| Affected Versions | Rancher 2.10.0–2.10.11, 2.11.0–2.11.13, 2.12.0–2.12.9, 2.13.0–2.13.5, 2.14.0–2.14.1. Versions prior to 2.10.0 are also listed as affected in the GHSA. |
| Fixed Versions | 2.14.2, 2.13.6, 2.12.10, 2.11.14, 2.10.12. Fix validates the authImage parameter to allow only valid OCI image reference characters, rejecting newlines, whitespace, and YAML-breaking characters. |
| Internet Exposure | Rancher Manager dashboards are frequently internet-exposed for multi-site cluster management. The vulnerable /v3/import/ endpoint is served by the same HTTPS listener. No specific Shodan/Censys census for Rancher was found, but Kubernetes management platforms are commonly reachable from the internet in cloud-native deployments. |
| Disclosure Date | 2026-06-19 via GitHub Security Advisory GHSA-mhc6-2gfq-xx62. Patched releases published same day. |
| Related Token Leakage CVEs | CVE-2024-58269 (registration token leakage via audit logs, Medium), GHSA-7r53-jvhg-9jq4 (long-lived plaintext registration tokens, no expiration). These weaken the token-acquisition prerequisite for this CVE's attack chain. |
Sources.
- GitHub Security Advisory GHSA-mhc6-2gfq-xx62
- GitHub Advisory Database — CVE-2026-44939
- SUSE Rancher Manager v2.14.2 Release Notes
- GitLab Advisory Database — CVE-2026-44939
- OSV — CVE-2026-44939
- Tenable CVE Entry — CVE-2026-44939
- GHSA-7r53-jvhg-9jq4 — Plaintext registration token exposure
- Go Vulnerability Database — GO-2026-5875
Why this verdict
- Fleet-scale blast radius by definition: Rancher Manager is a Kubernetes orchestration platform — 100% of its installs exist to manage downstream clusters. Successful exploitation deploys a privileged DaemonSet across *every node* in the targeted downstream cluster and can pivot to all Rancher-managed clusters. This is vCenter-class impact.
- Role multiplier: Rancher occupies the *Hypervisors / orchestration* high-value role category. The bug is IN the orchestration platform itself, not a peripheral feature. ≥10% of installs (realistically 100%) are in the high-value role. The documented chain succeeds in this role, and the blast radius is fleet-scale (all managed clusters). Per the high-value-role floor rule, the verdict floor is CRITICAL.
- Token acquisition friction is weakened by history: While the attack requires a valid cluster registration token, Rancher has multiple documented token-leakage CVEs (CVE-2024-58269, GHSA-7r53-jvhg-9jq4). Tokens are long-lived by default, embedded in URLs, and surface in audit logs, Slack messages, CI/CD configs, and wiki pages. This prerequisite is weaker than it appears.
- Social engineering bar is operationally low: The UI:R requirement in CVSS maps to 'trick an admin into running kubectl apply against a URL' — but this is exactly how Rancher's import workflow operates by design. Administrators copy-paste these commands from documentation. Poisoning a wiki page or intercepting a Slack message is far easier than traditional phishing.
- No exploitation yet, but trivial weaponization: No public PoC or in-the-wild exploitation reduces urgency slightly. However, the GHSA advisory itself documents the exact injection technique — weaponization requires only
curland a text editor. The 0.6-point reduction from the vendor's 9.6 reflects this latent-but-not-active threat status.
Why not higher?
A 9.5+ score would require either zero user interaction or confirmed active exploitation. This chain requires social engineering — a victim admin must run kubectl apply against an attacker-controlled URL — and no in-the-wild exploitation or public PoC has been documented as of 2026-09-27. The EPSS of 1.3% indicates elevated but not imminent risk. These friction points prevent maximum severity despite the devastating blast radius.
Why not lower?
Rancher Manager is definitionally a canonical high-value orchestration component — 100% of installs manage downstream Kubernetes clusters. Successful exploitation yields fleet-scale compromise: arbitrary code execution with root privileges on every node across all managed clusters via a privileged DaemonSet with hostNetwork: true. The floor for canonical orchestration components with fleet-scale blast radius is CRITICAL. Registration tokens have multiple documented leakage paths (CVE-2024-58269, GHSA-7r53-jvhg-9jq4), substantially weakening the token-acquisition friction. A generic 'requires social engineering' argument is insufficient to break the floor when the social engineering aligns perfectly with the product's normal operational workflow.
Crowdsourced verification payload.
Run this script on any host with kubectl access to the Rancher management cluster (not a downstream cluster). Requires cluster-admin or equivalent read access to the cattle-system namespace. Invoke with: bash check_cve_2026_44939.sh. No arguments needed; set RANCHER_NAMESPACE env var if your Rancher runs in a non-default namespace.
#!/usr/bin/env bash
# CVE-2026-44939 Checker — Rancher Manager YAML Injection
# Detects vulnerable Rancher versions and checks for exploitation indicators.
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN
set -uo pipefail
RANCHER_NS="${RANCHER_NAMESPACE:-cattle-system}"
VULNERABLE=0
UNKNOWN=0
# --- Step 1: Determine Rancher version ---
IMAGE=""
for deploy in rancher rancher-server; do
IMAGE=$(kubectl get deployment "$deploy" -n "$RANCHER_NS" \
-o jsonpath='{.spec.template.spec.containers[0].image}' 2>/dev/null || true)
[ -n "$IMAGE" ] && break
done
if [ -z "$IMAGE" ]; then
IMAGE=$(kubectl get pods -n "$RANCHER_NS" -l app=rancher \
-o jsonpath='{.items[0].spec.containers[0].image}' 2>/dev/null || true)
fi
if [ -z "$IMAGE" ]; then
echo "[!] Could not detect Rancher deployment in namespace '$RANCHER_NS'."
echo "UNKNOWN"
exit 2
fi
TAG=$(echo "$IMAGE" | grep -oP '(?<=:v)[0-9]+\.[0-9]+\.[0-9]+' || true)
if [ -z "$TAG" ]; then
echo "[!] Could not parse version from image: $IMAGE"
echo "UNKNOWN"
exit 2
fi
echo "[*] Detected Rancher image: $IMAGE"
echo "[*] Parsed version: v${TAG}"
IFS='.' read -r MAJ MIN PAT <<< "$TAG"
# --- Step 2: Check version against vulnerable ranges ---
if [ "$MAJ" -eq 2 ]; then
if [ "$MIN" -eq 14 ] && [ "$PAT" -lt 2 ]; then
VULNERABLE=1
elif [ "$MIN" -eq 13 ] && [ "$PAT" -lt 6 ]; then
VULNERABLE=1
elif [ "$MIN" -eq 12 ] && [ "$PAT" -lt 10 ]; then
VULNERABLE=1
elif [ "$MIN" -eq 11 ] && [ "$PAT" -lt 14 ]; then
VULNERABLE=1
elif [ "$MIN" -eq 10 ] && [ "$PAT" -lt 12 ]; then
VULNERABLE=1
elif [ "$MIN" -lt 10 ]; then
VULNERABLE=1
fi
fi
# --- Step 3: Check for exploitation indicators ---
echo ""
echo "[*] Checking for exploitation indicators in '$RANCHER_NS' namespace..."
SUSPICIOUS=$(kubectl get daemonsets -n "$RANCHER_NS" -o json 2>/dev/null | \
python3 -c "
import sys, json
try:
data = json.load(sys.stdin)
for ds in data.get('items', []):
name = ds['metadata']['name']
spec = ds['spec']['template']['spec']
for c in spec.get('containers', []):
if 'command' in c and c.get('name','') not in ('rancher-agent','cluster-agent','kube-api-auth'):
print(f' ALERT: DaemonSet {name} container {c["name"]} has unexpected command: {c["command"]}')
img = c.get('image','')
if img and 'rancher' not in img.lower() and 'cattle' not in img.lower():
print(f' ALERT: DaemonSet {name} container {c["name"]} uses non-Rancher image: {img}')
if spec.get('hostNetwork') and name not in ('cattle-node-agent','kube-api-auth'):
print(f' ALERT: DaemonSet {name} has hostNetwork:true (unexpected)')
except Exception as e:
print(f' (inspection error: {e})')
" 2>/dev/null || echo " (could not inspect DaemonSets — python3 may not be available)")
if [ -n "$SUSPICIOUS" ]; then
echo "$SUSPICIOUS"
else
echo " No exploitation indicators found."
fi
# --- Step 4: Final verdict ---
echo ""
if [ "$VULNERABLE" -eq 1 ]; then
echo "VULNERABLE — Rancher v${TAG} is affected by CVE-2026-44939."
echo " Upgrade to: 2.14.2 / 2.13.6 / 2.12.10 / 2.11.14 / 2.10.12"
exit 1
else
echo "PATCHED — Rancher v${TAG} is not affected by CVE-2026-44939."
exit 0
fi