k8saudit shipped rules do not detect privileged/sensitive settings on init or ephemeral containersGHSA-jhjp-4c2q-xmx4
MEDIUMFix: falcosecurity/plugins#1400GHSA-jhjp-4c2q-xmx4 is a medium-severity (CVSS 4.3) vulnerability in github.com/falcosecurity/plugins/plugins/k8saudit. A fix is available for github.com/falcosecurity/plugins/plugins/k8saudit — see the affected versions and patch details below.
Real-World Exposure
github.com/falcosecurity/plugins/plugins/k8saudit🐹github.com/falcosecurity/plugins/plugins/k8saudit-eks🐹github.com/falcosecurity/plugins/plugins/k8saudit-gke🐹github.com/falcosecurity/plugins/plugins/k8saudit-aks🐹github.com/falcosecurity/plugins/plugins/k8saudit-ovhReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/falcosecurity/plugins/plugins/k8saudit | all versions | 0.18.0go get github.com/falcosecurity/plugins/plugins/k8saudit@v0.18.0 |
| 🐹Go | github.com/falcosecurity/plugins/plugins/k8saudit-eks | all versions | 0.12.0go get github.com/falcosecurity/plugins/plugins/k8saudit-eks@v0.12.0 |
| 🐹Go | github.com/falcosecurity/plugins/plugins/k8saudit-gke | all versions | 0.9.0go get github.com/falcosecurity/plugins/plugins/k8saudit-gke@v0.9.0 |
| 🐹Go | github.com/falcosecurity/plugins/plugins/k8saudit-aks | all versions | 0.6.0go get github.com/falcosecurity/plugins/plugins/k8saudit-aks@v0.6.0 |
| 🐹Go | github.com/falcosecurity/plugins/plugins/k8saudit-ovh | all versions | 0.6.0go get github.com/falcosecurity/plugins/plugins/k8saudit-ovh@v0.6.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/falcosecurity/plugins/plugins/k8saudit, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/falcosecurity/plugins/plugins/k8saudit to 0.18.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-jhjp-4c2q-xmx4 is resolved across your whole dependency graph.
Workarounds
Close the privilege gap rather than the entry point: audit which accounts, roles and service identities can reach the affected operation, drop the component to the least privilege it actually needs, and review file and directory permissions created by earlier installs — a default left in place is what makes this reachable.
Frequently Asked Questions
Is GHSA-jhjp-4c2q-xmx4 in your dependencies?
Find it across Go, including transitive dependencies.