CVE-2026-77180: NGINX Ingress Controller annotations allow config injection

What it is

NGINX Ingress Controller turns Kubernetes objects into NGINX configuration. On affected versions, multiple user-controllable fields, including Ingress annotations, are written into that generated configuration without sanitization (CWE-76). A user who can create or modify these objects can put NGINX directives into a value and have the controller apply them.

F5 says this could let the attacker create or delete files or disable services. The attacker needs a Kubernetes account that can already write to these resources, so this is a privilege-escalation problem for multi-tenant clusters, not a bug anyone on the internet can reach. F5 states there is no data plane exposure and the issue is limited to the control plane.

Nothing suggests it is exploited. CISA’s SSVC entry in the CVE record says exploitation “none” and not automatable. We found no public proof of concept. The reporter is credited as kodareef5.

Am I affected?

You’re affected if you run NGINX Ingress Controller 5.0.0 to 5.5.x or 2026-lts-r1 to 2026-lts-r4. The risk is real when people or service accounts other than cluster administrators can create or change Ingress, VirtualServer, VirtualServerRoute, Policy or DosProtectedResource objects (the list is from F5’s workarounds).

Versions past End of Technical Support were not evaluated by F5.

To check the running version, look at the controller image tag in your deployment (for example with kubectl describe deployment on the controller).

What to do

1. Upgrade to 5.6.0 or 2026-lts-r5. If you are on an unsupported release, move to a supported one.
2. If you can’t upgrade tonight, limit who can write. Restrict RBAC create, update and patch permissions on VirtualServer, VirtualServerRoute, Policy, DosProtectedResource and Ingress to trusted cluster administrators. Production impact: teams that deploy their own Ingress objects lose that ability until the upgrade.
3. Or add an admission policy. F5 suggests Kyverno, OPA Gatekeeper or a ValidatingAdmissionPolicy that rejects special characters in user-controlled fields. Test it first: a policy that is too strict can block valid deployments.
4. Review who has had write access to these resources while you ran an affected version. If an untrusted account had it, check the generated configuration (below) and redeploy the controller if you find anything you didn’t write.

Detection

No indicators of compromise have been published, and no log signatures were found in the sources. Practical checks:

• Review Kubernetes audit logs for creates and updates to Ingress, VirtualServer, VirtualServerRoute, Policy and DosProtectedResource objects by accounts that aren’t cluster administrators.
• Look for annotation or field values that contain newlines, semicolons, braces or NGINX directives.
• Compare the NGINX configuration generated inside the controller pods with what your manifests should produce, and look for unexpected directives or files.
• Watch for controller pods whose NGINX process stops or restarts unexpectedly.