GHSA-JHJP-4C2Q-XMX4: Falco k8saudit Plugin Ruleset Bypass via initContainers and ephemeralContainers

The Falco k8saudit plugin is a security auditing tool designed to ingest, parse, and analyze Kubernetes Audit Logs. By evaluating audit events against predefined rulesets, the plugin identifies security risks and compliance issues within active clusters. One of its primary default rules, Create Privileged Pod, alerts administrators when containers requiring administrative privileges are scheduled.\n\nThis vulnerability, tracked as GHSA-JHJP-4C2Q-XMX4, allowed attackers to bypass this critical rule. The security flaw stems from a tracking omission within the default extraction logic. The ruleset and underlying data-parsing schema only analyzed standard container arrays, ignoring other container fields supported by Kubernetes.\n\nSpecifically, an attacker could define a privileged container within initContainers or dynamically inject one via ephemeralContainers. Because the plugin did not extract security contexts from these specific blocks, no alert was triggered. This provided a reliable mechanism for attackers to execute highly privileged workloads on nodes without detection.

To understand the root cause of the vulnerability, we must examine the Kubernetes Pod specification (PodSpec) schema. Kubernetes supports three distinct arrays of container definitions within a Pod Spec: containers, initContainers, and ephemeralContainers. All three variants permit the application of a securityContext containing the privileged: true flag.\n\nPrior to the fix, the Falco k8saudit plugin parsed incoming audit JSON payloads using strict path configurations. In the plugin's data extraction module (extract.go), the key ka.req.pod.containers.privileged was explicitly mapped to requestObject.spec.containers[*].securityContext.privileged. This mapping extracted Boolean flags exclusively from the standard container array.\n\nThe parser implementation had no corresponding fields or path extractions mapped to initContainers or ephemeralContainers. Consequently, when an audit event containing a privileged payload in these omitted arrays arrived, the k8saudit engine returned a null or empty set. The rule compiler subsequently failed to match the true state, preventing alert emission.\n\nThe logical flaw resides in the assumption that standard application containers represent the sole vectors for running privileged code. Because initContainers execute prior to standard containers and ephemeralContainers allow ad-hoc debugger injection, omitting these structures created an operational blind spot.

The core of the vulnerability can be analyzed by looking at how the fields were registered and extracted in extract.go before and after the fix.\n\nPrior to the patch, the extract.go file contained specific, hardcoded logic for extracting container elements. The code was structurally restricted to parsing standard container arrays, as shown in the following extract:\n\ngo\n// Vulnerable Code Path in extract.go\ncase "ka.req.pod.containers.privileged":\n // This call only queries "spec" -> "containers"\n arr, err := e.getValuesRecursive(jsonValue, e.argIndexFilter(req), "requestObject", "spec", "containers", "securityContext", "privileged")\n if err != nil {\n return err\n }\n req.SetValue(e.arrayAsStringsSkipNil(arr))\n\n\nTo remediate this structural gap, the developers refactored the extraction logic to generalize path parsing. The fix dynamically iterates through all valid container arrays within the Pod specification, as shown below:\n\ngo\n// Patched Code Path in extract.go\nfield := req.Field()\n// The patch normalizes the handler for containers, initContainers, and ephemeralContainers\nfor _, list := range []string{"containers", "initContainers", "ephemeralContainers"} {\n if prefix := "ka.req.pod." + list + "."; strings.HasPrefix(field, prefix) {\n // The extractContainerField helper dynamically targets the designated list\n return e.extractContainerField(req, jsonValue, list, strings.TrimPrefix(field, prefix))\n }\n}\n\n\nThis modification ensures that if a field such as ka.req.pod.initContainers.privileged is referenced, the parser queries the initContainers sub-tree in the JSON audit payload. Additionally, the developers updated fields.go to expose the new audit fields to the rule engine, ensuring configuration consistency.\n\nThe macro any_container_privileged was added to k8s_audit_rules.yaml to replace the single container check with a logical OR across all container blocks:\n\nyaml\n# Refactored Rule Macro in k8s_audit_rules.yaml\n- macro: any_container_privileged\n condition: >\n (ka.req.pod.containers.privileged intersects (true) or\n ka.req.pod.initContainers.privileged intersects (true) or\n ka.req.pod.ephemeralContainers.privileged intersects (true))\n

Exploitation of this vulnerability requires an attacker to possess permissions to create Pods or inject ephemeral containers inside a target namespace. The attacker initiates the bypass by constructing a Pod specification containing a privileged container nested within the initContainers array. Because Falco rules only evaluated standard containers, this payload executes as root on the host node without triggering alerts.\n\nThe following YAML manifest demonstrates a valid bypass payload. The standard container is defined as a benign web server, whereas the malicious action is performed within an initialization container:\n\nyaml\napiVersion: v1\nkind: Pod\nmetadata:\n name: privileged-init-bypass\n namespace: target-namespace\nspec:\n initContainers:\n - name: malicious-init\n image: alpine:latest\n command: ["/bin/sh", "-c"]\n args: \n - |\n echo "[+] Escaping from init container...";\n mkdir -p /mnt/host;\n mount -t proc none /mnt/host;\n # Execute commands on host namespace or write ssh keys...\n sleep 5;\n securityContext:\n privileged: true\n containers:\n - name: benign-dummy-container\n image: nginx:alpine\n ports:\n - containerPort: 80\n\n\nWhen this manifest is submitted to the API server, an audit log is emitted and captured by Falco. Because the rule Create Privileged Pod only evaluates fields matching ka.req.pod.containers.privileged, the condition returns false. The container runtime executes the init container with administrative privileges, granting the attacker a root host escape window.\n\nA second exploitation route involves injecting a privileged debugging container into an existing, active Pod using the /ephemeralcontainers API endpoint. The standard Falco rules fail to evaluate the subresource modification, allowing runtime debugger processes to run with full privileges undetected.

The impact of this security-bypass vulnerability is classified as high. Active auditing configurations are designed to provide runtime security observability and threat detection. When a bypass occurs, detection mechanisms fail, offering adversaries an open window to compromise the cluster infrastructure.\n\nA successful bypass allows an attacker to gain unmonitored administrative privileges on the underlying Kubernetes node. From this position, the attacker can execute container escape routines, access the node's root filesystem, and dump credentials. Additionally, attackers can leverage host-level access to compromise neighboring pods or entire nodes in the cluster.\n\nBy compromising the logging observability tier, the attacker effectively achieves defense evasion. Since security operations centers rely on Falco alerts to initiate incident response, the silent execution of privileged code delays threat identification. This delay increases the dwell time of an active intrusion within the production environment.

The primary and recommended remediation path is to upgrade the Falco k8saudit plugin to version v0.18.0 or later. Additionally, corresponding cloud wrapper plugins must be updated to their designated secure versions. These updates ensure that the underlying path parsers extract structural data from all container lists.\n\nIf immediate patching of the Falco plugins is not possible, security teams must deploy alternative admission controls to block privileged container creation. Using admission controllers like Kyverno or Open Policy Agent (OPA) Gatekeeper is highly effective. These tools evaluate and block the pod creation request at the API gateway prior to cluster scheduling.\n\nThe following Kyverno policy illustrates a temporary mitigation that blocks privileged contexts across all three container types:\n\nyaml\napiVersion: kyverno.io/v1\nkind: ClusterPolicy\nmetadata:\n name: block-privileged-containers\nspec:\n validationFailureAction: Enforce\n background: true\n rules:\n - name: privilege-check\n match:\n any:\n - resources:\n kinds:\n - Pod\n validate:\n message: "Privileged containers are not allowed."\n pattern:\n spec:\n =(containers):\n - =(securityContext):\n =(privileged): "false"\n =(initContainers):\n - =(securityContext):\n =(privileged): "false"\n =(ephemeralContainers):\n - =(securityContext):\n =(privileged): "false"\n