GHSA-jhjp-4c2q-xmx4: Medium severity go/github.com/falcosecurity/plugins/plugins/k8saudit-ovh vulnerability
The k8saudit plugin's per-container fields (ka.req.pod.containers.) and the shipped k8sauditrules.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 anycontainerprivileged 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/github.com/falcosecurity/plugins/plugins/k8saudit-ovhto a version that resolves this vulnerability.Fixed in 0.6.0 - Upgrade
Upgrade
go/github.com/falcosecurity/plugins/plugins/k8saudit-aksto a version that resolves this vulnerability.Fixed in 0.6.0 - Upgrade
Upgrade
go/github.com/falcosecurity/plugins/plugins/k8saudit-gketo a version that resolves this vulnerability.Fixed in 0.9.0 - Upgrade
Upgrade
go/github.com/falcosecurity/plugins/plugins/k8saudit-eksto a version that resolves this vulnerability.Fixed in 0.12.0 - Upgrade
Upgrade
go/github.com/falcosecurity/plugins/plugins/k8sauditto a version that resolves this vulnerability.Fixed in 0.18.0 - Upgrade
Upgrade
k8sauditto a version that resolves this vulnerability.Fixed in 0.18.0 - Upgrade
Upgrade
k8saudit-eksto a version that resolves this vulnerability.Fixed in 0.12.0 - Upgrade
Upgrade
k8saudit-gketo a version that resolves this vulnerability.Fixed in 0.9.0 - Upgrade
Upgrade
k8saudit-aksto a version that resolves this vulnerability.Fixed in 0.6.0 - Upgrade
Upgrade
k8saudit-ovhto a version that resolves this vulnerability.Fixed in 0.6.0 - Configuration
For environments that cannot upgrade immediately, restrict who can create pods (RBAC) to trusted operators/users only, since the bypass requires the ability to create pods.
Kubernetes RBAC Who can create pods = Restrict to trusted subjects - Configuration
Enforce Pod Security Admission with `baseline`/`restricted` to block privileged initContainers/ephemeralContainers at admission time as defense-in-depth.
Kubernetes Pod Security Admission (PSA) Pod security level = baseline/restricted - Configuration
If using an admission controller, configure Kyverno/OPA-Gatekeeper to block privileged initContainers and ephemeralContainers at admission time.
Admission controller (Kyverno or OPA/Gatekeeper) Admission policy for privileged initContainers/ephemeralContainers = Deny at admission time - Configuration
After upgrading, review any custom rules built on `ka.req.pod.containers.*` (especially tuned `Create Disallowed Pod` image allowlists) and extend them to the new `initContainers`/`ephemeralContainers` image fields (per-container security fields must also be extended).
k8saudit Custom rules on ka.req.pod.containers.* image allowlists (e.g., disallowed image allowlists) = Extend to ka.req.pod.initContainers.* and ka.req.pod.ephemeralContainers.*
Event History
Frequently Asked Questions
Are default k8saudit deployments affected?
Yes. The gap was present in the shipped k8s_audit_rules.yaml, including the default Create Privileged Pod rule.
What access does an attacker need to exploit this detection gap?
The attacker must be able to create pods. They can place a privileged container in initContainers or ephemeralContainers rather than the regular containers list.
Is this a Kubernetes privilege-escalation vulnerability?
No. It is a detection bypass: Kubernetes still applies the requested container privileges, but the affected default rule does not generate an alert for those container lists.
What else could evade inspection besides privileged containers?
Other per-container security settings, including capabilities, allowPrivilegeEscalation, and runAsUser, were subject to the same gap. Customized image allowlists could also miss disallowed images in initContainers or ephemeralContainers.