CVE-2026-4342: 
Ingress NGINX Controller (community-driven) vulnerability analysis and mitigation

CVE-2026-4342 is a comment-based nginx configuration injection vulnerability in Kubernetes ingress-nginx, where a combination of Ingress annotations can be used to inject arbitrary configuration into nginx. Discovered and disclosed on March 19, 2026, it affects ingress-nginx versions prior to v1.13.9, v1.14.5, and v1.15.1. The vulnerability was reported by researcher wooseokdotkim and assigned a CVSS v3.1 base score of 8.8 (High) (GitHub Advisory, Kubernetes Issue, oss-security).

The root cause is improper input validation (CWE-20) in how ingress-nginx processes Ingress resource annotations. An attacker with low-level privileges (e.g., the ability to create or modify Ingress objects in a Kubernetes cluster) can craft annotation combinations that inject malicious directives into the nginx configuration, bypassing expected sanitization. The injection mechanism is comment-based, allowing configuration blocks to be smuggled past validation logic. Detection guidance from the Kubernetes Security Response Committee notes that suspicious data within the rules.http.paths.path field of an Ingress resource may indicate exploitation attempts (Kubernetes Issue, oss-security).

Successful exploitation allows a low-privileged attacker to achieve arbitrary code execution within the ingress-nginx controller process and access all Kubernetes Secrets the controller can reach. In the default ingress-nginx installation, the controller has cluster-wide access to Secrets, meaning a successful attack could expose sensitive credentials, TLS certificates, API tokens, and other secrets across the entire cluster. This creates significant risk for lateral movement and full cluster compromise (GitHub Advisory, Kubernetes Issue).

As of the time of disclosure, no confirmed in-the-wild exploitation has been observed, and the Feedly executive summary notes no public proof-of-concept was confirmed at the time of initial analysis. However, PoC references have been indexed (e.g., https://github.com/stuartMoorhouse/CVE-2026-4342), and the vulnerability has been tracked by Qualys scanners. The EPSS score is approximately 0.04–0.057%, placing it in the 18th percentile for exploitation likelihood. The vulnerability is not currently listed in the CISA KEV catalog based on available data (GitHub Advisory, Feedly).

1. Reconnaissance: Identify Kubernetes clusters running ingress-nginx using tools like kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx or by scanning for exposed Kubernetes API endpoints. Confirm the ingress-nginx version is below v1.13.9, v1.14.5, or v1.15.1.
2. Obtain low-privileged access: Acquire credentials or a service account with permission to create or modify Ingress resources in at least one namespace (a relatively common permission in multi-tenant clusters).
3. Craft malicious Ingress object: Create an Ingress resource with specially crafted annotation combinations designed to inject nginx configuration directives. The injection leverages comment-based techniques to smuggle directives past input validation, embedding malicious nginx config blocks.
4. Trigger configuration reload: Submit the malicious Ingress object to the Kubernetes API. The ingress-nginx controller will process the annotations and regenerate the nginx configuration, incorporating the injected directives.
5. Achieve code execution and Secret access: The injected nginx configuration executes arbitrary code in the context of the ingress-nginx controller process, enabling the attacker to read cluster-wide Secrets, exfiltrate credentials, or establish persistence (Kubernetes Issue, oss-security).

• Kubernetes API Logs: Unexpected creation or modification of Ingress resources by low-privileged service accounts, particularly those containing unusual annotation values or complex annotation combinations.
• Ingress Resource Inspection: Suspicious or encoded data within the rules.http.paths.path field of Ingress resources; annotations containing nginx directive syntax, comment characters (#), or newline sequences (\n) in unexpected fields.
• ingress-nginx Controller Logs: Errors or unexpected behavior during nginx configuration reload; unusual nginx configuration blocks appearing in generated config files.
• Process: Unexpected child processes spawned by the ingress-nginx controller (e.g., shell processes, network utilities like curl or wget).
• Network: Unusual outbound connections from the ingress-nginx controller pod to external IPs or internal cluster services not normally accessed by the controller.
• File System: Unexpected files written to the ingress-nginx controller container filesystem, particularly in /tmp or nginx configuration directories (Kubernetes Issue, oss-security).

The primary remediation is to upgrade ingress-nginx to a fixed version: v1.13.9, v1.14.5, or v1.15.1, depending on the currently deployed branch. As interim mitigations, restrict RBAC permissions so that only trusted principals can create or modify Ingress resources; limit the ingress-nginx controller's Secret access to only those namespaces and Secrets required for operation rather than cluster-wide. Implement admission controllers or OPA/Gatekeeper policies to validate and restrict Ingress annotations until patching is complete, and monitor Ingress object creation for suspicious annotation patterns (oss-security, GitHub Advisory).

The Kubernetes Security Response Committee disclosed the vulnerability via the oss-security mailing list on March 19, 2026, with Tabitha Sable authoring the disclosure on behalf of the committee. The Canadian Centre for Cyber Security (CCCS) issued advisory AV26-260, and Belgium's CCB published a warning urging immediate patching. Security news outlets including The Hacker Wire and Security Online covered the vulnerability, and it was included in The Hacker News weekly recap. The Kubernetes project's official Bluesky account also posted about the issue, indicating active community communication (oss-security, Kubernetes Issue).