Loading vulnerability…
CVE-2026-4342 is a high-severity vulnerability in ingress-nginx caused by insufficient validation of Ingress annotations. A crafted combination of annotations can inject arbitrary configuration into the generated nginx configuration. According to the provided advisory context, this configuration injection can result in arbitrary code execution in the security context of the ingress-nginx controller and disclosure of Kubernetes Secrets accessible to that controller. The issue affects ingress-nginx versions prior to v1.13.9, v1.14.5, and v1.15.1. The advisory also notes that suspicious data in the rules.http.paths.path field of an Ingress resource may indicate exploitation attempts.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
rules.http.paths.path, and audit existing Ingress definitions for unexpected annotation combinations. Because default installations may allow the controller to access Secrets cluster-wide, limit the controller's Secret access where operationally feasible to reduce blast radius until patched.Patch, then assume compromise.
rules.http.paths.path, as potential indicators of exploitation.1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos.
This repository is a full proof-of-concept environment for reproducing CVE-2026-4342 against ingress-nginx. It is not just a single exploit file; it includes infrastructure provisioning, vulnerable controller deployment, malicious Kubernetes manifests, execution scripts, verification, and cleanup. Repository structure: - `infra/`: Terraform for provisioning an OVH managed Kubernetes cluster and generating/merging kubeconfig. `main.tf` creates the cluster and node pool; `kubeconfig.tf` writes `shared/kubeconfig.yaml` and merges it into the user's kubeconfig. - `config/`: Kubernetes manifests and Helm values. `helm-values.yaml` intentionally deploys vulnerable ingress-nginx v1.15.0, enables snippet annotations, disables admission webhooks, and keeps RBAC enabled. `test-secrets.yaml` creates fake Secrets in `default`, `kube-system`, and `target-ns`. `backend-service.yaml` deploys a simple nginx backend. The two key exploit manifests are `exploit-ingress-rce.yaml` and `exploit-ingress-secrets.yaml`. - `scripts/`: Operational wrappers. `configure.sh` installs ingress-nginx and supporting resources. `exploit.sh` executes the PoC end-to-end, captures outputs, and stores artifacts in `results/<timestamp>/`. `verify.sh` checks acceptance criteria. `teardown.sh` removes deployed resources. - `shared/env.json`: Tracks environment state. - `results/`: Output directory for proof artifacts. Main exploit capabilities: 1. RCE via annotation injection: `config/exploit-ingress-rce.yaml` abuses `nginx.ingress.kubernetes.io/configuration-snippet` to inject a new nginx `location /_rce_output` block containing `content_by_lua_block`. The Lua uses `io.popen("id && cat /etc/hostname")` to execute shell commands inside the ingress-nginx controller pod and returns the output in the HTTP response. The Ingress also includes a suspicious route `/_cve_2026_4342_rce` as a detection artifact. 2. Secret disclosure via annotation injection: `config/exploit-ingress-secrets.yaml` injects `location /_read_secrets` with Lua that reads the mounted ServiceAccount token from `/var/run/secrets/kubernetes.io/serviceaccount/token`, builds the Kubernetes API base URL from `KUBERNETES_SERVICE_HOST` and `KUBERNETES_SERVICE_PORT_HTTPS` (defaulting to `https://kubernetes.default.svc:443`), and queries `/api/v1/namespaces/<ns>/secrets` or `/api/v1/namespaces/<ns>/secrets/<name>` using `resty.http` with `ssl_verify = false`. The response body is returned directly to the caller. A second suspicious route `/_cve_2026_4342_secrets` is included as a detection artifact. 3. Automated exploitation and evidence collection: `scripts/exploit.sh` discovers the controller pod, node IP, and NodePort, then applies each malicious Ingress, waits for config reload, and uses curl against `http://${NODE_IP}:${NODE_PORT}` to retrieve `/_rce_output` and `/_read_secrets?...`. It saves proof to `results/` and also copies the malicious manifests and an ingress inventory JSON for detection analysis. If the HTTP path fails, it falls back to `kubectl exec` to demonstrate command execution and ServiceAccount token-based API access from inside the controller pod. Overall purpose: The repository is designed to stand up a controlled lab that demonstrates how unsanitized ingress-nginx snippet annotations can be turned into arbitrary nginx/Lua injection, leading first to code execution in the controller pod and then to cluster secret exfiltration through the controller's privileged ServiceAccount. It is a practical, operational PoC rather than a scanner or detector, though it intentionally embeds detection artifacts in paths and manifests for blue-team testing.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
22 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.