GHSA-jhjp-4c2q-xmx4

The k8saudit plugin's per-container fields (ka.req.pod.containers.*) and the shipped k8s_audit_rules.yaml evaluated only requestObject.spec.containers. Security-relevant settings on a pod's initContainers or ephemeralContainers were not inspected, so the shipped Create Privileged Pod rule did not fire for a privileged container placed in either list.

Impact

An actor able to create pods (the activity k8saudit is intended to audit) could run a privileged container without triggering the default Create Privileged Pod rule, by declaring it as an initContainer or ephemeralContainer instead of a regular container. Kubernetes runs such containers with the requested privileges, but the shipped rule did not see them. The same gap applied to other per-container security settings (capabilities, allowPrivilegeEscalation, runAsUser, etc.) and, for deployments using a customized image allowlist, to disallowed images placed in those lists.

This is a detection bypass of the default k8saudit ruleset, not a direct privilege escalation, and it requires the ability to create pods. The cloud-provider variants (k8saudit-eks, k8saudit-gke, k8saudit-aks, k8saudit-ovh) embed the same extraction logic and ship the same ruleset, and were affected equally.

Note: adding an ephemeral container goes through the pods/ephemeralcontainers subresource, so the EphemeralContainers Created rule still logged that event at NOTICE, but without any privileged/security evaluation.

Patches

Fixed in k8saudit 0.18.0, and in the cloud-variant releases that depend on it — k8saudit-eks 0.12.0, k8saudit-gke 0.9.0, k8saudit-aks 0.6.0, k8saudit-ovh 0.6.0 — all released on 2026-06-19.

The fix (falcosecurity/plugins#1400, merged 2026-06-18) adds dedicated ka.req.pod.initContainers.* and ka.req.pod.ephemeralContainers.* field families and updates Create Privileged Pod (via a new any_container_privileged macro) to evaluate all three container lists.

Operators upgrading should review any custom rules built on ka.req.pod.containers.* — in particular tuned Create Disallowed Pod image allowlists — and extend them to the new initContainers/ephemeralContainers image fields.

Workarounds

For deployments that cannot upgrade immediately, restrict who can create pods (RBAC) and enforce Pod Security Admission (baseline/restricted) or an admission controller (Kyverno, OPA/Gatekeeper) to block privileged init/ephemeral containers at admission time, as defense-in-depth.

Credits

kanywst — discovery and fix.

The k8saudit plugin's per-container fields (ka.req.pod.containers.*) and the shipped k8s_audit_rules.yaml evaluated only requestObject.spec.containers. Security-relevant settings on a pod's initContainers or ephemeralContainers were not inspected, so the shipped Create Privileged Pod rule did not fire for a privileged container placed in either list.

Impact

An actor able to create pods (the activity k8saudit is intended to audit) could run a privileged container without triggering the default Create Privileged Pod rule, by declaring it as an initContainer or ephemeralContainer instead of a regular container. Kubernetes runs such containers with the requested privileges, but the shipped rule did not see them. The same gap applied to other per-container security settings (capabilities, allowPrivilegeEscalation, runAsUser, etc.) and, for deployments using a customized image allowlist, to disallowed images placed in those lists.

This is a detection bypass of the default k8saudit ruleset, not a direct privilege escalation, and it requires the ability to create pods. The cloud-provider variants (k8saudit-eks, k8saudit-gke, k8saudit-aks, k8saudit-ovh) embed the same extraction logic and ship the same ruleset, and were affected equally.

Note: adding an ephemeral container goes through the pods/ephemeralcontainers subresource, so the EphemeralContainers Created rule still logged that event at NOTICE, but without any privileged/security evaluation.

Patches

Fixed in k8saudit 0.18.0, and in the cloud-variant releases that depend on it — k8saudit-eks 0.12.0, k8saudit-gke 0.9.0, k8saudit-aks 0.6.0, k8saudit-ovh 0.6.0 — all released on 2026-06-19.

The fix (falcosecurity/plugins#1400, merged 2026-06-18) adds dedicated ka.req.pod.initContainers.* and ka.req.pod.ephemeralContainers.* field families and updates Create Privileged Pod (via a new any_container_privileged macro) to evaluate all three container lists.

Operators upgrading should review any custom rules built on ka.req.pod.containers.* — in particular tuned Create Disallowed Pod image allowlists — and extend them to the new initContainers/ephemeralContainers image fields.

Workarounds

For deployments that cannot upgrade immediately, restrict who can create pods (RBAC) and enforce Pod Security Admission (baseline/restricted) or an admission controller (Kyverno, OPA/Gatekeeper) to block privileged init/ephemeral containers at admission time, as defense-in-depth.

Credits

kanywst — discovery and fix.

k8saudit shipped rules do not detect privileged/sensitive settings on init or ephemeral containers in github.com/falcosecurity/plugins/plugins/k8saudit