{"items":[{"id":"NVI-00014089","kind":"vulnerability","title":"k8saudit shipped rules do not detect privileged/sensitive settings on init or ephemeral containers","revision":1,"unknowns":["Customer inventory, deployment, reachability and exploitation have not been inspected."],"lifecycle":"active","identifiers":["GHSA-jhjp-4c2q-xmx4"],"plain_summary":"GitHub lists this reviewed advisory for 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-ovh. Published version ranges and source prerequisites are shown below; this is not an inspection of a visitor’s application.","review_status":"source_listed","control_topics":[],"public_actions":[{"summary":"Identify the exact component and deployed version, examine the linked publisher’s conditions, and retain evidence of any mitigation.","source_ids":["sr-431b3178237441cba5316fd19190d9ce"],"action_type":"investigate","limitations":"Confirm current vendor support, compatibility and deployment evidence. This report has not tested a fix in your system.","current_supported_target":null}],"schema_version":"1.1.0","source_metrics":[{"kind":"CVSS","as_of":"2026-09-21T21:43:55.000Z","value":"4.3 medium","meaning":"GitHub source severity; exploitability and local consequence require separate evidence.","source_id":"sr-431b3178237441cba5316fd19190d9ce"}],"why_it_matters":"Published affected context helps an owner decide what evidence to gather. This report has not examined your application.","related_sources":[{"id":"sr-431b3178237441cba5316fd19190d9ce","url":"https://github.com/advisories/GHSA-jhjp-4c2q-xmx4","basis":"vendor_advisory","notes":"GitHub Advisory Database; CC-BY-4.0. Each advisory links its original attribution. Null normalizes fields.","title":"GHSA-jhjp-4c2q-xmx4","publisher":"GitHub Advisory Database","observed_at":"2026-11-01T14:29:31.527Z"}],"affected_context":[{"certainty":"source_listed","source_ids":["sr-431b3178237441cba5316fd19190d9ce"],"technology":"github.com/falcosecurity/plugins/plugins/k8saudit","known_exclusions":[],"conditions_summary":"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.\n\n### Impact\n\nAn 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.\n\nThis 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`","public_affected_ranges":["<= 0.17.0"]},{"certainty":"source_listed","source_ids":["sr-431b3178237441cba5316fd19190d9ce"],"technology":"github.com/falcosecurity/plugins/plugins/k8saudit-eks","known_exclusions":[],"conditions_summary":"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.\n\n### Impact\n\nAn 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.\n\nThis 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`","public_affected_ranges":["<= 0.11.0"]},{"certainty":"source_listed","source_ids":["sr-431b3178237441cba5316fd19190d9ce"],"technology":"github.com/falcosecurity/plugins/plugins/k8saudit-gke","known_exclusions":[],"conditions_summary":"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.\n\n### Impact\n\nAn 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.\n\nThis 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`","public_affected_ranges":["<= 0.8.0"]},{"certainty":"source_listed","source_ids":["sr-431b3178237441cba5316fd19190d9ce"],"technology":"github.com/falcosecurity/plugins/plugins/k8saudit-aks","known_exclusions":[],"conditions_summary":"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.\n\n### Impact\n\nAn 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.\n\nThis 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`","public_affected_ranges":["<= 0.5.1"]},{"certainty":"source_listed","source_ids":["sr-431b3178237441cba5316fd19190d9ce"],"technology":"github.com/falcosecurity/plugins/plugins/k8saudit-ovh","known_exclusions":[],"conditions_summary":"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.\n\n### Impact\n\nAn 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.\n\nThis 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`","public_affected_ranges":["<= 0.5.0"]}],"null_published_at":"2026-11-02T10:00:37.206Z","source_updated_at":"2026-09-21T21:43:55.000Z","source_disclosed_at":"2026-09-21T21:43:52.000Z","is_synthetic_fixture":false,"null_last_reviewed_at":null,"public_change_summary":"First indexed by Null; source disclosure date is shown separately.","null_first_observed_at":"2026-11-01T14:29:31.527Z"}],"next_cursor":null,"snapshot_revision":"42594"}