Mittel25 / 100Konfidenz: Mittel

CVSS8.2EPSS0.4 %Über Netz erreichbarOhne AnmeldungOhne Zutun des Nutzers

Umgehend auf die gepatchten OpenSSL-Versionen 4.0.3, 3.6.5, 3.5.9 oder 3.4.8 aktualisieren.

▸Herleitung der Bewertung(2)

Wie der Wert zustande kommt

Hoechster CVSS-Basiswert 8.2+15
Ohne Anmeldung ueber das Netz ausnutzbar (CVE-2026-84782, CVSS-Vektor AV:N/PR:N)+10

Woraus sich die Konfidenz ergibt

Nur ein Herausgeber — keine Gegenlesung
Strukturierte CVE-Daten aus der NVD vorhanden

Die Konfidenz misst die Belegqualität, nicht die Schwere.

Einschränkungen

Schmale Datenlage: der Wert beruht auf wenigen Einzelsignalen.

Bewertung v1.2, deterministisch berechnet. Bedrohungswert und Konfidenz sind getrennte Größen.· 2026-09-30 08:09 UTCMethodik

Network & Perimeter

OpenSSL Fixes High-Severity DTLS Flaw That Can Leak Heap Memory Unencrypted

The Hacker News·30. September 2026, 08:09

Originalartikel lesen bei The Hacker News

OpenSSL hat eine schwerwiegende DTLS-Schwachstelle (CVE-2026-84782) behoben, die zum Leck von Heap-Speicher oder Programmabstürzen führen kann. Betroffen sind Anwendungen, die OpenSSL für DTLS nutzen, wie z.B. WebRTC. Nutzer sollten umgehend auf die gepatchten Versionen (z.B. OpenSSL 4.0.3, 3.6.5, 3.5.9, 3.4.8) aktualisieren, um das Risiko zu minimieren.

SecBoard-Einordnung

Die Schwachstelle kann zum Leck von Heap-Speicher führen, der sensible Daten enthalten könnte, oder zu Programmabstürzen, was die Verfügbarkeit von Diensten beeinträchtigt.

Realistisch schlimmster Fall: Ein Angreifer könnte durch Ausnutzung der Schwachstelle sensible Informationen aus dem Heap-Speicher abgreifen oder Denial-of-Service-Angriffe durch Absturz der betroffenen Anwendungen durchführen.

Empfehlung: Umgehend auf die gepatchten OpenSSL-Versionen 4.0.3, 3.6.5, 3.5.9 oder 3.4.8 aktualisieren. Für ältere Versionen sollten Premium-Support-Fixes bezogen werden.

Im erfassten Bestand

▸CVE-2026-84782 kommt damit in 3 erfassten Meldungen der letzten 90 Tage vor.

Gezählt im eigenen Bestand, rückwärts ab dem Erscheinungsdatum. Das ist Belegstärke, keine Aussage über die Häufigkeit in der Welt.

Key Facts

CVE-2026-84782

CVSS: 8.2 · HIGH
EPSS: 0.4%
Über das Netz: ja
Anmeldung nötig: nein
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Vertraulichkeit, Verfügbarkeit
Patch: unbekannt
Zuweisende CNA: openssl-security@openssl.org

CVE-2026-84783

CVSS: 7.5 · HIGH
EPSS: 0.2%
Über das Netz: ja
Anmeldung nötig: nein
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Verfügbarkeit
Patch: unbekannt
Zuweisende CNA: openssl-security@openssl.org

CVE-2026-75806

CVSS: 5.3 · MEDIUM
EPSS: 0.4%
Über das Netz: ja
Anmeldung nötig: nein
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Verfügbarkeit
Patch: unbekannt
Zuweisende CNA: openssl-security@openssl.org

Betroffen

Anwendungen, die OpenSSL für DTLS nutzen, insbesondere solche, die WebRTC-Datenkanäle und Internettelefonie verwenden.

Hersteller

Openssl

Produkte

Openssl

▸ CPE-Rohbezeichner anzeigen (1)

cpe:2.3:a:openssl:openssl:*:*:*:*:*:*:*:*

Prüfen

▸Überprüfen Sie alle Anwendungen auf die verwendete OpenSSL-Version, insbesondere solche, die DTLS oder WebRTC nutzen.
▸Stellen Sie sicher, dass ein Patch-Management-Prozess für kritische Bibliotheken wie OpenSSL vorhanden ist und angewendet wird.

▸ 1 weitere

▸Überwachen Sie Systemprotokolle auf unerwartete Programmabstürze oder ungewöhnliche Speichernutzung in DTLS-basierten Diensten.

Offene Punkte

▸ anzeigen

▸Es ist nicht spezifiziert, welche spezifischen Arten von Informationen im Heap-Speicher geleakt werden könnten.
▸Der genaue Mechanismus der Ausnutzung (z.B. ob eine Authentifizierung erforderlich ist) ist nicht detailliert beschrieben.
▸Es wird nicht angegeben, ob es bereits aktive Ausnutzungen dieser Schwachstelle gibt.

Red-Team-Relevanz

Was heißt das für dein nächstes Assessment?

▸ Einordnung anzeigen

Initial Access möglich?Ja
Privilege Escalation relevant?Unklar
Exploit öffentlich verfügbar?Möglich
Detection / Logging prüfbar?Möglich
Für Purple-Team-Szenario geeignet?Unklar

Kundenfragen

Sind wir hiervon betroffen — und können wir es detektieren?

MITRE ATT&CK(3)

Techniken aus allen Quellen zusammengeführt — nach Stärke des Belegs sortiert.

T1499Defacementzugeordnet

„Programmabstürze“

T1499.001Endpoint Denial of Service: Endpoint Denial of Servicezugeordnet

„Programmabstürze“

T1560Archive Collected Datazugeordnet

„Leck von Heap-Speicher“

Mehrere Herkünfte bei derselben Technik heißt: mehrere unabhängige Wege führen dorthin.

Quellen & Belege· 1 Quelle

The Hacker NewsKontextPUBLICZuverlässigkeit Cdiese Meldung

Redaktionelle Berichterstattung, meist Zweitverwertung einer Primaerquelle.

OpenSSL Fixes High-Severity DTLS Flaw That Can Leak Heap Memory Unencrypted

Nur eine Quelle — der Sachverhalt ist an keiner zweiten Stelle gegengelesen.

Verknüpfte Intelligence

Dieselben Entitäten an anderer Stelle auf SecBoard.

CVE-Profile

CVE-2026-84782 CVE-2026-84783 CVE-2026-75806

Vollständigen Artikel lesen bei The Hacker News

Erwähnte CVEs (3)

CVE-2026-84782HIGH(8.2)

EPSS 0.4%

Issue summary: The DTLS retransmission logic does not correctly handle a handshake message write that is suspended part-way through. The retransmitted message can be read past the message buffer and the retransmission overwrites the internal state the suspended write needs to resume correctly. Impact summary: The retransmitted message can disclose a heap memory to the peer as plaintext handshake data or cause a crash and a Denial of Service when the read reaches an unmapped memory region. CWE: CWE-125: Out-of-bounds Read Description: DTLS handshake messages can be written out in multiple fragments, and a write can suspend mid-message (returning WANT_WRITE) if the underlying transport temporarily cannot accept more data. While such a write is suspended, the DTLS retransmission timer may independently fire and ask the retransmission logic to resend an earlier, already-acknowledged-as-sent message from its retransmit queue. The retransmission logic reused the same internal buffer and position tracking as the message that was still being written, without resetting the position back to the start of the message being retransmitted. As a result the retransmission was read starting from wherever the suspended write had left off, producing a mislabelled message whose body was leftover bytes from the other, larger message still in flight - content that was never meant to be sent at that point, and which could run past the end of the allocated buffer. Separately, even when the retransmission is positioned correctly, allowing it to run to completion while another write is suspended overwrites the same shared bookkeeping that the suspended write depends on to resume. When the application later resumes the suspended write (via a subsequent SSL_read(), SSL_write(), SSL_accept(), or SSL_connect() call), it finds that bookkeeping in a state inconsistent with the message and aborts the process in a debugging build. The fix resets the retransmission's read position to the start of the message before resending, and skips retransmission entirely whenever a handshake write is still suspended, deferring to the next call that resumes it instead. FIPS impact: no The affected code is outside the FIPS module boundary.

Details NVD

CVE-2026-84783HIGH(7.5)

EPSS 0.2%

Issue summary: The first concurrent use of the same X.509 certificate by several threads may cause its cached extension data to be freed while another thread is still using it. Impact summary: A remote, unauthenticated peer could crash a multi-threaded TLS client, or a multi-threaded TLS server that requests client certificates, if the first certificate chains built to the same trusted CA certificate are built by several connections at the same time. This is a use-after-free read, which is likely to crash the process, resulting in a Denial of Service. CWE: CWE-416: Use After Free Description: OpenSSL caches the decoded values of a certificate's X.509v3 extensions inside the X509 object the first time they are needed. In OpenSSL 4.0 this cache is built in two phases: the extension values are computed while holding a read lock on the certificate, and the results are then installed into the certificate under a write lock. Because a read lock does not exclude other readers, several threads can compute the cache for the same certificate at the same time. Each thread that subsequently acquires the write lock installs its own results and frees the values installed by the thread before it, even though that earlier thread has already marked the cache as complete and may have returned pointers into it to its caller. A caller still using those pointers then reads freed memory. Any certificate shared between threads is exposed the first time its extensions are decoded. In TLS the certificates at risk are the trusted CA certificates supplied for chain verification, by whatever means, since these are shared by every connection and their extensions are decoded and cached the first time a chain is built to them. Certificates sent by the peer are decoded separately for each connection and are not shared, so they are not affected. In a TLS client verifying server certificates, or a TLS server that requests and verifies client certificates, the use-after-free could only occur if the first chains built to the same trusted CA are built by several connections at the same time. FIPS impact: no The FIPS module is not affected as X.509 certificate handling is outside of the OpenSSL FIPS module boundary. OpenSSL 4.0 is vulnerable to this issue. OpenSSL 3.6, 3.5, 3.4, 3.0, 1.1.1 and 1.0.2 are not affected by this issue. OpenSSL 4.0 users should upgrade to OpenSSL 4.0.3. This issue was reported on 27 August 2026 by Tim Becker (Xint.io) and independently in a public report on 31 August 2026 by aydinmercan. The fix has been developed by Bob Beck. -- cut (non-publishing metadata for internal use) -- Reported by: Tim Becker (Xint.io), aydinmercan Fixed by: Bob Beck

Details NVD

CVE-2026-75806MEDIUM(5.3)

EPSS 0.4%

Issue summary: An established DTLS 1.2 association using an AEAD cipher suite can be terminated by a single unauthenticated datagram whose encrypted fragment is shorter than the mandatory explicit IV and authentication tag overhead. Impact summary: An attacker who can send a datagram that is routed to an existing DTLS 1.2 association can tear that association down without knowing any key material. This is a Denial of Service limited to the targeted association. There is no memory safety or confidentiality impact. CWE: CWE-1284: Improper Validation of Specified Quantity in Input Description: In TLS 1.2 and DTLS 1.2 every record protected by an AEAD cipher suite carries an explicit IV followed by the ciphertext and an authentication tag. When decrypting such a record the record layer passed the record length to the cipher implementation before checking that the record was long enough to contain the explicit IV and the tag. For a record shorter than that overhead the cipher implementation rejected the impossible length, and the record layer treated this as an internal failure and raised a fatal internal_error alert instead of treating the record as one that failed authentication. In TLS 1.2 the same record causes a fatal internal_error alert instead of the expected bad_record_mac alert. Since any undecryptable record already terminates a TLS connection, this is a protocol conformance issue rather than a security issue in TLS. The fix validates the record length against the explicit IV and tag length before any AEAD processing, so that TLS reports bad_record_mac and DTLS silently discards the record. FIPS impact: no The affected code is outside the FIPS module boundary.

Details NVD