CVE-2025-1098

What it actually does

The flaw allows a user who can create or modify Kubernetes Ingress resources to abuse the ingress-nginx `mirror-target` or `mirror-host` annotations to inject unintended NGINX configuration. When the ingress-nginx controller renders and reloads its generated configuration, the injected directives can execute attacker-controlled behavior in the context of the ingress-nginx controller. Because the controller commonly runs with broad Kubernetes API permissions, successful exploitation can expose Kubernetes Secrets accessible to that controller, and in default deployments this may include cluster-wide Secrets. The reported CVSS is 8.8 and the exploit maturity is listed as weaponized, indicating practical exploitation paths exist despite requiring authenticated Kubernetes permissions.

Why it matters to the business

A compromised ingress controller can become a high-impact cluster compromise point: attackers may steal application credentials, TLS keys, service tokens, database passwords, and other Kubernetes Secrets; alter traffic routing; disrupt externally exposed services; or use the controller as a foothold for broader cloud or cluster access. The high EPSS score of 0.83421 and weaponized exploit maturity make this a priority even though it is not currently listed in CISA KEV. The supplied affected-product metadata lists `ffmpeg (Debian:14)` with a fixed version of `7:7.1.1-1`, while the vulnerability description describes ingress-nginx; security teams should treat this as a metadata inconsistency and validate both package exposure and ingress-nginx controller exposure before closing the issue.

How an attack unfolds

An attacker first obtains Kubernetes credentials or workload permissions that allow them to create or update an Ingress object in a namespace watched by ingress-nginx. They then submit an Ingress manifest containing malicious values in `nginx.ingress.kubernetes.io/mirror-target` or `nginx.ingress.kubernetes.io/mirror-host`. The ingress-nginx controller observes the resource change, renders those annotation values into its NGINX configuration, and reloads NGINX. Because the annotation value is not safely constrained, attacker-controlled configuration is interpreted by NGINX and can be used to execute code or cause the controller to access and disclose Kubernetes Secrets. After execution, the attacker may enumerate Secrets available to the controller service account, exfiltrate credentials, modify ingress behavior, and pivot to applications or cloud services that trust those credentials.

How to fix it

Patch the affected component and remove unsafe configuration paths. For ingress-nginx exposure, upgrade the ingress-nginx controller to a vendor-supported fixed release and ensure all controller replicas are replaced, not just the Helm chart metadata. If the supplied package metadata applies to the environment, upgrade `ffmpeg (Debian:14)` to `7:7.1.1-1` or later. Because the description and affected-product metadata conflict, verify the authoritative vendor advisory for the deployed component before marking remediation complete. As compensating controls, restrict who can create or update Ingress resources, use admission control policies to deny or tightly validate `nginx.ingress.kubernetes.io/mirror-target` and `nginx.ingress.kubernetes.io/mirror-host`, disable risky annotation usage where possible, scope the ingress-nginx controller service account to the minimum required permissions, avoid cluster-wide Secret access, rotate Secrets that may have been exposed, and review existing Ingress objects for suspicious annotation values.

How to confirm the fix worked

Confirm the ingress-nginx controller image or package version is a fixed release from the vendor and that all running controller pods use the updated image. Query all namespaces for Ingress resources containing `nginx.ingress.kubernetes.io/mirror-target` or `nginx.ingress.kubernetes.io/mirror-host` and validate that any remaining use is expected and policy-compliant. Confirm admission policies prevent untrusted users from setting these annotations. Review the ingress-nginx controller service account permissions and verify it no longer has unnecessary cluster-wide Secret access. If the Debian package mapping is applicable, verify `ffmpeg` on Debian 14 is installed at `7:7.1.1-1` or later using the system package manager. Finally, force a controller rollout and confirm no old vulnerable pods remain running.

Typical attack path

1. Obtain Kubernetes API access with permission to create or update Ingress resources in a namespace handled by ingress-nginx.
2. Identify that the cluster uses ingress-nginx and that annotations are permitted on Ingress objects.
3. Create or modify an Ingress containing attacker-controlled `nginx.ingress.kubernetes.io/mirror-target` or `nginx.ingress.kubernetes.io/mirror-host` annotation values.
4. Wait for the ingress-nginx controller to reconcile the Ingress and regenerate/reload NGINX configuration.
5. Abuse the injected configuration to execute code or access data in the ingress-nginx controller context.
6. Use the controller service account permissions to read Kubernetes Secrets, with potential cluster-wide impact in default installations.
7. Exfiltrate credentials or tokens and pivot to applications, namespaces, cloud services, or administrative interfaces protected by those Secrets.

How to detect it

To determine whether exploitation already occurred, review Kubernetes audit logs for `create`, `update`, or `patch` operations on Ingress resources containing `nginx.ingress.kubernetes.io/mirror-target` or `nginx.ingress.kubernetes.io/mirror-host`, especially changes made by unexpected users, service accounts, CI/CD jobs, or recently created credentials. Inspect current and historical Ingress manifests for suspicious annotation values, including multiline values, encoded content, shell metacharacters, unexpected NGINX directives, references to local files, or destinations not used for legitimate traffic mirroring. Review ingress-nginx controller logs for configuration reloads, NGINX syntax errors, emergency errors, crashes, unexpected reload loops, or generated configuration containing mirror annotations. Use container runtime, EDR, or Kubernetes node telemetry to look for unexpected child processes spawned by the ingress-nginx controller or NGINX worker processes, such as shells, interpreters, network transfer utilities, or Kubernetes clients. Review Kubernetes API audit events for Secret `list`, `get`, or `watch` activity by the ingress-nginx controller service account, particularly activity that is new, high-volume, cross-namespace, or temporally close to an Ingress annotation change. If suspicious activity is found, preserve the controller pod filesystem, generated NGINX configuration, controller logs, Kubernetes audit logs, and relevant Ingress object history before rotating exposed Secrets.

• nginx.ingress.kubernetes.io/mirror-target
• nginx.ingress.kubernetes.io/mirror-host
• mirror-target
• mirror-host
• "resource":"ingresses"
• "verb":"create"
• "verb":"update"
• "verb":"patch"
• "resource":"secrets"
• "verb":"get"
• "verb":"list"
• "verb":"watch"
• ingress-nginx-controller
• /etc/nginx/nginx.conf
• /var/log/nginx/error.log
• nginx: [emerg]
• nginx: configuration file
• reloading NGINX
• unexpected error reloading NGINX
• /bin/sh
• /bin/bash
• curl
• wget
• nc
• ncat
• python
• perl

What your security team should do

• Immediately inventory clusters using ingress-nginx and identify namespaces where users or automation can create or update Ingress resources.
• Prioritize remediation because EPSS is high, exploitation is listed as weaponized, and compromise can expose Kubernetes Secrets.
• Upgrade ingress-nginx controllers to fixed vendor-supported versions and verify all replicas are replaced.
• Deploy admission control rules to block or restrict `nginx.ingress.kubernetes.io/mirror-target` and `nginx.ingress.kubernetes.io/mirror-host` for non-administrative users.
• Review all existing Ingress objects for suspicious mirror annotation values, unexpected multiline content, encoded strings, shell metacharacters, or directives unrelated to legitimate traffic mirroring.
• Reduce ingress-nginx controller RBAC privileges, especially permissions to read Secrets across all namespaces.
• Rotate Secrets accessible to the ingress-nginx controller if suspicious annotations, controller process anomalies, or unauthorized Secret reads are found.
• Investigate Kubernetes audit logs for Ingress changes followed by unusual controller behavior or Secret access.
• Resolve the metadata inconsistency by validating whether the environment is affected through ingress-nginx, Debian `ffmpeg`, or both, and apply the listed fixed package version where relevant.