[BUG] v5.0.3 breaks `/api/auth/nginx` for Kubernetes ingress-nginx users (Strict X-Forwarded-Uri requirement)

[Dual-0]

Describe the bug
The recent security patches in v5.0.3 (GHSA-xg2q-62g2-cvcm / GHSA-3q28-qjrv-qr39) introduced strict enforcement of X-Forwarded-* headers, explicitly rejecting requests with empty or missing X-Forwarded-Uri headers. This completely breaks the /api/auth/nginx endpoint for Kubernetes users who are still one the NGINX Ingress Controller (ingress-nginx).

During an auth_request subrequest, NGINX natively sends X-Original-URI and X-Original-URL, not X-Forwarded-Uri. Because snippet annotations are disabled by default in modern ingress-nginx controllers for security reasons (CVE-2021-25742), users cannot use auth-snippet to manually inject the required X-Forwarded-Uri header, leaving them hard-blocked.

To Reproduce
Steps to reproduce the behavior:

1. Deploy Tinyauth v5.0.3 on a Kubernetes cluster using ingress-nginx.
2. Protect an application using standard NGINX annotations (setting auth-url to http://<tinyauth>/api/auth/nginx).
3. Attempt to access the protected application in a browser.
4. See 400 Bad Request from the protected app.

Expected behavior
The /api/auth/nginx endpoint should either natively parse and accept NGINX's default X-Original-URI header, or not immediately reject the request when X-Forwarded-Uri is missing on this specific endpoint.

Logs

2026-03-11T19:26:32.015071502Z 2026-03-11T19:26:32Z ERR internal/controller/proxy_controller.go:339 > Header not found header=x-forwarded-uri log_stream=app
2026-03-11T19:26:32.015118142Z 2026-03-11T19:26:32Z WRN internal/middleware/zerolog_middleware.go:62 > Client Error address=10.0.132.34:50242 client_ip=2a01:599:c04:4d2a:b942:d76:62bb:8614 latency="194.082µs" log_stream=http method=GET path=/api/auth/nginx status=400
2026-03-11T19:26:33.545161041Z 2026-03-11T19:26:33Z ERR internal/controller/proxy_controller.go:339 > Header not found header=x-forwarded-uri log_stream=app

Device (please complete the following information):

• OS: Kubernetes (Talos Linux)
• Browser: Any
• Tinyauth: v5.0.3
• Docker: containerd

Additional context
The only workaround right now is to either downgrade to v5.0.2 or deploy a dedicated header-translation reverse proxy next to Tinyauth. Modifying the global ingress controller to allow-snippet-annotations: "true" is a severe security risk in multi-tenant clusters, so a native fix in Tinyauth's NGINX endpoint logic is needed.

[e1024x]

Can confirm this is a side effect of the security patches. nginx sends X-Original-URI during auth_request subrequests, not X-Forwarded-Uri, so the new strict header check rejects every request coming through ingress-nginx.

The /api/auth/nginx endpoint should fall back to X-Original-URI when X-Forwarded-Uri isn't present. Authelia and Authentik both handle it this way for the same reason.

Worth noting this probably also affects anyone using envoy's ext_authz or HAProxy, neither of those set X-Forwarded-Uri by default either. Basically anything that isn't Traefik or Caddy is going to hit the same 400.

[steveiliop56]

Thank you guys. Fixed in v5.0.4.

[Dual-0]

@steveiliop56 Thanks for the fast fix in v5.0.4! The X-Original-URI fallback works.

However, in my point of view it looks like we've hit a new issue with the strict header checks. The /api/auth/nginx endpoint passes the URI check now, but immediately fails and returns a 400 Bad Request because it is now strictly requiring X-Forwarded-Host.

Logs (v5.0.4):

2026-03-13T00:15:58.293862405Z ERR internal/controller/proxy_controller.go:346 > Header not found header=x-forwarded-host log_stream=app
2026-03-13T00:15:58.316521306Z WRN internal/middleware/zerolog_middleware.go:62 > Client Error address=10.0.131.180:42836 client_ip=91.99.90.84 latency=27.932611ms log_stream=http method=GET path=/api/auth/nginx status=400

Just like with the URI, standard Kubernetes ingress-nginx doesn't send X-Forwarded-Host, X-Forwarded-Method, or X-Forwarded-Proto during an internal auth_request subrequest by default. It just sends the standard Host header. And because snippet annotations are disabled globally for security, we cannot manually inject them.

To fully fix the /api/auth/nginx endpoint without having to patch these headers one by one, it likely needs to:

1. Fall back to the standard Host header if X-Forwarded-Host is missing.
2. Ensure that it isn't strictly requiring other Traefik-specific headers (like X-Forwarded-Method or X-Forwarded-Proto) which will also be missing from standard NGINX subrequests.

@e1024x what do you think?

[steveiliop56]

@Dual-0 just for testing, can you replace Tinyauth with Whoami? I mean replace the redirect and forward the headers just to see what is it getting.

I thought x-forwarded-* headers where a standard just like x-forwarded-for is. There is a reason Traefik decided to use x-forwarded-host and not host because if Tinyauth is running over HTTPS and the connection is not internal (e.g. runs on another LXC or another proxy), Nginx in kubernetes would simply not work.

Also, seems like snippet annotations can be enabled and configured. Authentik for example recommends so. We cannot rely on headers like host for authentication. We need the x-forwarded-* ones.

[Dual-0]

@steveiliop56 Here is the output from a echo server. This is the raw HTTP request that standard Kubernetes ingress-nginx sends to the auth-url endpoint:

GET /api/auth/nginx HTTP/1.1
X-Request-ID: f0e69fbcecdf05bc71d480637434878f
Host: echo-test.tinyauth.svc.cluster.local
X-Original-URL: https://example.domain.tld/_static/out/browser/serviceWorker.js
X-Original-Method: GET
X-Sent-From: nginx-ingress-controller
X-Real-IP: x.x.x.x
X-Forwarded-For: x.x.x.x
X-Auth-Request-Redirect: /_static/out/browser/serviceWorker.js
Connection: close
# ... (standard browser headers follow)

As I know the /api/auth/nginx endpoint isn't receiving the proxied request. It is receiving an internal nginx subrequest generated by the auth_request module. Within this nginx builds a new HTTP request for this and it does not append the X-Forwarded-Host or X-Forwarded-Proto headers to it.

Because snippets are globally disabled in secure clusters (due to CVE-2021-25742), users cannot force nginx to inject those missing headers. In my point of view a possible solution could be to use the specific /api/auth/nginx endpoint (standard practice which Authelia and Authentik use?) and extract all the necessary context from the headers nginx provide.

I think if the nginx endpoint logic relies on X-Original-URL instead of X-Forwarded-Host/X-Forwarded-Proto it maybe work out of the box for ingress-nginx users.

[steveiliop56]

We will just extract everything we need from the X-Original-URL, simple.

[steveiliop56]

@Dual-0 @e1024x can you please test with v5.0.5-beta.1?

I rebuilt the proxy authentication handler from scratch to support every authentication method like forward_auth (what Traefik and Caddy use), auth_request (the one the ingress should use) and ext_authz (what Envoy uses). Now, instead of doing overrides and fallbacks in the code, we create a context with everything needed right from the beginning and the rest of the logic can use one generalized struct for accessing any proxy information.

You don't need to change anything in your configuration. I will reopen this until we have confirmation that everything is working correctly.

[Dual-0]

@steveiliop56 I just updated from v5.0.2-distroless to v5.0.5-beta.1-distroless and I can confirm it is working perfectly out of the box! No workarounds, snippets or custom proxy headers needed on the Kubernetes side.

Thank you so much for the quick help and all the effort you put into this! ❤️

[steveiliop56]

Perfect! Closing this and will release a patch by Friday.