A double quote in an ingress path: config injection to RCE in ingress-nginx

This is not a memory-corruption exploit or a clever protocol trick. It is configuration injection: untrusted input crosses a boundary into a config file that a privileged process then loads and acts on. ingress-nginx sits at the front door of a large share of Kubernetes clusters, turning Ingress objects into live nginx configuration on every change. That translation step is the vulnerability. The Kubernetes security team published the advisory for CVE-2026-3288 alongside a cluster of siblings, CVE-2026-24512, CVE-2026-24513, CVE-2026-24514, and CVE-2026-1580, all fixed together in v1.13.8, v1.14.4, and v1.15.0 on 9 March 2026, with credit to reporter Kai Aizen. We do not publish a weaponized payload. We explain the mechanism, who can reach it, and how to know whether your clusters are exposed. Verifiable security.

How a quote becomes code

The controller's job is to convert Kubernetes Ingress objects into an nginx configuration and reload nginx. Several annotations feed values directly into that generated file. The nginx.ingress.kubernetes.io/rewrite-target annotation is the clearest example: its value is meant to become the target of a rewrite rule. The controller places that value inside a generated directive, roughly as if it were writing rewrite ... "your-value"; into the config. The intended value is a path, which the controller assumed was safe to drop into the file verbatim.

The assumption breaks the moment the value contains a quote. A " in the annotation closes the string the controller opened, and the characters after it are no longer data, they are configuration. nginx reads them as new directives on the same reload. That is the whole trick: not a buffer overflow, not a parser bug in nginx itself, just a value that was trusted to be a path being allowed to redefine the file it was written into. The same flaw reaches the path field of an Ingress rule, which is likewise rendered into the generated configuration.

Injecting configuration would be serious on its own, because nginx configuration controls routing, TLS termination, and access rules for everything behind the controller. But it is more powerful than routing. Certain directives, including module and Lua hook mechanisms available in the ingress build, can cause code to run in the controller's process. Once the attacker can write arbitrary directives, they are no longer editing routes, they are choosing what the controller executes. That is how a config-injection bug becomes remote code execution, CWE-94 territory, without ever touching nginx's own memory.

Illustrative structure of the quote breakout. No working directive payload is shown.

Why the blast radius is the whole cluster

Two facts turn this from a controller bug into a cluster event. The first is where the code runs. The ingress controller is not a low-value pod. In a default installation its service account can read Secrets across the whole cluster, because it needs TLS certificates and related material to terminate connections. Code execution in that process therefore doubles as a cluster-wide secret-disclosure primitive: database credentials, cloud tokens, service-account keys, anything held as a Secret the controller can list. The second fact is who can pull the trigger. The attacker does not need cluster-admin or a shell on a node. They need permission to create or modify Ingress objects.

In a lot of real clusters that permission is handed out freely, to a CI pipeline that deploys applications, a tenant namespace in a shared cluster, or a platform team's self-service workflow. Ingress creation reads as routine, not privileged, so it rarely sits behind the scrutiny reserved for RBAC edits or node access. That gap between how the permission feels and what this bug turns it into is the entire risk.

An Ingress looks like routing metadata. In this bug it is a write primitive into the configuration of the process that holds your cluster's Secrets.

The lifecycle problem: this class will not keep getting fixed

Treat this as more than one patch. ingress-nginx is being retired. The project has signaled that it is winding down, which means the stream of maintainers who found and fixed this injection class is drying up. CVE-2026-3288 and its siblings were caught this time. The next annotation that templates untrusted input into the config may not be, and clusters that stay on ingress-nginx past its maintenance horizon inherit that risk permanently. The fix for the specific CVE is an upgrade. The fix for the class is a migration plan and an admission-control net that does not depend on the controller staying maintained.

How to know whether you are exposed

How Celvex catches this

The lesson generalizes past one controller. Any component that turns user-supplied objects into a configuration file for a privileged process is templating strings across a trust boundary, and every such boundary needs the same neutralization a database query or a shell command needs. ingress-nginx forgot it for one annotation, and the cost was code execution next to every Secret in the cluster. Ask the question everywhere it applies: what untrusted values reach my generated configs, and what can those configs make the reader do.

Verifiable security. Find it. Prove it. Fix it. Verify the fix held. That is what we ship.