GHSA-jhjp-4c2q-xmx4 k8saudit shipped rules do not detect privileged/sensitive settings on init or ephemeral containers

• Go github.com/falcosecurity/plugins/plugins/k8saudit: < 0.18.0 → fixed in 0.18.0 • Go github.com/falcosecurity/plugins/plugins/k8saudit-eks: < 0.12.0 → fixed in 0.12.0 • Go github.com/falcosecurity/plugins/plugins/k8saudit-gke: < 0.9.0 → fixed in 0.9.0 • Go github.com/falcosecurity/plugins/plugins/k8saudit-aks: < 0.6.0 → fixed in 0.6.0 • Go github.com/falcosecurity/plugins/plugins/k8saudit-ovh: < 0.6.0 → fixed in 0.6.0

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.