Kritische Sicherheitslücke in HTTP/2 entdeckt: „MadeYouReset“ ermöglicht neue DDoS-Angriffe

Eine Forschergruppe hat eine Schwachstelle im Internet-Protokoll HTTP/2 aufgedeckt, die es Angreifern erlaubt, Webserver gezielt zum Absturz zu bringen. Die Lücke, die den Namen „MadeYouReset“ trägt, wurde am 13. August 2025 öffentlich bekannt gegeben und mit der Kennung CVE-2025-8671 versehen. Sie erreicht einen Schweregrad von 7,5 von 10 Punkten.

Die Entdeckung geht auf den Informatik-Masterstudenten Gal Bar Nahum von der Universität Tel Aviv zurück. Nach seinen Untersuchungen eröffnet der Fehler eine neue Form von Denial-of-Service (DoS)-Angriffen, die sich von klassischen Methoden unterscheiden: Angreifer können durch präparierte Anfragen praktisch unbegrenzt viele parallele Prozesse auf einem Server erzwingen – selbst wenn die eingebauten Sicherheitsmechanismen des Protokolls eigentlich genau das verhindern sollen.

Technisch gesehen basiert „MadeYouReset“ auf einer bereits 2023 entdeckten Schwachstelle namens „Rapid Reset“, die damals zu einigen der größten DDoS-Angriffe in der Geschichte führte. Während Rapid Reset durch schnelle Stream-Resets funktionierte, geht die neue Angriffstechnik noch einen Schritt weiter: Durch gezielt fehlerhafte Frames oder Flusskontrollfehler kann ein Client den Server dazu bringen, eine unbegrenzte Zahl gleichzeitiger Streams über eine einzige Verbindung zu verarbeiten. Zwar markiert der Server diese Streams als geschlossen, die eigentliche Verarbeitung im Backend läuft jedoch weiter – bis die Ressourcen erschöpft sind und das System zusammenbricht.

Experten sehen in der Entdeckung eine ernstzunehmende Bedrohung für die Stabilität des modernen Internets. Denn HTTP/2 ist die Grundlage für einen Großteil heutiger Webkommunikation. Sicherheitsforscher warnen daher, dass die Lücke in den kommenden Wochen und Monaten verstärkt von Angreifern ausgenutzt werden könnte, sollten nicht rasch entsprechende Updates und Gegenmaßnahmen entwickelt werden.

Wie Angreifer die Asymmetrie des Webs ausnutzen – und warum „MadeYouReset“ gefährlich ist

In einem Blogbeitrag erklärt der Entdecker der Schwachstelle, Gal Bar Nahum, die Grundlagen von Denial-of-Service-Angriffen (DoS). Nicht jeder Angriff dieser Art beruht automatisch auf einer Sicherheitslücke, betont er. Entscheidend sei das Kostenverhältnis: Wenn ein Angreifer mit minimalem Aufwand einen Server lahmlegen kann, liegt eine echte Schwachstelle vor.

Das Prinzip ist einfach: DoS-Angriffe leben von einer Asymmetrie. Während es für Angreifer billig ist, massenhaft Anfragen zu verschicken, sind deren Verarbeitung und Beantwortung für den Server vergleichsweise teuer. Genau dieser Unterschied macht das Web schnell und effizient – eröffnet aber auch Möglichkeiten für Missbrauch.

Allein diese Asymmetrie macht HTTP jedoch nicht automatisch verwundbar. Kritisch wird es erst dann, wenn Angreifer ihre Angriffe parallel in großem Maßstab ausführen können. Aus diesem Grund enthält HTTP/2 Schutzmechanismen, die die Zahl der gleichzeitigen Aufgaben begrenzen, die ein einzelner Client an einen Server übermitteln darf.

Doch genau hier setzt die neue Lücke an: „MadeYouReset“ umgeht diese Begrenzung und ermöglicht es, Server mit unzähligen parallelen Prozessen zu überlasten.

Was macht HTTP/2 so anfällig?

Um zu verstehen, wie die Lücke funktioniert, lohnt ein Blick auf den Aufbau des Protokolls: HTTP/2 organisiert die Kommunikation über Frames – kleine Datenpakete, die entweder Nutzdaten (etwa Header oder Inhalte von Anfragen) oder Steuerinformationen enthalten. Diese Frames laufen über sogenannte Streams, virtuelle Kanäle, über die jeweils ein kompletter Request-Response-Zyklus abgewickelt wird.

Hinzu kommen spezielle Steuerframes wie SETTINGS, WINDOW_UPDATE, PRIORITY, RST_STREAM, GO_AWAY oder PING, die den Ablauf koordinieren und dafür sorgen, dass Verbindungen effizient bleiben.

Die Möglichkeit, mehrere Streams parallel zu öffnen, ist eine der wichtigsten Verbesserungen von HTTP/2 gegenüber dem Vorgänger HTTP/1.1. Sie sorgt für schnellere Ladezeiten und mehr Effizienz – macht das Protokoll aber gleichzeitig verwundbarer für ausgeklügelte Angriffe wie MadeYouReset.

Grafik Quelle: Gal Bar Nahum

Allerdings birgt die Parallelität auch ein Risiko: Da das Protokoll es Clients ermöglicht, sehr einfach viele gleichzeitige Anfragen zu öffnen (was an sich sehr vorteilhaft ist), könnte ein böswilliger Client den Server überlasten. Aus diesem Grund wurde in HTTP/2 auch ein Parameter namens MAX_CONCURRENT_STREAMSeingeführt, der die Anzahl der aktiven Streams begrenzt, die ein Client haben kann. Wenn ein Server überlastet ist, kann er diesen Parameter reduzieren, indem er den Client benachrichtigt. Der Standardwert für diesen Parameter ist in fast allen HTTP/2-Servern und -Implementierungen 100. Theoretisch ist dies ein guter Mechanismus, aber in der Praxis …

Der Vorgänger: Wie „Rapid Reset“ das Internet erschütterte

Bevor es zur neuen Schwachstelle „MadeYouReset“ kam, sorgte bereits ihr Vorläufer für Schlagzeilen: „Rapid Reset“, eine Zero-Day-Lücke im HTTP/2-Protokoll, die im Oktober 2023 entdeckt und sofort in freier Wildbahn ausgenutzt wurde. Sowohl Cloudflare als auch Google stuften die damit verbundenen Angriffe als die größten DDoS-Attacken der Geschichte ein. Betroffen waren nahezu alle HTTP/2-Server und Implementierungen – das Problem war damit von globalem Ausmaß.

Die Funktion hinter dem Angriff: Abbrechen von Anfragen

HTTP/2 brachte eine praktische neue Funktion mit: Clients können dem Server mitteilen, dass sie die Antwort auf eine bereits gestartete Anfrage nicht mehr benötigen. Ein klassisches Beispiel ist der Browser, der eine Anfrage abbricht, wenn ein Nutzer auf „Stopp“ klickt oder zu einer anderen Seite wechselt. Technisch wird dies über den RST_STREAM-Frame umgesetzt, mit dem ein Stream sofort als beendet markiert wird.

Für die Nutzererfahrung ist das ein Vorteil: unnötige Daten werden nicht mehr übertragen. Doch genau diese Logik machte sich „Rapid Reset“ zunutze.

Die Schwachstelle

Laut den Spezifikationen von HTTP/2 gilt: Sobald ein Stream mit RST_STREAM abgebrochen wird, wird er unmittelbar als geschlossen behandelt. Der entscheidende Punkt: Geschlossene Streams werden nicht auf das Limit MAX_CONCURRENT_STREAMS angerechnet – also die Obergrenze, wie viele gleichzeitige Anfragen ein Client stellen darf.

Genau hier setzte Rapid Reset an: Angreifer konnten massenhaft Anfragen stellen und sie sofort wieder abbrechen. Formal hielten sie sich damit an die Regeln des Protokolls – in der Praxis aber wurden Server so mit Arbeit überschwemmt, dass sie unter der Last zusammenbrachen.

 

Grafik Quelle: Gal Bar Nahum

Theoretisch sollte die Stornierung eines Streams den Server anweisen, die Bearbeitung der HTTP-Anfrage zu beenden und das Senden einer Antwort abzubrechen – selbst wenn diese bereits berechnet wurde –, um eine Verschwendung von Serverressourcen und Bandbreite zu vermeiden. In der Praxis jedoch wird bei vielen Servern und Implementierungen die Stornierung einer Anfrage erst dann abgebrochen, wenn die Antwort bereits berechnet wurde. Was passiert, ist, dass der Server nach dem Empfang einer Anforderungsstornierung in der HTTP/2-Komponente des Servers die Bearbeitung der HTTP-Anforderung fortsetzt, die Antwort berechnet und die Antwort an die HTTP/2-Komponente weiterleitet, die sie verwirft, da der Stream storniert wurde und nun geschlossen ist. Dieses Verhalten ist nicht auf Faulheit der Entwickler zurückzuführen – es gibt einen triftigen Grund dafür.

Daher führt die Stornierung einer Anfrage zu einer Diskrepanz zwischen der Anzahl der aktiven Anfragen aus Sicht von HTTP/2 und der Anzahl der tatsächlich aktiven Anfragen, die im Backend des Servers verarbeitet werden (und für die Antworten berechnet werden).

Der Rapid-Reset-Angriff

Wie der Name schon sagt, öffnet Rapid Reset einfach Streams und bricht sie sofort mit RST_STREAMab. Durch das Öffnen und schnelle Abbrechen eines Streams wird die HTTP-Anfrage verarbeitet und eine Antwort berechnet, aber sie wird nicht mehr auf MAX_CONCURRENT_STREAMSangerechnet.

Mit anderen Worten: Ein Angreifer kann Stream-Abbrüche nutzen, um Server dazu zu bringen, Antworten auf eine unbegrenzte Anzahl gleichzeitiger Anfragen zu verarbeiten und zu berechnen, während er die durch das HTTP/2-Protokoll auferlegte Begrenzung MAX_CONCURRENT_STREAMS vollständig umgeht.

Im Vergleich zu einem regulären HTTP/2-Request-Flood-Angriff, der durch MAX_CONCURRENT_STREAMS begrenzt ist, ist Rapid Reset weit überlegen – er ist nur durch seinen eigenen Durchsatz begrenzt.

 

Grafik Quelle: Gal Bar Nahum

Wie Rapid Reset abgeschwächt wurde

Die Abschwächung von Rapid Reset, die von fast allen betroffenen Implementierungen verwendet wurde, war sehr einfach: Die Anzahl der Streams, die ein Client abbrechen kann, wurde begrenzt. Mit anderen Worten: Die Anzahl der RST_STREAM-Frames, die ein Client senden kann, wurde begrenzt (beispielsweise ist eine Begrenzung auf 100 mehr als ausreichend).

Keine Stornierung von Anfragen -> kein RST_STREAM-> kein Rapid Reset.

„Dies funktionierte sehr gut und schränkte den Angriff vollständig ein, ohne legitime Benutzer zu beeinträchtigen“, so Gal Bar Nahum.

MadeYouReset: Wenn der Server selbst den Reset übernimmt

Der Name der neuen Schwachstelle ist Programm: Während bei „Rapid Reset“ der Client eine Anfrage abbricht, sorgt bei MadeYouReset der Server selbst für den Abbruch.

Auf den ersten Blick wirkt das paradox – schließlich ist es normalerweise der Client, der das Interesse an einer Antwort verliert. Doch Angreifer haben einen anderen Ansatz gefunden: Sie benötigen lediglich einen Weg, den Server dazu zu bringen, von sich aus ein RST_STREAM-Signal zu senden.

Warum gerade RST_STREAM?

In HTTP/2 dient RST_STREAM nicht nur zur Stornierung von Anfragen durch den Client, sondern auch dazu, Stream-Fehler zu signalisieren. Das eröffnet neue Möglichkeiten.

Fehler, die direkt vom Client verursacht werden, sind allerdings wenig nützlich. Ein Blick zurück auf HTTP/1.1 macht deutlich, warum: Dort sind 4xx-Fehler für clientseitige Probleme reserviert – etwa eine ungültige Anfrage (400) oder fehlende Berechtigung (403). Solche Anfragen werden sofort abgelehnt, ohne dass das Backend nennenswert arbeiten muss. Dasselbe gilt in HTTP/2: Eine fehlerhafte Anfrage kann zwar problemlos ein RST_STREAM auslösen, doch die Serverressourcen bleiben weitgehend unberührt.

Der Trick hinter MadeYouReset

Damit der Angriff funktioniert, muss der Stream zunächst mit einer gültigen Anfrage beginnen – also eine Anfrage, die der Server tatsächlich verarbeitet. Erst danach wird ein Stream-Fehler ausgelöst, der den Server zwingt, ein RST_STREAM zu senden.

Während der Stream auf Protokollebene als „geschlossen“ gilt, läuft die Bearbeitung im Backend weiter. Genau diese Lücke erlaubt es Angreifern, eine nahezu unbegrenzte Zahl paralleler Vorgänge auszulösen – und die Serverlast explodieren zu lassen

Grafik Quelle: Gal Bar Nahum

In HTTP/1.1 existieren ausschließlich Anfragen, jedoch keine Streams. Deshalb lässt sich dort ein Fehler nur über fehlerhafte Anfragen erzeugen. In HTTP/2 hingegen gibt es mehr Spielraum: Neben HTTP-Nachrichten existieren Kontroll-Frames, die den Verbindungsfluss steuern. Werden bestimmte ungültige Kontroll-Frames erzeugt oder die Protokollsequenz im richtigen Moment verletzt, kann der Server dazu gebracht werden, ein RST_STREAM für einen Stream zu senden, der bereits eine gültige Anfrage enthielt.

Gal Bar Nahum: „Bei meinen Recherchen habe ich sechs solcher „make the server send RST_STREAM“-Primitive identifiziert, die in der RFC definiert sind und somit in jeder RFC-konformen Implementierung auftreten. Auf diese gehe ich im Beitrag „Technische Details“ ein.“

Durch die Nutzung von MadeYouReset – einer dieser sechs Primitiven – muss ein Angreifer kein einziges RST_STREAM selbst senden. Damit lässt sich die gängige Rapid-Reset-Abwehrmaßnahme, nämlich das Zählen clientseitiger Abbrüche, vollständig umgehen – bei gleicher Wirkung wie Rapid Reset.

Grafik Quelle: Gal Bar Nahum

Auswirkungen von MadeYouReset

Die meisten betroffenen Server können durch diesen Angriff vollständig lahmgelegt werden, einige stürzen infolge einer Speicherüberlastung (Out of Memory, OOM) sogar ab.

Die konkreten Auswirkungen hängen von mehreren Faktoren ab:

• der Kapazität des Servers (CPU, Arbeitsspeicher, I/O, Worker-Pools),

• der Sendegeschwindigkeit des Angreifers (Bandbreite und Client-CPU),

• sowie der gewählten Zielressource (wie viel Rechenzeit für deren Verarbeitung erforderlich ist).

Ein sehr leistungsfähiger Server könnte einem schwachen Angreifer standhalten.

Gal Bar Nahum: „Nach meinen Tests sind jedoch aufgrund der Asymmetrie zwischen Anfrage und Antwortberechnung – verbunden mit der Möglichkeit, unbegrenzt viele parallele Anfragen zu erzeugen – die meisten Server anfällig für einen vollständigen Denial of Service. Eine erhebliche Zahl ist zudem gegenüber Speicherfehlern (OOM) verwundbar.“

Selbst wenn einzelne Anfragen keine komplexen Backend-Prozesse auslösen, entsteht durch die hohe Frequenz von Erstellen und Abbrechen von Streams ein erheblicher Overhead im HTTP/2-Frontend. Schon das Parsen von Frames, das Steuern der Statusmaschine, das Verwalten von HPACK sowie die anschließende Bereinigung verbrauchen beträchtliche CPU- und Speicherressourcen. Im großen Maßstab genügt dieser Aufwand allein, um die Serverleistung massiv zu verschlechtern oder einen DoS-Zustand herbeizuführen.

Weitere Einzelheiten zu den Auswirkungen und deren Messung finden sich im dritten Beitrag der Reihe: Auswirkungen.

Betroffene Projekte

Eine unvollständige Liste der betroffenen Implementierungen (wird erweitert):

Project	CVE	Links
general CVE	CVE-2025-8671	Vuln Note
netty	CVE-2025-55163	Advisory
Apache Tomcat	CVE-2025-48989	Advisory
F5 BIG-IP	CVE-2025-54500	Advisory
h2o	CVE-2025-8671	Advisory
swift-nio-http2	–	Adviosry

Zusammenfassung

Gal Bar Nahum fasst seine Erkenntnisse zu MadeYouReset zusammen: Er hat aufgezeigt, was die Schwachstelle ist, welchen Mechanismus sie ausnutzt, wie ihr Vorgänger Rapid Reset funktionierte, auf welche Weise gängige Schutzmaßnahmen umgangen werden und welche potenziellen Auswirkungen drohen.

Im nächsten Schritt will er die Details vertiefen: die einzelnen MadeYouReset-Primitiven, die Zählweise aktiver Streams im Protokoll, die Gründe, warum Backend-Prozesse nach einem Stream-Reset häufig weiterlaufen – und damit die gravierenden Folgen – sowie mögliche Abwehrmaßnahmen. Diese Aspekte werden im Beitrag Technische Details behandelt.

Korrekturen werden veröffentlicht

Viele Webserver bleiben offenbar ungepatcht und sind dadurch weiterhin angreifbar. Betroffen sind vor allem HTTP/2-Server sowie zentrale Systeme wie Netty, Jetty und Apache Tomcat.

Die Schwachstelle wurde vorab verantwortungsvoll gemeldet, sodass Anbieter Sicherheitsupdates vorbereiten konnten. Inzwischen veröffentlichen mehrere Hersteller Patches:

• SUSE hat Upstream-Projekte aktualisiert und eigene Patches für seine Produkte bereitgestellt.

• Varnish Cache schließt die Lücke in den Versionen 5.x bis 7.7.1. Wer nicht sofort aktualisieren kann, soll vorübergehend HTTP/2 deaktivieren.

• Fastly hat sein Netzwerk bereits am 2. Juni abgesichert, ohne dass Kunden eingreifen müssen.

• Netty stellt mit Version 4.2.4.Final eine gezielte Korrektur bereit.

• Apache Tomcat erhielt einen Fix per Commit; Red Hat warnt jedoch, dass derzeit keine Lösung vorliegt, die den eigenen Sicherheitsstandards entspricht.

Vielleicht spannend für Sie

---

 

---