Summary
k8saudit shipped rules do not detect privileged/sensitive settings on init or ephemeral containers
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.
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.
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.
GHSA-JHJP-4C2Q-XMX4 has a CVSS score of 4.3 (Medium). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.18.0, 0.12.0, 0.9.0, 0.6.0); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
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.
Frequently Asked Questions
- What is GHSA-JHJP-4C2Q-XMX4? GHSA-JHJP-4C2Q-XMX4 is a medium-severity security vulnerability in github.com/falcosecurity/plugins/plugins/k8saudit (go), affecting versions <= 0.17.0. It is fixed in 0.18.0, 0.12.0, 0.9.0, 0.6.0.
- How severe is GHSA-JHJP-4C2Q-XMX4? GHSA-JHJP-4C2Q-XMX4 has a CVSS score of 4.3 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which packages are affected by GHSA-JHJP-4C2Q-XMX4?
github.com/falcosecurity/plugins/plugins/k8saudit(go) (versions <= 0.17.0)github.com/falcosecurity/plugins/plugins/k8saudit-eks(go) (versions <= 0.11.0)github.com/falcosecurity/plugins/plugins/k8saudit-gke(go) (versions <= 0.8.0)github.com/falcosecurity/plugins/plugins/k8saudit-aks(go) (versions <= 0.5.1)github.com/falcosecurity/plugins/plugins/k8saudit-ovh(go) (versions <= 0.5.0)
- Is there a fix for GHSA-JHJP-4C2Q-XMX4? Yes. GHSA-JHJP-4C2Q-XMX4 is fixed in 0.18.0, 0.12.0, 0.9.0, 0.6.0. Upgrade to this version or later.
- Is GHSA-JHJP-4C2Q-XMX4 exploitable, and should I be worried? Whether GHSA-JHJP-4C2Q-XMX4 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-JHJP-4C2Q-XMX4 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-JHJP-4C2Q-XMX4?
- Upgrade
github.com/falcosecurity/plugins/plugins/k8sauditto 0.18.0 or later - Upgrade
github.com/falcosecurity/plugins/plugins/k8saudit-eksto 0.12.0 or later - Upgrade
github.com/falcosecurity/plugins/plugins/k8saudit-gketo 0.9.0 or later - Upgrade
github.com/falcosecurity/plugins/plugins/k8saudit-aksto 0.6.0 or later - Upgrade
github.com/falcosecurity/plugins/plugins/k8saudit-ovhto 0.6.0 or later
- Upgrade