Traefik CVE-2026-54763: bypass de auth por guion bajo

Si tenés Traefik delante de tus servicios y confiás en BasicAuth, DigestAuth o ForwardAuth para decidir quién entra, hay una familia de vulnerabilidades que conviene mirar hoy mismo. No es un bug exótico de laboratorio: es un carácter, el guion bajo, que rompe la suposición más básica de un reverse proxy — que los headers que el proxy escribe son los únicos que el backend va a leer.

CVE-2026-54763 es una vulnerabilidad de spoofing de identidad en los middlewares BasicAuth, DigestAuth y ForwardAuth de Traefik. Traefik borra los headers de identidad falsificados en su forma canónica con guiones (X-Auth-User), pero no toca las variantes con guion bajo (X_Auth_User), que muchos backends normalizan de manera idéntica. Afecta a Traefik hasta v2.11.50, v3.6.21 y v3.7.5, y está corregida en v2.11.51, v3.6.22 y v3.7.6.

¿Por qué Header.Del() de Go no borra X_Auth_User?

Traefik: el guion bajo que burla BasicAuth y ForwardAuth

Porque Header.Del() de Go canonicaliza mayúsculas/minúsculas ASCII y guiones, pero no trata el guion bajo como equivalente al guion. Cuando el middleware ejecuta Header.Del("X-Auth-User") para limpiar lo que mandó el cliente antes de escribir su propio valor, un header llamado X_Auth_User es, para Go, un header completamente distinto: sobrevive intacto y se reenvía al backend junto con el que Traefik acaba de escribir.

El intercambio queda así de simple:

Cliente  →  X_Auth_User: superadmin
Traefik  →  X-Auth-User: alice        (lo que autenticó de verdad)
Backend  →  recibe LOS DOS headers

Y ahí es donde el problema deja de ser de Traefik y pasa a ser de tu stack: si el backend colapsa ambas formas en la misma variable, gana el valor del atacante. La advisory GHSA-x677-9fxg-v5c5 del repositorio traefik/traefik, publicada el 1 de julio de 2026, lista los cuatro puntos exactos donde ocurre: pkg/middlewares/auth/basic_auth.go, digest_auth.go, forward.go y pkg/middlewares/ingressnginx/snippet/snippet.go — es decir, también el camino de snippets de Ingress-NGINX en Kubernetes.

¿Qué diferencia hay entre CVE-2026-54763 y CVE-2026-39858?

Atacan la misma clase de defecto en dos superficies distintas: CVE-2026-39858 falsifica el contexto de confianza (los headers X-Forwarded-*) antes de que se tome la decisión de autenticación, y CVE-2026-54763 falsifica la identidad ya autenticada (el headerField de BasicAuth/DigestAuth y los authResponseHeaders de ForwardAuth) después.

CVE-2026-39858 — spoofing de alias forwarded, pre-auth. Según el GitHub Advisory Database (GHSA-5m6w-wvh7-57vm, publicada el 24 de abril de 2026), la sanitización de forwarded headers de Traefik apunta solo a los nombres canónicos y no normaliza variantes como X_Forwarded_Proto o X_Forwarded_Host. El atacante inyecta un esquema o un host "de confianza" y el servicio de auth decide con datos que él controla. Corregida en 2.11.43, 3.6.14 y 3.7.0-rc.2.
CVE-2026-54763 — spoofing de identidad, post-auth (y a veces sin auth). Es el "fix incompleto" de CVE-2026-33433, que a su vez cubría el caso de un headerField configurado en forma no canónica. La advisory es explícita sobre el caso más grave: en el camino de authResponseHeaders de ForwardAuth "the attacker does NOT need credentials" — ese mecanismo confía en headers que solo deberían venir del servidor de autenticación, y la variante con guion bajo atraviesa esa frontera.
La cadena importa más que cada CVE por separado. Son tres advisories encadenadas sobre el mismo malentendido (33433 → 39858 → 54763). Si tu instalación quedó en una versión intermedia porque "ya parcheaste el bypass de Traefik en abril", estás cubierto contra la primera mitad y expuesto a la segunda.

¿Qué versiones de Traefik están afectadas y cuáles tienen el parche?

Para CVE-2026-54763 hay parche en v2.11.51, v3.6.22 y v3.7.6, publicadas el 30 de junio de 2026 según la página de releases del proyecto. Todo lo anterior (v2.11.50, v3.6.21, v3.7.5 y previas) está afectado.

Rama	Afectada hasta	Parche CVE-2026-54763	Parche CVE-2026-39858
v2.11	2.11.50	2.11.51	2.11.43
v3.6	3.6.21	3.6.22	3.6.14
v3.7	3.7.5	3.7.6	3.7.0-rc.2
v1.7	1.7.34	sin parche (EOL)	sin parche (EOL)

Sobre la severidad hay ruido y vale aclararlo, porque vas a ver números distintos según dónde mires: la advisory de traefik/traefik puntúa 7.5 para BasicAuth/DigestAuth y 9.1 para ForwardAuth — dos escenarios, dos scores —, mientras que los agregadores tipo NVD publican un único 7.8 y el boletín del CERT Santé francés del 7 de julio de 2026 lo reporta como 9.1 crítico. La divergencia no es un error: depende de qué middleware uses. Si tenés ForwardAuth expuesto, tratalo como el número alto.

¿Alcanza con actualizar Traefik para estar protegido?

No necesariamente, y este es el punto que más gente se va a comer. La mitigación que propone la propia advisory no es un cambio silencioso de comportamiento sino una opción nueva de entry point que hay que activar a mano, y su valor por defecto documentado es keep — o sea, seguir reenviando los headers con guion bajo tal cual.

Traducido a la práctica: hacés docker compose pull, saltás a v3.7.6+, ves el contenedor arriba y asumís que terminaste. Pero si no tocaste la configuración del entry point, los X_Auth_User del mundo siguen viajando a tu aplicación. Actualizar es el paso uno de dos, no el único.

¿Cómo configurar underscoreHeadersStrategy en tu entry point?

Se define por entry point, dentro de la sección http, y acepta tres valores. Según la documentación de migración de Traefik v3.7, la opción underscoreHeadersStrategy funciona así:

keep — valor por defecto. Los headers con guion bajo se reenvían tal cual. Es el comportamiento histórico y el que te deja expuesto.
delete — la opción recomendada para la mayoría. Elimina en silencio cualquier header de request cuyo nombre contenga un guion bajo, antes del ruteo. Rompe poco porque los headers legítimos con guion bajo son rarísimos en HTTP.
reject — el modo estricto. Devuelve 400 Bad Request a cualquier request que traiga un header con guion bajo. Preferible si querés que el rechazo quede visible en los logs en vez de silencioso.

En YAML estático:

entryPoints:
  websecure:
    address: ":443"
    http:
      underscoreHeadersStrategy: delete

Y el equivalente por CLI, que es el formato que vas a usar si configurás Traefik con labels o flags en Docker Compose:

--entrypoints.websecure.http.underscoreheadersstrategy=delete

Aplicalo en todos los entry points que reciban tráfico de internet, no solo en el de HTTPS. Un entry point :80 que solo redirige a HTTPS igual procesa la request original.

¿Qué backends normalizan guiones bajos como guiones?

Los que implementan o heredan la convención CGI de RFC 3875, que convierte X-Auth-User y X_Auth_User a la misma variable de entorno HTTP_X_AUTH_USER. La lista que menciona la advisory de Traefik cubre buena parte de lo que hay en producción:

PHP y cualquier cosa vía CGI/FastCGI. El superglobal $_SERVER expone ambas formas colapsadas en la misma clave.
Aplicaciones WSGI y ASGI en Python. Frameworks como los del ecosistema Django/Flask leen el environ ya normalizado, o hacen matching case-insensitive que ignora la diferencia.
Tomcat y contenedores de servlets Java EE. El acceso a headers por nombre en la API de servlets puede exponer las dos variantes al código de la aplicación.
nginx con underscores_in_headers on. Por defecto nginx descarta los headers con guion bajo — que es exactamente la razón por la que ese default existe. Si lo prendiste alguna vez para una integración puntual, revisalo.

Si tu backend es un binario Go que lee headers con la librería estándar, el riesgo es menor: Go no colapsa las dos formas. Pero "menor" no es "nulo", porque cualquier middleware, sidecar o capa intermedia entre Traefik y tu app puede reintroducir la normalización.

¿Cómo verificar si tu instalación está expuesta?

Primero mirá la versión con traefik version (o docker exec sobre el contenedor) y comparala con la tabla de arriba. Después, revisá si tenés configurado algún headerField en BasicAuth/DigestAuth o algún authResponseHeaders en ForwardAuth: si la respuesta es no, la superficie de CVE-2026-54763 es mucho menor, aunque la de CVE-2026-39858 sigue en pie.

Para probar el comportamiento en un entorno de staging, mandá el header en su forma con guion bajo contra una ruta protegida y observá qué llega al backend. Un endpoint de eco que imprima los headers recibidos alcanza:

curl -i -H "X_Auth_User: superadmin" https://staging.tu-dominio.com/ruta-protegida

Si el backend reporta superadmin en vez del usuario que Traefik autenticó, tenés el bypass reproducido. Con underscoreHeadersStrategy: delete el header no debería aparecer nunca; con reject, la request ni siquiera debería llegar. Hacelo en staging, no en producción, y documentá el resultado antes y después del cambio.

¿Qué se lleva un equipo de infraestructura de todo esto?

Que los headers que escribe el proxy son una frontera de confianza y hay que tratarlos como tal, no como un detalle de transporte. El análisis de hardening publicado el 1 de julio de 2026 en blog.lrvt.de lo resume mejor que cualquier changelog: "Treat proxy-managed identity and authorization headers as a trust boundary, and remove ambiguous header aliases before they reach the application" — tratá los headers de identidad y autorización gestionados por el proxy como una frontera de confianza, y eliminá los alias ambiguos antes de que lleguen a la aplicación.

Hay un patrón que se repite en las tres advisories encadenadas: el bug nunca estuvo en la lógica de autenticación, sino en la normalización de nombres. Cada capa del stack tiene su propia idea de qué significa "el mismo header", y el atacante trabaja justo en el hueco entre dos de esas ideas. Es la misma familia de razonamiento que vimos en el bypass de tamaño del plugin AuthZ de Docker: no romper la autorización, sino hacer que dos componentes lean cosas distintas del mismo request.

Tres acciones concretas para hoy:

Actualizá a v2.11.51, v3.6.22 o v3.7.6 como mínimo. Al 15 de julio de 2026 las ramas iban por v2.11.52, v3.6.23 y v3.7.8, así que verificá la versión vigente en el repositorio oficial antes de fijar un tag.
Poné underscoreHeadersStrategy: delete en todos los entry points. El default es keep: sin este paso, actualizar no te cubre.
Auditá qué headers usa tu backend para decidir identidad o permisos. Si tu aplicación confía en un X-Auth-User o un X-Forwarded-* para autorizar, ese header necesita venir de una fuente que puedas garantizar.

Si estás armando el reverse proxy desde cero, dos lecturas complementarias del blog: Traefik con Docker y Let's Encrypt en un Cloud Server, para el setup base, y Traefik vs Nginx Proxy Manager: qué reverse proxy elegir, para decidir la herramienta antes de heredar sus CVEs.