CVE-2026-71554 - h2 Duplicate Host Header Request Smuggling Primitive

Dies ist meine erste CVE, und ich habe dieses PoC veröffentlicht, um den Fund zu dokumentieren und anderen zu helfen, ihn zu verstehen und nachzuvollziehen.

CVE: CVE-2026-71554 GHSA: GHSA-6hr6-w5qg-qmwg Betroffen: h2 <= 4.4.0 Behoben: h2 4.4.1 Schweregrad: Mittel (CWE-444, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L = 5.3) NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-71554

Was ich gefunden habe

Bei der Überprüfung der Header-Validierungslogik von h2 ist mir aufgefallen, dass _validate_host_authority_header() in src/h2/utilities.py prüft, ob Host und :authority übereinstimmen – aber nur den letzten Host-Header vergleicht, den es sieht. Wenn man zwei Host-Header sendet, verwendet h2 den zweiten für die Übereinstimmungsprüfung und leitet beide ohne Beanstandung an die Anwendung weiter.

Interessanterweise lehnt h2 4.4.0 bereits doppelte Content-Length-Header mit einem ProtocolError ab. Dieselbe Korrektur wurde nie auf Host angewendet. Es gab sogar einen TODO-Kommentar im Quellcode, der genau diese Lücke einräumte:

# TODO: We should also guard against receiving duplicate Host headers,
#       and against sending duplicate headers.

Ursache

_validate_host_authority_header() in src/h2/utilities.py verwendet eine Last-Wins-Schleife, die den zuletzt gesehenen Host-Wert speichert und nur Folgendes prüft:

Mindestens eines von :authority oder Host ist vorhanden
Wenn beide vorhanden sind, stimmen sie überein

Es gibt keine Prüfung der Anzahl der Host-Header. Jeder Host-Header wird unabhängig davon, wie viele vorhanden sind, an die Anwendung weitergegeben.

Angriffsszenarien

Fall 1 – Zwei Host-Header, kein :authority

Der Client sendet:

:method: GET
:path: /
:scheme: https
host: good.internal
host: evil.attacker

h2 akzeptiert beide. Die Anwendung erhält beide Host-Header.

Ein HTTP/1.1-Downgrade erzeugt:

GET / HTTP/1.1
host: good.internal
host: evil.attacker

RFC 9112 Abschnitt 3.2 verlangt, dass ein Server mit 400 auf jede HTTP/1.1-Anfrage antwortet, die mehr als einen Host-Header enthält. Backends weichen voneinander ab:

nginx          — lehnt mit 400 ab
Python stdlib  — akzeptiert, gibt beim Lookup den ERSTEN Host zurück
Werkzeug       — akzeptiert, gibt beim Lookup den ERSTEN Host zurück

Fall 2 – Stealth-Smuggling (:authority-Bypass)

Der Client sendet:

:method: GET
:path: /
:scheme: https
:authority: good.internal
host: evil.attacker     <- Index 0, erster Host (vom Origin gesehen)
host: good.internal     <- Index 1, letzter Host (vom h2-Validator verwendet)

h2 validiert: letzter Host (good.internal) == :authority (good.internal) – besteht.

Die Anwendung erhält beide Host-Header. Ein HTTP/1.1-Downgrade erzeugt:

GET / HTTP/1.1
host: evil.attacker
host: good.internal

Backends, die bei einem Single-Key-Lookup den ersten Host zurückgeben, leiten die Anfrage an evil.attacker weiter, während h2 glaubte, good.internal validiert zu haben. Vollständige Routing-Desynchronisation zwischen dem, was h2 validiert hat, und dem, was der Origin verarbeitet.

Kontrolle – Ein einzelner nicht übereinstimmender Host wird korrekt abgelehnt

:method: GET
:path: /
:scheme: https
:authority: good.internal
host: evil.attacker

h2 löst einen ProtocolError aus. Bestätigt, dass die Lücke spezifisch für doppelte Host-Header ist.

Was betroffen sein kann

Die Auswirkung hängt von der Deployment-Architektur ab:

Betroffen: Reverse-Proxys oder API-Gateways, die HTTP/2 von Clients akzeptieren und beim Weiterleiten an Backends auf HTTP/1.1 downgraden, wobei das Backend den ersten Host-Header für Routing-Entscheidungen verwendet
Betroffene Backends (empirisch getestet): Python stdlib http.client, Werkzeug Headers – beide akzeptieren doppelte Host-Header und geben den ersten Wert zurück
Nicht betroffene Backends: nginx – lehnt bei doppelten Host-Headern mit 400 ab
Nicht betroffene Deployments: End-to-End-HTTP/2 ohne HTTP/1.1-Downgrade

Schritte zur Reproduktion

Voraussetzungen

pip install h2==4.4.0

Ausführen

python3 poc_h2_duplicate_host.py

Erwartete Ausgabe bei verwundbarem 4.4.0

CASE 1 - Zwei Host-Header, kein :authority (beide weitergeleitet)
h2 weitergeleitete Host-Header: ['good.internal', 'evil.attacker']
Resultierende HTTP/1.1-Anfrage:
GET / HTTP/1.1
host: good.internal
host: evil.attacker

CASE 2 - STEALTH: :authority stimmt mit dem LETZTEN Host überein, erster Host geschmuggelt
:authority=['good.internal']  Host(s)=['evil.attacker', 'good.internal']
h2-Mismatch-Prüfung BESTEHT (:authority == letzter Host).
Resultierende HTTP/1.1-Anfrage:
GET / HTTP/1.1
host: evil.attacker
host: good.internal

CONTROL - Einzelner nicht übereinstimmender Host vs. :authority (korrekt abgelehnt)
[control] SENDER rejected: ProtocolError(...)

Überprüfen des Fixes auf 4.4.1

pip install h2==4.4.1
python3 poc_h2_duplicate_host.py

Alle drei Fälle lösen einen ProtocolError aus. Es werden keine Header weitergeleitet.

Der Fix

Ein Zähler, der der bestehenden Schleife in _validate_host_authority_header() hinzugefügt wurde:

host_header_count = 0
for header in headers:
    if header[0] == b"host":
        host_header_count += 1
    yield header

if host_header_count > 1:
    raise ProtocolError("Request header block has multiple Host headers.")

Commit: https://github.com/python-hyper/h2/commit/292a40829feefda98c8509dcdbbb4a57af9bd6a6

Danksagung

Entdeckt und gemeldet von Sunand Mohan (https://github.com/SunandM)

poc-h2-CVE-2026-71554

Beliebteste