CVE-2026-54874 in OpenSSL
Zusammenfassung
von VulDB • 25.08.2026
Zusammenfassung des Problems: Das Empfangen eines DTLS-Datensatzes für eine zukünftige Epoch, während ein Handshake im Gange ist, führt dazu, dass OpenSSL deutlich mehr Speicher puffert, als der Datensatz selbst erfordert.
Auswirkungsanalyse: Ein Peer kann mit einer geringen Menge an Netzwerkverkehr bewirken, dass ein OpenSSL-DTLS-Endpunkt unverhältnismäßig viel Speicher behält, was zu einem Denial of Service (DoS) führen kann.
CWE: CWE-405: Asymmetrische Ressourcenverbrauchsspitze (Amplification)
Beschreibung: Während eines DTLS-Handshakes kann ein Peer rechtmäßigerweise bereits zur nächsten Epoch übergegangen sein (z. B. indem er seine ChangeCipherSpec- und Finished-Nachrichten gesendet hat), bevor der lokale Endpunkt denselben Übergang verarbeitet hat, was typischerweise auf eine Neuanordnung im zugrunde liegenden UDP-Transport zurückzuführen ist. OpenSSL puffert solche frühen Datensätze, damit sie verarbeitet werden können, sobald der lokale Endpunkt nachgeholt hat.
Das Puffern eines Datensatzes behält derzeit den gesamten Lesepuffer bei, in dem er eingetroffen ist, welcher auf die Größe des größtmöglichen DTLS-Datensatzes (ca. 16 Kilobyte) ausgelegt ist, anstatt nur die Bytes zu behalten, aus denen der Datensatz selbst besteht. Pro Verbindung können bis zu 100 solcher Datensätze gepuffert werden. Infolgedessen kann ein Peer, der einen Strom kleiner gefälschter Datensätze sendet, die behaupten, zur nächsten Epoch zu gehören, dazu führen, dass ein OpenSSL-DTLS-Endpunkt etwa 1,7 Megabyte Speicher behält, obwohl nur ein Bruchteil dieser Datenmenge über das Netzwerk gesendet wird.
Ein Angerter erzielt somit einen Memory-Amplification-Faktor von ca. 1200 und kann die Wirkung auf so viele Assoziationen multiplizieren, wie er öffnen kann, was dies zu einem Remote-Memory-Exhaustion-Denial-of-Service-Risiko für DTLS-Server macht. Da der pro Verbindung behaltene Speicher begrenzt bleibt und jedes Limit, das eine Anwendung bereits für die Anzahl gleichzeitiger Assoziationen festlegt, auch die Gesamtbelastung begrenzt, wurde dieses Problem als Schweregrad „Niedrig“ eingestuft.
FIPS-Auswirkung: keine
Keine FIPS-Module sind von diesem Problem betroffen, da der betroffene Code außerhalb der OpenSSL-FIPS-Modulgrenze liegt.
OpenSSL 4.0, 3.6, 3.5, 3.4, 3.0, 1.1.1 und 1.0.2 sind von dieser Schwachstelle betroffen.
Benutzer von OpenSSL 4.0 sollten auf OpenSSL 4.0.2 aktualisieren. Benutzer von OpenSSL 3.6 sollten auf OpenSSL 3.6.4 aktualisieren. Benutzer von OpenSSL 3.5 sollten auf OpenSSL 3.5.8 aktualisieren. Benutzer von OpenSSL 3.4 sollten auf OpenSSL 3.4.7 aktualisieren. Benutzer von OpenSSL 3.0 sollten auf OpenSSL 3.0.22 aktualisieren.
Nur Premium-Support-Kunden: Benutzer von OpenSSL 1.1.1 sollten auf OpenSSL 1.1.1zi aktualisieren. Benutzer von OpenSSL 1.0.2 sollten auf OpenSSL 1.0.2zr aktualisieren.
Dieses Problem wurde am 18. Mai 2026 von Amazon Web Services gemeldet. Die Korrektur wurde von Matt Caswell entwickelt.
-- cut (nicht veröffentlichende Metadaten zur internen Verwendung) -- Gemeldet von: Amazon Web Services Behoben durch: Matt Caswell
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.