IETF HTTP/2: Denial of Service (CVE-2023-44487)

Was ist betroffen, was ist zu tun

Das HTTP/2-Protokoll ermöglicht eine Denial-of-Service-Angriff (Verbrauch von Serverressourcen), da die Anfrageabbrüche viele Streams schnell zurücksetzen können, wie im Zeitraum August bis Oktober 2023 ausgenutzt wurde.

Die Schwachstelle wird aktiv ausgenutzt; behandeln Sie sie vorrangig. Die vorliegenden Quellen nennen keine Fix-Version. Prüfen Sie die Herstellerhinweise in den Referenzen unten. Sofortmaßnahmen, Mitigation und Erkennungsregeln stehen im Runbook unten.

Widersprüchliche Versionsdaten – die Versionsanzeige ist ausgeblendet, bis die Daten bereinigt sind.

Unklar, ob und wie Sie betroffen sind? Frage zu dieser Schwachstelle stellen

Metriken

Behebung und Mitigation

1. 01

   Schritt 1 im Runbook

   Sofort-Response (0-24 h)

   • Inventarisierung aller aus dem Internet erreichbaren Endpunkte mit aktiviertem HTTP/2 (Reverse-Proxies, Load-Balancer, API-Gateways, Applikationsserver): curl -sI --http2 https://<host> bzw. nmap --script ssl-enum-ciphers -p 443 (ALPN h2 prüfen). Ohne diese Liste lässt sich nicht priorisieren.
   • Apache Tomcat aktualisieren: Die Versionen 9.0.0 bis 9.0.80 sowie 11.0.0 (Milestone-Builds) sind betroffen. Auf ein Release nach 9.0.80 bzw. den gefixten 11.0.x-Stand gemäß Apache-Security-Advisory aktualisieren.
   • Weitere gelistete Komponenten auf die gefixten Versionen anheben: Akka HTTP Server 10.5.3, Amazon OpenSearch Data Prepper 2.5.0, Apache APISIX 3.6.1, Apache Solr 9.4.0.
   • Für alle übrigen HTTP/2-Stacks (Webserver, Proxies, CDN, Ingress-Controller, Laufzeitbibliotheken) gilt: Patch verfügbar beim Hersteller — Version bitte im Vendor-Advisory nachschlagen. Dabei Edge-Komponenten vor internen Backends patchen.
   • Wo kurzfristig nicht gepatcht werden kann: HTTP/2 am Edge temporär deaktivieren und auf HTTP/1.1 zurückfallen (z. B. Tomcat: <UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol"/> aus dem Connector entfernen). Den Performance-Verlust bewusst in Kauf nehmen.
   • DDoS-Schutzdienstleister bzw. CDN kontaktieren und bestätigen lassen, dass der Rapid-Reset-Schutz auf ihrer Seite aktiv ist. Den Notfallkontakt im Incident-Runbook hinterlegen.
2. 02

   Schritt 2 im Runbook

   Mitigation-Layer

   • Netzwerk/Edge: HTTP/2-Terminierung ausschließlich an einer gehärteten, gepatchten Schicht (CDN, WAF, gepatchter Reverse-Proxy) durchführen. Backends sprechen intern HTTP/1.1, sodass ungepatchte Applikationsserver nicht direkt erreichbar sind.
   • Protokoll-Konfiguration: Die maximale Anzahl gleichzeitiger Streams pro Verbindung begrenzen (Tomcat Http2Protocol Attribut maxConcurrentStreams, analoge Direktiven in Proxies). Verbindungen mit übermäßig vielen Stream-Abbrüchen (RST_STREAM) per GOAWAY schließen, sofern die Implementierung dies unterstützt.
   • Rate-Limiting: Ratenbegrenzung pro Quell-IP sowohl für neue TCP/TLS-Verbindungen als auch für Requests pro Sekunde setzen, zusätzlich die Lebensdauer und die Anzahl der Requests pro Verbindung limitieren.
   • IPS (TLS-terminiert): Ein Suricata-Threshold auf RST_STREAM-Frames, z. B. alert http2 any any -> $HOME_NET any (msg:"CVE-2023-44487 HTTP/2 Rapid Reset"; http2.frametype:RST_STREAM; threshold:type both,track by_src,count 500,seconds 10; sid:9244871; rev:1;), ist nur dort wirksam, wo TLS entschlüsselt wird.
   • Kapazität/Resilienz: Autoscaling-Grenzen und Kostenalarme prüfen, da ein Angriff sonst zu unkontrollierter Ressourcen- und Kostenexplosion führen kann. Upstream-Scrubbing beim Provider vertraglich absichern.
3. 03

   Schritt 3 im Runbook

   Detection-Regeln

   • Proxy-/Webserver-Logs: Ein sprunghafter Anstieg abgebrochener Requests deutet auf Rapid Reset hin (nginx Status 499, Envoy Response-Flag DC, Tomcat-Access-Log mit 0 Bytes und sehr kurzer Dauer). SPL: index=web status=499 | bin _time span=1m | stats count by _time, clientip | where count>1000
   • Load-Balancer-/CDN-Telemetrie: Ein stark ansteigendes Verhältnis von Requests zu Verbindungen bei wenigen Quell-IPs ist auffällig, ebenso Kennzahlen zu „client reset“ oder „stream reset“ im Provider-Dashboard bzw. Cloud-LB-Logs.
   • Suricata/Zeek: Hohe Raten an http2.frametype:RST_STREAM pro Quelle, Suricata app-layer HTTP/2-Anomalie-Events sowie Zeek conn.log mit langlebigen 443-Verbindungen und extrem hohem orig_pkts bei kleiner Antwortgröße.
   • Host-Metriken: CPU-Sättigung oder Thread-Pool-Erschöpfung im Applikationsserver ohne korrespondierenden Anstieg erfolgreicher Requests (2xx). Dazu einen Alert auf die Korrelation „CPU > 90 % und 2xx-Rate fällt“ anlegen.
   • Sigma-Form: logsource: category: webserver / detection: selection: sc-status: 499 / condition: selection | count() by c-ip > 1000 in einem Zeitfenster von 1 Minute.

Erkennungsregeln

Für diese Schwachstelle liegt noch keine NEOSEC-Erkennungsregel vor.

Einordnung nach NIS2 und CRA

Regelbasierte Einordnung aus Ausnutzungsstatus und Schweregrad. Sie ersetzt keine Prüfung im Einzelfall.

NIS2

NIS2 ist die EU-Richtlinie (EU) 2022/2555 zur Erhöhung des Cybersicherheitsniveaus in der Union. Sie weitet Pflichten gegenüber der ersten NIS-Richtlinie deutlich aus: mehr Sektoren, verbindliches Risikomanagement, gestufte Meldepflichten und persönliche Verantwortung der Geschäftsleitung.

Im Glossar lesen

Aktiv ausgenutzt: Behandeln Sie die Schwachstelle im Schwachstellenmanagement nach Art. 21 Abs. 2 lit. e NIS2 vorrangig. Wird sie in Ihrer Umgebung ausgenutzt, prüfen Sie die Meldepflicht nach Art. 23 (Frühwarnung binnen 24 Stunden).

CRA

Der CRA ist die EU-Verordnung (EU) 2024/2847 mit horizontalen Cybersicherheitsanforderungen an „Produkte mit digitalen Elementen“ — von Industriesteuerungen über Software bis zu vernetzten Verbrauchergeräten. Erstmals müssen Hersteller Sicherheit über den gesamten Produktlebenszyklus gewährleisten, Schwachstellen behandeln und Sicherheitsupdates bereitstellen.

Im Glossar lesen

Seit dem 11.09.2026 müssen Hersteller betroffener Produkte mit digitalen Elementen aktiv ausgenutzte Schwachstellen nach Art. 14 CRA melden, mit Frühwarnung binnen 24 Stunden über die zentrale Meldeplattform der ENISA.

ISO/IEC 27001

ISO/IEC 27001 ist der international führende Standard für ein Informationssicherheits-Managementsystem (ISMS). Er beschreibt einen risikobasierten, prozessorientierten Rahmen, um Informationssicherheit systematisch zu planen, umzusetzen, zu überprüfen und zu verbessern.

Im Glossar lesen

Maßnahme A.8.8, Management technischer Schwachstellen: Relevanz für Ihre Systeme bewerten, Behebung einplanen und nachweisen.

Beschreibung

Das HTTP/2-Protokoll ermöglicht eine Denial-of-Service-Angriff (Verbrauch von Serverressourcen), da die Anfrageabbrüche viele Streams schnell zurücksetzen können, wie im Zeitraum August bis Oktober 2023 ausgenutzt wurde.

Quelle: BSI WID Portal, BSI CSAF, redhat_csaf, Debian Security Advisories, pwn.watch, OSV (Open Source Vulnerabilities), schneider_csaf, suse_csaf, siemens_advisory, CISA KEV Catalog, NVD (NIST), CVE.org (MITRE), CSA/SingCERT, cvelistv5

Hersteller und Produkte

• Akka HTTP Server
• Amazon Opensearch Data Prepper
• Apache Software Foundation Apache APISIX
• Apache Software Foundation Apache Solr
• Apache Software Foundation Apache Tomcat
• Apache Software Foundation Apache Traffic Server
• Apple Swiftnio Http\/2
• Caddyserver Caddyserver Caddy
• Cisco Business Process Automation
• Cisco Cisco Connected Mobile Experiences 10.2(1.0)
• Cisco Cisco Data Center Network Manager
• Cisco Cisco Enterprise Chat and Email

Weakness-Klassen (CWE)

• CWE-400Uncontrolled Resource Consumption

  Class

  The product does not properly control the allocation and maintenance of a limited resource.

  Eintrag bei MITRE CWE-400

Quellen & Referenzen

• github.comapple/swift-nio-http2/security/advisories/GHSA-qppj-fm5r-hxr3web
• github.comh2o/h2o/security/advisories/GHSA-2m7v-gc89-fjqfweb
• NVD (NIST)NVD: CVE-2023-44487advisory, pwn-watch
• github.comalibaba/tengine/issues/1872web
• github.comapache/apisix/issues/10320web
• github.comakka/akka-http/issues/4323web
• github.comvarnishcache/varnish-cache/issues/3996web
• github.comtempesta-tech/tempesta/issues/1986web
• github.comAzure/AKS/issues/3947web
• github.comopensearch-project/data-prepper/issues/3474web
• github.comcaddyserver/caddy/issues/5877web
• github.comopenresty/openresty/issues/930web
• github.comdotnet/announcements/issues/277web
• github.comeclipse/jetty.project/issues/10679web
• github.cometcd-io/etcd/issues/16740web
• github.comgolang/go/issues/63417web
• github.comninenines/cowboy/issues/1615web
• github.comhaproxy/haproxy/issues/2312web
• github.comhyperium/hyper/issues/3337web
• github.comkazu-yamamoto/http2/issues/93web

Änderungen an der CVE

Wer diese CVE wann geändert hat: die NVD (Analyse, betroffene Produkte, CVSS), der Herausgeber der CVE (CNA) und ergänzende Stellen wie CISA (ADP).

1. 11.08.2026Produktkennungen umgestelltNVD

   Produktzuordnung geändert:

   • Cisco Firepower Threat Defense Software (nach 7.4.2)
   Einzeländerung im Original anzeigen

   Einzeländerungen dieses Ereignisses im Original der NVD

   Art	Aktion	Vorher	Nachher
   Produktkonfiguration	geändert	OR *cpe:2.3:a:cisco:firepower_threat_defense:*:*:*:*:*:*:*:* versions from (excluding) 7.4.2	OR *cpe:2.3:a:cisco:secure_firewall_threat_defense:*:*:*:*:*:*:*:* versions from (excluding) 7.4.2

   Kennung der Quelle: nvd@nist.gov