Traefik EUVD-2026-113927

Exploitation requires the default configuration where allowCrossNamespaceResources is disabled, and only affects Traefik v3.7.11 through v3.7.14 using the Kubernetes Ingress NGINX provider (Traefik v2 and pre-3.7.11 are not affected). The attacker must have rights to create Ingresses in a namespace (PR:H), and - per the AT:P attack requirement - a target CA secret must ALREADY be referenced by another Ingress so that the shared client-authentication TLS option is cached; only then does the later Ingress reuse the cached option and bypass the cross-namespace check. Limiting factors: impact is confined to enforcing a foreign CA on the attacker's own routes and learning whether the secret exists and is in use - the secret's contents are NOT disclosed, and the bypass does not occur on the first (uncached) build of the TLS option.

All decision signals agree this is a low-priority, low-risk issue. The vendor-supplied CVSS 4.0 base score is 2.1 (Low) with vector AV:N/AC:L/AT:P/PR:H/UI:N/VC:N/VI:L/VA:N/SC:L/SI:N/SA:N: network vector but high privileges required (PR:H - the attacker must already be able to create Ingresses), an attack requirement present (AT:P - a shared client-auth TLS option must already be cached by another Ingress), no confidentiality impact on the vulnerable system (VC:N), and only low integrity/subsequent-confidentiality impact. KEV status is NO (not listed by CISA), so this is not confirmed as actively exploited. No public exploit was identified - the two references are the Traefik GHSA advisory and the VulnCheck advisory, both write-ups rather than working exploit code. The vuln.today decision label is 'monitor', consistent with the low score. No EPSS score was provided in the input, so real-world exploitation probability cannot be quantified here. There are no conflicting signals: a CVSS Low, no KEV, no PoC, and a 'monitor' decision all point the same direction. This is a genuine but minor cross-namespace isolation weakness, not an urgent priority.

In a multi-tenant Kubernetes cluster, a user who only has rights to create Ingresses in their own namespace notices that another namespace already uses a CA secret via the nginx.ingress.kubernetes.io/auth-tls-secret annotation. They create an Ingress referencing that foreign CA secret; because the shared client-authentication TLS option is already cached, the cross-namespace check is skipped and the foreign CA is enforced as the client certificate authority on the attacker's own routes, confirming the secret exists and is in use. No public exploit code exists, and the secret's contents are never disclosed.