Traefik: a ForwardAuth advisory exposed my unsupported version

On October 21, Traefik published a security advisory about its ForwardAuth middleware. It is rated "high", with a score of 7.0 out of 10. I went through all my Traefik configurations to see if I was exposed. I am not. But while checking, I found a wider problem: my version has not received a single fix since May 2025.

TL;DR: the GHSA-hrpp-p4fc-wwf8 flaw only hits Traefik setups where ForwardAuth talks to an NTLM or Negotiate authentication server. It is fixed in versions 2.11.60 and 3.7.16. Before you react to the score, read the advisory's conditions and compare them with your config. Then check the support status of your version. My setup does not use ForwardAuth. But my 3.3.7 is end of life. 44 advisories from 2026 list it without ever fixing it, and two describe a flaw already present in my binary.

Versions and source status: snapshot as of October 31, 2026. Check the latest fixes before deploying.

This article is for teams that run Traefik in Docker or Kubernetes. You do not need to know NTLM to follow it.

What the October 21 advisory says

Traefik is a reverse proxy: it receives requests and forwards them to your services. ForwardAuth asks an external server whether a request is authorized. It can copy the returned identity into headers sent to the service.

The flaw involves connection-bound authentication, such as NTLM or some Negotiate/Kerberos deployments. IIS Windows Authentication is one example.

ForwardAuth shared connections to the authentication server across clients. A connection authenticated by a victim could serve another client. That client could then be accepted under the victim’s identity.

The fixes shipped in Traefik 2.11.60 and 3.7.16 on October 20. The advisory followed the next day. In 3.7, the same issue affects the Ingress NGINX provider’s auth-url annotation. Versions 3.0 through 3.6 are affected and will receive no fix.

Read the conditions before the score

A score tells you how bad a flaw is if you are exposed. It does not tell you whether you are. To find out, read the advisory's conditions and compare them with your config.

For this flaw, three conditions must all be true at once:

Read the conditions before the score, then check your version's support. Without ForwardAuth, the flaw does not reach you. A frozen version, though, will get no fix.

The score itself hints at it. Its CVSS vector contains AT:P. That code means the attack depends on conditions present in your deployment. The vector is the string of codes that breaks the score down, criterion by criterion.

Read the version range carefully too. It is the widest list of affected versions, not proof. One case surprised me during this lab.

In March, Traefik published an advisory about a crash caused by HTTP/2 frames (CVE-2026-27141). It covers every version up to 3.6.9. But the bug comes from the Go library golang.org/x/net, and only from its version 0.50.0. I read my binary's dependencies with go version -m. It ships version 0.38.0, so that bug does not affect it.

Check your exposure with four commands

Start with the version that really runs. The tag written in your file is not enough.

# Docker
docker exec <traefik-container> traefik version

# Kubernetes
kubectl get pods -A -o jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' | grep traefik

Then search your config for ForwardAuth. The same search covers Docker labels, YAML files and Kubernetes manifests:

grep -rniE 'forwardauth|auth-url' .

Read every match before you conclude. In my case, the only auth-url line is read by ingress-nginx, not by Traefik.

If the Traefik API is enabled, ask it for the config it really loaded:

curl -s http://127.0.0.1:8080/api/http/middlewares \
  | jq -r '.[] | select(.type == "forwardauth") | .name'

For each ForwardAuth you find, look at how its server asks for authentication:

curl -sI https://your-auth-server/ | grep -i '^www-authenticate'

If that server advertises NTLM or Negotiate, also check your version. With ForwardAuth and an affected version, all three conditions are met. Upgrade now.

Do not rely on your scanner alone. On October 31, the advisory still had no CVE number. The GitHub Advisory Database, the one Dependabot reads, did not list it yet. The critical digestAuth advisory from August was missing too. The project's own advisory page remains the reference.

My lab: no ForwardAuth

The container on my machine runs Traefik 3.3.7, built with Go 1.23.8. Three Docker Compose files reference traefik:v3.3. They serve local tools or development environments.

My configurations use the file and Docker providers, with host-based or path-based routes. They use no middleware, so no ForwardAuth. Neither HTTP/3 nor mutual TLS authentication, known as mTLS, is enabled.

I found an auth-url annotation in Kubernetes. It is read by ingress-nginx, not Traefik. Its oauth2-proxy server uses neither NTLM nor Negotiate. That line therefore proves no exposure to the Traefik advisory.

The local containers listen on 127.0.0.1. This local scope also limits network exposure. Their unsupported version remains a problem.

My version, on the other hand, gets nothing

The traefik:v3.3 tag still points to 3.3.7. It has not changed since May 5, 2025. Another docker pull therefore brings no fix.

Of 62 Traefik advisories published since January 2026, 44 include my version in their affected range. None provides a fix for 3.3. An affected version range alone does not prove exposure, though.

The binary’s Go 1.23.8 compiler is also unsupported. The mechanism matches my eMudhra patch test. It needs a new binary, not another pull of the same image.

The 2026 advisories against my config

I took the most severe advisories, plus those whose conditions look like my config. Version 3.3 will get none of these fixes.

The other 35 advisories need a component I do not use. That means an authentication or rewrite middleware, a Kubernetes provider, HTTP/3, mTLS or an NTLM service. Others target TCP routers or FastProxy mode, an experimental proxy you turn on separately. Only one remains unclear to me. It comes from the gRPC-Go library, and I could not prove whether Traefik exposes it.

Two flaws, on the other hand, are already in my binary

Two advisories from 2026 are not about a component I do not use. They describe a flaw present in 3.3.7 itself. I checked them on a copy of my binary, run away from my real container, which did not change. I explain here what they break and what that changes for a service behind the proxy. I do not give the exact request: the goal is to understand the risk, not to arm an attack.

Identity headers that disappear (CVE-2026-29054)

Traefik adds X-Forwarded headers to every request. They tell the service who the real client is, and which protocol it came in on. A service reads X-Real-Ip for its logs, for example, or X-Forwarded-Proto to know whether the call came in over HTTP or HTTPS.

Traefik protects those headers against client-requested removal. But before 3.6.9, that protection compares the names case-sensitively, while the deletion itself ignores case. So a client can ask to remove a header by spelling it in lowercase. The protection does not recognize it, and the header leaves anyway. With the name spelled normally, nothing disappears. So the flaw is really there in 3.3.7.

The effect depends on what the service behind reads. On my side, my Go services look at X-Forwarded-For first, and it stays in place: the impact is limited. But my Keycloak reads X-Forwarded-Proto. An identity header a client can empty is no longer a source of trust, neither for an authorization nor for a routing decision.

A path rule that no longer protects (CVE-2026-88009)

Traefik decides routing and applies its middlewares by reading the request path. A rule can say, for example, "deny /admin to any address outside this list".

Before 3.7.13, a malformed request can present its target in a misleading form. Traefik reads it as an empty path, so "/", but forwards the real target to the service. It then makes its decision on "/", not on /admin. The rule does not apply. Worse, the access log records "/", so nothing looks wrong. The service, meanwhile, does receive /admin and answers.

In my configs, Traefik protects no path, so there is nothing to bypass today. But the day I add a path-based rule on this version, the flaw is already waiting for it. And the log would not show it happening.

How to fix it

The target is 3.7.16 at least, or 2.11.60 if you are still on v2. Since October 30, the latest release is 3.7.17. It is built with Go 1.27.

If you come from a version between 3.0 and 3.6, do not jump straight to production. Read the v3 migration guide section by section, from your version up to 3.7. For a Docker or file config like mine, I noted these changes:

• Since 3.6.16, the Docker provider needs Docker API 1.40 or later, which means Docker Engine 19.03.
• Since 3.7.13, a request target without a slash gets a 400 error. That is the fix for the test above.
• Since 3.7.15, every CONNECT request gets a 501 error.
• Since 3.7.17, a request carrying more than 500 header values gets a 431 error. The maxHeaderValueCount option sets that limit.

On Kubernetes, also plan the CRD and RBAC updates. CRDs describe Traefik's own resources, and RBAC sets its permissions. The guide asks for some on the moves to 3.4, 3.5, 3.6 and 3.7.

Then pin an exact version in your file, for example traefik:v3.7.17. Have a tool like Renovate watch that line, so it opens a pull request for each new release. Write down the old tag too, so you can roll back if a test breaks.

Finally, write down the end-of-support date of your new version. Traefik's current rule gives each minor version six months of support from its release. Version 3.7 shipped on May 5, 2026, and 3.8 has been a release candidate since October 30. The official table does not show an end date for 3.7 yet. Read it again when 3.8 ships.

And do not trust the table alone. It says 2.11 security support ends on September 7, 2026. Yet Traefik still shipped 2.11.60 on October 20, then 2.11.61 on October 30. The advisories and release notes are what tell you what is really fixed.

The checklist

A flaw that does not affect you can still tell you that your version has been abandoned.

• [ ] Run traefik version in every Traefik container or pod
• [ ] Compare that version with Traefik's official support table
• [ ] Search your whole config for forwardauth and auth-url
• [ ] Check the WWW-Authenticate header of every authentication server
• [ ] Read each advisory's conditions before its score
• [ ] Check a version range against the dependency at fault, with go version -m
• [ ] Move to 3.7.16 or later, or to 2.11.60 or later
• [ ] Read the migration guide for every minor version you skip
• [ ] Pin an exact version and have Renovate or a similar tool watch it
• [ ] Put the next end-of-support date in your calendar

The takeaway

A security advisory asks two questions. The first is simple: does my config meet its conditions? The second often matters more: will my version get the fix?

For the ForwardAuth flaw, my answer is no to both. The flaw does not affect me. But if a flaw affects me tomorrow, my 3.3 will not get fixed either. PostgreSQL 14 reaches the same point on November 12, and I tested what happens to its old dumps.

Want a review of your proxies, your images and their end-of-support dates? See my DevSecOps hardening offer, or let's talk.

Sources: Traefik advisory GHSA-hrpp-p4fc-wwf8 · Traefik forum announcement, 2.11.60 and 3.7.16 · 3.7.16 release notes · 2.11.60 release notes · Traefik security advisories · Traefik support policy · Traefik v3 migration guide · ForwardAuth documentation · Go vulnerability database, GO-2026-4559 · Docker Hub, traefik image · CVSS 4.0 specification