GHSA-JHJP-4C2Q-XMX4
Vulnerability from github – Published: 2026-09-21 21:43 – Updated: 2026-09-21 21:43The 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": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.17.0"
},
"package": {
"ecosystem": "Go",
"name": "github.com/falcosecurity/plugins/plugins/k8saudit"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.18.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.11.0"
},
"package": {
"ecosystem": "Go",
"name": "github.com/falcosecurity/plugins/plugins/k8saudit-eks"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.12.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.8.0"
},
"package": {
"ecosystem": "Go",
"name": "github.com/falcosecurity/plugins/plugins/k8saudit-gke"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.9.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.5.1"
},
"package": {
"ecosystem": "Go",
"name": "github.com/falcosecurity/plugins/plugins/k8saudit-aks"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.6.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.5.0"
},
"package": {
"ecosystem": "Go",
"name": "github.com/falcosecurity/plugins/plugins/k8saudit-ovh"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.6.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-693"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-21T21:43:52Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "The `k8saudit` plugin\u0027s 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\u0027s `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`) embed the same extraction logic and ship the same ruleset, and were affected equally.\n\nNote: 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.\n\n\n### Patches\n\nFixed in `k8saudit 0.18.0`, and in the cloud-variant releases that depend on it \u2014 `k8saudit-eks 0.12.0`, `k8saudit-gke 0.9.0`, `k8saudit-aks 0.6.0`, `k8saudit-ovh 0.6.0` \u2014 all released on 2026-06-19.\n\nThe fix ([falcosecurity/plugins#1400](https://github.com/falcosecurity/plugins/pull/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.\n\nOperators upgrading should review any **custom** rules built on `ka.req.pod.containers.*` \u2014 in particular tuned `Create Disallowed Pod` image allowlists \u2014 and extend them to the new `initContainers`/`ephemeralContainers` image fields.\n\n### Workarounds\n\nFor 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.\n\n### Credits\n\n[kanywst](https://github.com/kanywst) \u2014 discovery and fix.",
"id": "GHSA-jhjp-4c2q-xmx4",
"modified": "2026-09-21T21:43:52Z",
"published": "2026-09-21T21:43:52Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/falcosecurity/plugins/security/advisories/GHSA-jhjp-4c2q-xmx4"
},
{
"type": "WEB",
"url": "https://github.com/falcosecurity/plugins/pull/1400"
},
{
"type": "WEB",
"url": "https://github.com/falcosecurity/plugins/commit/0adb9b3c7e2c8bad53f30d01c057e038b2afa5e1"
},
{
"type": "PACKAGE",
"url": "https://github.com/falcosecurity/plugins"
},
{
"type": "WEB",
"url": "https://github.com/falcosecurity/plugins/releases/tag/plugins/k8saudit-aks/v0.6.0"
},
{
"type": "WEB",
"url": "https://github.com/falcosecurity/plugins/releases/tag/plugins/k8saudit-eks/v0.12.0"
},
{
"type": "WEB",
"url": "https://github.com/falcosecurity/plugins/releases/tag/plugins/k8saudit-gke/v0.9.0"
},
{
"type": "WEB",
"url": "https://github.com/falcosecurity/plugins/releases/tag/plugins/k8saudit-ovh/v0.6.0"
},
{
"type": "WEB",
"url": "https://github.com/falcosecurity/plugins/releases/tag/plugins/k8saudit/v0.18.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "k8saudit shipped rules do not detect privileged/sensitive settings on init or ephemeral containers"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.