← Back to Feed CACHED · 2026-09-27 03:19:42 · CACHE_KEY CVE-2026-44939
CVE-2026-44939 · CWE-95 · Disclosed 2026-06-19

Rancher Manager Command Injection via Unsanitized authImage YAML Parameter in Cluster Import Endpoint

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

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.

"Rancher import endpoint YAML injection yields fleet-scale Kubernetes takeover via social engineering"
02 · The Attack Path

5 steps from start to impact.

STEP 01

Obtain a valid cluster registration token

The attacker acquires a Rancher cluster registration token. These tokens are embedded in import URLs (/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.
Conditions required:
  • Access to a leaked, shared, or intercepted cluster registration token
  • The token must still be valid (default: no expiration)
Where this breaks in practice:
  • Tokens are not publicly enumerable — attacker needs an information disclosure path
  • Organizations that rotate tokens or restrict API access reduce the attack surface
Detection/coverage: Rancher audit logs record token usage; monitor clusterregistrationtokens API calls for anomalous access patterns.
STEP 02

Craft the poisoned import URL

The attacker modifies the legitimate import URL, injecting URL-encoded newlines and YAML directives into the 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.
Conditions required:
  • Knowledge of YAML injection technique (publicly documented in the GHSA)
  • A valid token from Step 1
Where this breaks in practice:
  • 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
STEP 03

Deliver the poisoned URL to a cluster administrator

The attacker substitutes the crafted URL in a location where administrators will encounter it and run 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.
Conditions required:
  • Ability to modify a documentation source, intercept a communication channel, or send a convincing message to a Rancher admin
  • Target admin must execute kubectl apply against the URL
Where this breaks in practice:
  • 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
Detection/coverage: Email/messaging DLP solutions can flag URLs with unusual query parameters; proxy logs can detect the injection patterns in outbound requests to /v3/import/*.
STEP 04

Malicious DaemonSet deploys across the downstream cluster

When the admin runs 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.
Conditions required:
  • The victim executed kubectl apply in Step 3
  • The downstream cluster accepts the manifest (default behavior)
Where this breaks in practice:
  • Admission controllers (OPA Gatekeeper, Kyverno) that block privileged DaemonSets in cattle-system would stop this
  • Pod Security Admission in Restricted mode on cattle-system would block it, but almost no one does this because Rancher's own agents require elevated privileges in this namespace
Detection/coverage: Runtime security tools (Falco, Sysdig Secure) can alert on unexpected DaemonSet creation in cattle-system. kubectl get ds -n cattle-system reveals the injected workload.
STEP 05

Full cluster compromise and lateral movement

With privileged containers on every node, the attacker reads kubelet credentials, harvests service account tokens from /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.
Conditions required:
  • Successful DaemonSet deployment from Step 4
Where this breaks in practice:
  • 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
Detection/coverage: Anomalous API calls from cattle-system service accounts, unexpected exec into cattle pods, and unusual egress traffic from cluster nodes should trigger SIEM alerts.
03 · Compensating Control

1
CRITICAL 9.0→HIGH 7.0
SEVERITY REDUCED
Rotate and restrict all cluster registration tokens immediately — Revoke all existing 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.
2
CRITICAL 9.0→MEDIUM 5.5
SEVERITY REDUCED
Deploy admission controller policy blocking unexpected privileged workloads in cattle-system — Configure OPA Gatekeeper or Kyverno to deny DaemonSet creation in the 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.
3
CRITICAL 9.0→HIGH 7.5
SEVERITY REDUCED
Restrict network access to the /v3/import/ endpoint — Configure your ingress controller, WAF, or reverse proxy to deny external access to /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.
4
CRITICAL 9.0→IGNORE 0.0
SEVERITY REDUCED
Upgrade Rancher to a patched version — Apply the vendor patch (2.14.2, 2.13.6, 2.12.10, 2.11.14, or 2.10.12 depending on your release train). This is the definitive fix — the 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.
5
CRITICAL 9.0→CRITICAL 8.5
Deploy runtime detection for anomalous cattle-system workloads — Configure Falco, Sysdig Secure, or equivalent runtime security tools to alert on DaemonSet creation in 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.
What doesn't work
  • 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-system will 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.
04 · Intelligence Metadata

The supporting signals.

In-the-Wild ExploitationNo 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 AvailabilityNo 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 Score0.01313 (1.313%) — 70th percentile. Above-average exploitation probability relative to the general CVE population.
KEV StatusNot 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 VersionsRancher 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 Versions2.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 ExposureRancher 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 Date2026-06-19 via GitHub Security Advisory GHSA-mhc6-2gfq-xx62. Patched releases published same day.
Related Token Leakage CVEsCVE-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.

  1. GitHub Security Advisory GHSA-mhc6-2gfq-xx62
  2. GitHub Advisory Database — CVE-2026-44939
  3. SUSE Rancher Manager v2.14.2 Release Notes
  4. GitLab Advisory Database — CVE-2026-44939
  5. OSV — CVE-2026-44939
  6. Tenable CVE Entry — CVE-2026-44939
  7. GHSA-7r53-jvhg-9jq4 — Plaintext registration token exposure
  8. Go Vulnerability Database — GO-2026-5875
05 · The Call

Final Verdict
= UNCHANGED to CRITICAL (9.0/10)

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 curl and 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.

06 · Verification

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.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/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