Traefik 3.7.16: ForwardAuth finally speaks NTLM and Kerberos, plus one CVE

Traefik 3.7.16 shipped on October 20, alongside 2.11.60. The release contains three kinds of thing: one CVE, three bug fixes, one documentation note. One of those fixes deserves a post: ForwardAuth now supports NTLM and Kerberos.

The CVE first

CVE fixed: Advisory GHSA-hrpp-p4fc-wwf8

The release notes do not elaborate (the details live in the advisory), and the action is the usual one: upgrade to 3.7.16 or 2.11.60. For a reverse proxy, withholding detail is normal — its attack surface is configuration, and describing it precisely is drawing a map for attackers.

ForwardAuth and the old corporate-network problem

The interesting item:

[authentication, service, k8s/ingress-nginx] Support NTLM and Kerberos in ForwardAuth and ingress-nginx auth-url (#14091)

ForwardAuth is blunt by design: forward every request to an auth service and see what comes back. 2xx means pass, 401/403 means reject, and response headers carry identity back upstream.

http:
  middlewares:
    sso:
      forwardAuth:
        address: "http://auth.internal/verify"
        authResponseHeaders:
          - X-Auth-User
          - X-Auth-Groups

The problem is corporate networks: plenty of auth backends speak NTLM or Kerberos, and neither is a single question-and-answer. They need a persistent connection and multiple rounds:

Protocol	Needs	How it failed before
Basic	one request with Authorization	fine
NTLM	connection-level state, multiple 401 → retry with token rounds	every forward opened a new connection, the handshake never completed
Kerberos	Negotiate plus an SPN, usually keep-alive	same, plus the SPN has to match the connected hostname

So “ForwardAuth supports NTLM/Kerberos” is not a flag; it means keeping connection and handshake state in the forwarding layer. That is also why the same change touches ingress-nginx’s auth-url — that path mirrored nginx’s auth_request semantics, and nginx does not keep state either.

Why this matters beyond Windows domains

It looks like a Windows-only need, but:

• plenty of internal Nexus, Artifactory and GitLab deployments authenticate against LDAP or AD;
• any backend behind IIS or Windows integrated auth speaks NTLM;
• in Kubernetes the gateway (Traefik) and the auth backend usually sit in different namespaces with a Service in between — connection reuse is the first thing sacrificed.

The general shape is worth remembering: a proxy layer forwards statelessly by default, while some auth protocols are inherently stateful. The conflict never raises an error; it just shows up as “the browser prompts for credentials and rejects them anyway”.

Two more items

• k8s/gatewayapi: fixes the Gateway API conformance suite setup under the containerd image store (#14089). Only affects people running conformance tests, but those tests are the precondition for claiming conformance.
• Docs: clarifies that rewrite is supported inside ingress-nginx’s configuration-snippet (#14070) — knowledge that worked but was never written down.

My take

If your auth backend is AD or IIS, this release solves something you could previously only work around (usually by adding an nginx hop, or moving auth into the app). It is worth scheduling a verification pass.

If you do not use NTLM or Kerberos, only the CVE applies — but upgrade anyway. Reverse proxy patch releases are never “wait and batch it”.