Detecting CVE-2026-3288 & CVE-2026-24512: Ingress-nginx configuration injection vulnerabilities for Kubernetes

On March 9, 2026, the Kubernetes ingress-nginx project merged a fix for CVE-2026-3288 (CVSS 8.8 HIGH), a configuration injection vulnerability in the NGINX Ingress Controller. The vulnerability allows any user with permission to create or modify Ingress resources by inserting a double-quote character (“) into the Ingress path field. Because the field does not properly sanatize input, an attacker can break the expected syntax with a quotation mark and inject arbitrary nginx configuration directives into the generated configuration. The official advisory states that the vulnerability can lead to remote code execution (RCE) and the disclosure of secrets accessible to the controller.

CVE-2026-3288 is also closely related to CVE-2026-24512, a path injection vulnerability fixed one month prior. The fix for CVE-2026-24512 introduced the sanitizeQuotedRegex() function and applied it to buildLocation(), but missed buildProxyPass(), leaving the rewrite directive vulnerable to the same class of injection. These vulnerabilities are the latest in a string of ingress-nginx security challenges, which precipitate the project's coming retirement at the end of the month.

The Sysdig Threat Research Team (TRT) has analyzed the root cause of both CVEs and built a Falco detection rule that alerts users to exploitation attempts via Kubernetes audit logs. The Sysdig TRT’s full analysis and findings of the vulnerabilities are detailed below.

Affected Versions

• Affected: NGINX Ingress Controller versions before v1.13.8, v1.14.4, and v1.15.0
• Fixed: v1.13.8, v1.14.4, v1.15.0 (released March 9, 2026)
• Fix commit: PR #14667
• Related: CVE-2026-24512 (path injection via buildLocation(), fixed in v1.13.7 and v1.14.3 by PR #14501)

Root cause: Missing sanitization

The NGINX Ingress Controller translates Kubernetes Ingress objects into nginx configuration. When an Ingress includes a rewrite-target annotation, the controller generates a rewrite directive inside the corresponding location block via the buildProxyPass() function in template.go, as seen below:

return fmt.Sprintf(`
rewrite "(?i)%s" %s break;
%v%v %s%s;`, path, location.Rewrite.Target, xForwardedPrefix, proxyPass, proto, upstreamName)

The path variable comes directly from the Ingress spec.rules.http.paths.path field and is interpolated into a double-quoted nginx string without any escaping. If the path contains a (") character, it closes the quoted regex prematurely, and everything after it is interpreted as raw nginx configuration.

The companion function buildLocation() was fixed one month earlier as part of CVE-2026-24512. That fix (PR #14501) introduced the sanitizeQuotedRegex() function, which escapes \ and " characters, and applied it to buildLocation():

func buildLocation(input interface{}, enforceRegex bool) string {
    path := sanitizeQuotedRegex(location.Path)
    if enforceRegex {
        return fmt.Sprintf(`~* "^%s"`, path)
    }
    // ...
}

However, the same fix was not applied to buildProxyPass(). The fix for CVE-2026-3288 in PR #14667 adds the same sanitizeQuotedRegex() call to buildProxyPass(). It is a one-line change to avoid the arbitrary code execution flaw.

Bypassing the inspector

The NGINX Ingress Controller includes a DeepInspect function that validates Ingress objects before processing them. This inspector runs each path through CheckRegex, which matches against a blocklist of known-dangerous nginx directives:

invalidAliasDirective = regexp.MustCompile(`(?s)\s*alias\s*.*;`)
invalidRootDirective  = regexp.MustCompile(`(?s)\s*root\s*.*;`)
invalidEtcDir         = regexp.MustCompile(`/etc/(passwd|shadow|group|nginx|ingress-controller)`)
invalidSecretsDir     = regexp.MustCompile(`/var/run/secrets`)
invalidByLuaDirective = regexp.MustCompile(`.*_by_lua.*`)

This blocklist is incomplete. Directives such as return, set, and try_files are not checked and pass through without error. We confirmed that return bypasses the inspector and executes successfully with injected payloads.

Additionally, the inspector defines a validPathType regex that would enforce alphanumeric-only paths:

validPathType = regexp.MustCompile(`(?i)^/[[:alnum:]._\-/]*$`)

This regex is never called. It exists as dead code, meaning the inspector accepts paths containing characters such as ("), (,), and (;), spaces, #, and other special characters without restriction.

Exploitation

Prerequisites

The attacker must have permission to create or modify Ingress resources in any namespace on a cluster running a vulnerable NGINX Ingress Controller. 

Impact

The official advisory states this vulnerability can lead to arbitrary code execution and disclosure of secrets accessible to the controller. In the default installation, the NGINX Ingress Controller can access all secrets cluster-wide. The inspector’s blocklist does not cover directives such as include or ssl_engine, which could provide paths to code execution or file disclosure beyond what we tested.

During our testing, the Sysdig TRT confirmed that the following attack scenarios are possible using the return directive, which the inspector does not block:

• Hijack responses by serving attacker-controlled content on any path.
• Redirect users to phishing pages or credential harvesting sites.
• Steal credentials by using nginx variables such as $http_authorization to reflect Bearer tokens, API keys, or Basic auth credentials back in the response body.
• Leak internal state by returning nginx variables such as $server_addr to expose the controller pod’s internal IP address.
• Deny service by injecting an invalid configuration that prevents nginx from reloading.

Sysdig threat intelligence

Detection of this vulnerability has been added to the Sysdig Secure Threat Intelligence page, accessible at Home -> Threat Intelligence or by searching for “Remote Code Execution Vulnerabilities in NGINX Ingress Controller.”

Detection with Falco

The following Falco rule detects creation or modification of Ingress resources containing a double quote in the path, using Kubernetes audit log data:

rule: Ingress-NGINX Path Configuration Injection
  desc: >
    Detects Kubernetes Ingress resources where the path field contains a
    double-quote character, indicating potential ingress-nginx configuration
    injection via CVE-2026-3288 (buildProxyPass) or CVE-2026-24512
    (buildLocation). Both vulnerabilities use the path field as the
    injection vector.
  condition: >
    kevt and ingress and kmodify and response_successful
    and jevt.value[/requestObject/spec/rules/0/http/paths/0/path] contains "\""
  output: >
    Suspicious ingress path with config injection characters detected -
    possible CVE-2026-3288 / CVE-2026-24512
    (user=%ka.user.name
     verb=%ka.verb
     ingress=%ka.target.name
     ns=%ka.target.namespace
     path=%jevt.value[/requestObject/spec/rules/0/http/paths/0/path])
  priority: CRITICAL
  source: k8s_audit
  tags: [k8s, cve-2026-3288, cve-2026-24512, ingress-nginx, config-injection]

Both CVE-2026-3288 and CVE-2026-24512 require a (") character in the Ingress path field, which is never present in legitimate Ingress definitions. This makes it a high-fidelity detection signal that covers both vulnerabilities with a single rule.

Sysdig Secure customers are automatically protected with the Ingress-NGINX Malicious Annotation or Path Injection in the Sysdig K8s Notable Events, and any questions should be directed toward users’ Sysdig account teams.

How the detection works

Sysdig and Falco monitor Kubernetes audit events for Ingress create, update, or patch operations (kmodify) that completed successfully (response_successful). It then inspects the raw request body via jevt.value[/requestObject/spec/rules/0/http/paths/0/path], which extracts the path value from the first HTTP path in the Ingress spec. If that value contains a (") character, the detection sends an alert.

During validation, we deployed both a benign Ingress (path: /app) and the exploit Ingress on the same cluster. The alert fired exclusively on the exploit Ingress across create and update operations, with zero false positives on the benign resource.

Recommendations

• Update ingress-nginx to v1.13.8, v1.14.4, or v1.15.0, which include the sanitizeQuotedRegex() fix in buildProxyPass().
• Deploy the Falco rule above to detect exploitation attempts via Kubernetes audit logs.
• Restrict Ingress creation permissions using rule-based access control (RBAC), limiting which users and service accounts can create or modify Ingress resources.
• Verify the ingress-nginx admission webhook is enabled (it is on by default in the Helm chart), which runs nginx -t against the generated configuration and rejects Ingress objects that produce an invalid configuration.
• Audit existing Ingress resources for paths containing special characters: kubectl get ingress -A -o json | jq '.items[].spec.rules[].http.paths[].path' | grep '[";\\#]'.
• Monitor NGINX Ingress Controller logs for "received invalid ingress" messages, which indicate the inspector rejected a potentially malicious Ingress.

Mitigations

Several layers of defense reduce the likelihood of successful exploitation in production environments.

• This is not an internet-facing vulnerability. The attacker must be authenticated to the Kubernetes API and have permissions to create or modify Ingress resources. The most realistic threat is a compromised CI/CD pipeline or a malicious insider with namespace-level access.
• The admission webhook catches some payloads. The ingress-nginx Helm chart enables the admission webhook by default, which validates the generated nginx configuration before accepting an Ingress. During testing, we had to delete the webhook to deploy the exploit. However, payloads that produce valid nginx syntax (such as return 200) pass this check and are not blocked.
• A second sanitization function limits reachability on newer versions. On clusters running v1.13.7 or v1.14.3 (where the CVE-2026-24512 fix is applied), the companion function buildLocation() correctly escapes the path, producing a location regex that no normal HTTP request can match. The injected directives exist in the nginx configuration but cannot be triggered. However, for organizations still running older versions where buildLocation() is also unsanitized, the location regex is matchable, and the injected code is directly reachable via HTTP requests.

Conclusion

CVE-2026-3288 is a configuration injection vulnerability that stems from an incomplete fix for CVE-2026-24512. When sanitizeQuotedRegex() was introduced to protect buildLocation() in February 2026, the same sanitization was not applied to buildProxyPass(), leaving the rewrite directive vulnerable to the same class of path injection. The inspector’s reliance on a blocklist of known-dangerous directives, combined with dead validation code that is never called, means that a wide range of injection payloads pass through without detection.

This vulnerability follows a pattern seen in previous ingress-nginx configuration injection CVEs, including CVE-2026-24512 (path injection via buildLocation()), CVE-2021-25742 (snippet injection), and CVE-2024-7646 (annotation-based injection via \r). Each instance highlights the difficulty of safely interpolating user-controlled input into nginx configuration templates. 

Organizations running ingress-nginx should prioritize updating to v1.14.4 or later and deploy the Sysdig Secure or the Falco detection rule to catch exploitation attempts in environments where immediate patching is not possible.