CVE-2026-3288

Description

A Configuration Injection vulnerability was discovered in the Kubernetes ingress-nginx controller's handling of the nginx.ingress.kubernetes.io/rewrite-target annotation. The controller fails to properly sanitize user-supplied annotation values before incorporating them into the generated nginx configuration, allowing an attacker with Ingress object creation privileges to inject arbitrary nginx directives.

This is the first non-WordPress CVE in the SnailSploit portfolio and carries the highest severity rating of any finding to date. For deeper analysis of container breakout techniques and trust boundary exploitation in containerized environments, see Advanced Container Escapes and Zero Trust Container Runtime Security.

Technical Details

The ingress-nginx controller dynamically generates nginx configuration based on Kubernetes Ingress resource annotations. The rewrite-target annotation value is inserted into the nginx configuration with insufficient input validation, enabling injection of arbitrary configuration directives.

Attack Vector

An attacker with permissions to create or modify Ingress objects in any namespace can craft a malicious rewrite-target annotation that breaks out of the intended configuration context. By injecting nginx directives, the attacker can:

• Execute arbitrary code on the ingress controller pod
• Read Kubernetes Secrets from any namespace (including TLS certificates and service account tokens)
• Pivot to other services within the cluster network
• Intercept and modify traffic to other ingress-managed services

Vulnerability Characteristics

• Authentication: Requires Kubernetes RBAC privileges to create/edit Ingress objects
• Attack Complexity: Low — single annotation modification triggers the injection
• Privileges Required: Low — any namespace-scoped Ingress create/edit permission
• User Interaction: None required
• Scope: Changed — compromise of the ingress controller affects all namespaces

Impact Assessment

Successful exploitation of this vulnerability leads to:

• Remote Code Execution: Arbitrary command execution on the ingress controller pod with its service account privileges
• Cluster-Wide Secret Disclosure: The ingress controller typically has broad read access to Secrets across namespaces for TLS certificate management
• Lateral Movement: From the controller pod, an attacker can access internal cluster services and the Kubernetes API
• Traffic Interception: Ability to modify nginx configuration to intercept, redirect, or manipulate traffic to any ingress-managed service

The severity is rated High (CVSS 8.8) due to the changed scope — a single namespace compromise escalates to cluster-wide impact. The ingress controller is a critical infrastructure component that processes all external traffic entering the cluster.

Proof of Concept

The proof of concept demonstrates the injection chain:

1. Create an Ingress resource with a crafted rewrite-target annotation containing nginx directive injection
2. The ingress controller processes the annotation and generates a poisoned nginx configuration
3. The injected directives execute, demonstrating arbitrary configuration control
4. From configuration control, escalate to code execution via nginx's native capabilities

Full PoC and reproduction steps are available in the GitHub repository.

Remediation Steps

For Cluster Administrators

• Update immediately to ingress-nginx 1.13.8, 1.14.4, or 1.15.0+
• Audit existing Ingress objects for suspicious annotation values
• Implement admission controllers (OPA Gatekeeper or Kyverno) to validate annotation content
• Apply least-privilege RBAC — restrict Ingress create/edit to trusted service accounts
• Consider network policies to limit ingress controller pod egress

For Platform Teams

• Enable annotation validation in ingress-nginx configuration
• Monitor ingress controller logs for configuration reload errors (may indicate injection attempts)
• Implement runtime security monitoring on the ingress controller pod
• Consider moving to a Gateway API-based ingress solution with stronger input validation

Disclosure Timeline

• 2026-01-15: Vulnerability discovered during Kubernetes security research
• 2026-01-18: Reported to Kubernetes Security Response Committee via [email protected]
• 2026-02-12: Vulnerability confirmed by the ingress-nginx maintainers
• 2026-03-04: Patches released in versions 1.13.8, 1.14.4, and 1.15.0
• 2026-03-09: CVE-2026-3288 assigned and publicly disclosed

Acknowledged by Tabitha Sable, Kubernetes Security Response Committee.

References

• Kubernetes Issue #137560
• GitHub Security Advisory (GHSA-c56h-j8gw-3v54)
• NVD Entry
• MITRE Entry
• GitHub PoC