Summary
Traefik's Kubernetes Ingress NGINX provider can generate an HTTP router for ssl-passthrough Ingresses without applying configured access-control annotations. An unauthenticated attacker who reaches the relevant HTTP entry point with the Ingress host may access a backend intended to require authentication, source-range restrictions, or an external authorization check.
Traefik's Kubernetes Ingress NGINX provider can generate an HTTP router for ssl-passthrough Ingresses without applying configured access-control annotations. An unauthenticated attacker who reaches the relevant HTTP entry point with the Ingress host may access a backend intended to require authentication, source-range restrictions, or an external authorization check.
Affected context
The issue can occur in Traefik deployments using the Kubernetes Ingress NGINX provider when an ssl-passthrough Ingress is exposed through a non-TLS HTTP entry point. Risk depends on the generated router path, the presence of access-control annotations such as auth-type, auth-url, or whitelist-source-range, and whether an attacker can reach the entry point using the associated Ingress host.
The issue can occur in Traefik deployments using the Kubernetes Ingress NGINX provider when an ssl-passthrough Ingress is exposed through a non-TLS HTTP entry point. Risk depends on the generated router path, the presence of access-control annotations such as auth-type, auth-url, or whitelist-source-range, and whether an attacker can reach the entry point using the associated Ingress host.
Exploit preconditions
- Attack surface: An HTTP entry point handled by the Kubernetes Ingress NGINX provider
- Required access: Network reachability to the entry point and knowledge of, or ability to supply, the Ingress host
- Trigger point: Request routing for an ssl-passthrough Ingress on a non-TLS entry point
- Why exploitation is possible: The generated HTTP router may omit the Ingress's access-control annotations, allowing requests to reach a protected backend without the intended checks
- Attack surface: An HTTP entry point handled by the Kubernetes Ingress NGINX provider
- Required access: Network reachability to the entry point and knowledge of, or ability to supply, the Ingress host
- Trigger point: Request routing for an ssl-passthrough Ingress on a non-TLS entry point
- Why exploitation is possible: The generated HTTP router may omit the Ingress's access-control annotations, allowing requests to reach a protected backend without the intended checks
Why this happens
The underlying bug is an authorization-control omission during router generation. For the affected ssl-passthrough and non-TLS routing combination, security annotations associated with the Ingress are not propagated to the generated HTTP router. This behavior maps to CWE-306, Missing Authentication for Critical Function, because a backend request path that should invoke authentication or authorization controls can instead proceed without them.
The underlying bug is an authorization-control omission during router generation. For the affected ssl-passthrough and non-TLS routing combination, security annotations associated with the Ingress are not propagated to the generated HTTP router. This behavior maps to CWE-306, Missing Authentication for Critical Function, because a backend request path that should invoke authentication or authorization controls can instead proceed without them.
Potential impact
- Unauthenticated users may access protected backend functionality
- Sensitive application data could be disclosed
- Attackers could perform actions intended only for authenticated users
- Source-range restrictions or external authorization policies may be bypassed
- Unauthorized requests may be difficult to investigate when routing activity is not logged
- Unauthenticated users may access protected backend functionality
- Sensitive application data could be disclosed
- Attackers could perform actions intended only for authenticated users
- Source-range restrictions or external authorization policies may be bypassed
- Unauthorized requests may be difficult to investigate when routing activity is not logged
General mitigation guidance
Mitigation generally focuses on ensuring that every generated route preserves
the authentication and authorization requirements declared by the source
Ingress.
Defensive patterns include:
- Applying access-control middleware or equivalent policy consistently to all
HTTP and HTTPS router variants
- Treating ssl-passthrough and non-TLS routing combinations as explicit,
security-sensitive cases during configuration processing
- Using deny-by-default routing for protected backends
- Reducing exposure of HTTP entry points and limiting them to intended networks
- Enforcing authentication and authorization at the backend as a
defense-in-depth control
- Running routing components with only the privileges required for their
deployment
- Preserving audit logging for denied and permitted access-control decisions
Mitigation generally focuses on ensuring that every generated route preserves
the authentication and authorization requirements declared by the source
Ingress.
Defensive patterns include:
- Applying access-control middleware or equivalent policy consistently to all
HTTP and HTTPS router variants
- Treating ssl-passthrough and non-TLS routing combinations as explicit,
security-sensitive cases during configuration processing
- Using deny-by-default routing for protected backends
- Reducing exposure of HTTP entry points and limiting them to intended networks
- Enforcing authentication and authorization at the backend as a
defense-in-depth control
- Running routing components with only the privileges required for their
deployment
- Preserving audit logging for denied and permitted access-control decisions
How teams detect issues like this
Detection can combine configuration analysis, code review, and runtime
verification.
Useful approaches include:
- Static analysis that checks whether security annotations are propagated to
every generated router variant
- Code review of provider logic handling ssl-passthrough, entry-point
selection, and middleware attachment
- Policy checks requiring authentication or authorization on routes that
expose protected services
- Integration tests that send unauthenticated requests through each
entry-point and protocol combination
- Runtime monitoring for successful access to protected backends without a
corresponding authentication or authorization event
- Automated security review tools that flag route-generation paths where
access-control middleware may be omitted
Detection can combine configuration analysis, code review, and runtime
verification.
Useful approaches include:
- Static analysis that checks whether security annotations are propagated to
every generated router variant
- Code review of provider logic handling ssl-passthrough, entry-point
selection, and middleware attachment
- Policy checks requiring authentication or authorization on routes that
expose protected services
- Integration tests that send unauthenticated requests through each
entry-point and protocol combination
- Runtime monitoring for successful access to protected backends without a
corresponding authentication or authorization event
- Automated security review tools that flag route-generation paths where
access-control middleware may be omitted
