Hoch63 / 100Konfidenz: Mittel

In CISA KEVCVSS8.8EPSS2 %Über Netz erreichbarOhne Zutun des Nutzers

Alle Systeme, die OpenSSL oder WolfSSL verwenden, müssen umgehend auf die neuesten gepatchten Versionen aktualisiert werden.

▸Herleitung der Bewertung(4)

Wie der Wert zustande kommt

Im CISA-KEV-Katalog: CVE-2026-65660+25
Hoechster CVSS-Basiswert 8.8+16
Wird laut Meldung tatsaechlich ausgenutzt: exploited in attacks+12
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

Fuer 2 erkannte CVE(s) liegt noch kein CVSS-Basiswert vor (NVD-Rueckstau).

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

Network & Perimeter

High-Severity Vulnerabilities Patched in OpenSSL, WolfSSL

SecurityWeek·30. September 2026, 06:55

Originalartikel lesen bei SecurityWeek

OpenSSL und WolfSSL haben Patches für mehrere kritische Sicherheitslücken veröffentlicht. Betroffen sind Anwendungen, die diese kryptografischen Bibliotheken nutzen, darunter VPNs, VoIP- und IoT-Produkte. Nutzer sollten ihre Systeme umgehend aktualisieren, um Angriffe wie Datendiebstahl, Dienstverweigerung (DoS) oder die Umgehung der Peer-Authentifizierung zu verhindern.

SecBoard-Einordnung

Die Schwachstellen ermöglichen Angreifern potenziell den Zugriff auf sensible Daten, die Unterbrechung von Diensten oder die Umgehung von Authentifizierungsmechanismen, was die Integrität und Vertraulichkeit der Kommunikation gefährdet.

Realistisch schlimmster Fall: Ein Angreifer könnte sensible Daten aus dem Heap-Speicher auslesen, Anwendungen zum Absturz bringen oder die Peer-Authentifizierung umgehen, um sich als legitimer Kommunikationspartner auszugeben und so unautorisierten Zugriff zu erlangen.

Empfehlung: Alle Systeme, die OpenSSL oder WolfSSL verwenden, müssen umgehend auf die neuesten gepatchten Versionen aktualisiert werden. Insbesondere sind VPNs, VoIP- und IoT-Produkte sowie Webserver zu prüfen.

Im erfassten Bestand

▸CVE-2026-65660 kommt damit in 13 erfassten Meldungen der letzten 90 Tage vor.
▸CVE-2026-65660 stand zum Zeitpunkt dieser Meldung seit 5 Tagen im KEV-Katalog der CISA.

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-65660CISA KEV

CVSS: 8.8 · HIGH
EPSS: 2.1%
Über das Netz: ja
Anmeldung nötig: ja
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Vertraulichkeit, Integrität, Verfügbarkeit
im KEV seit: 2026-09-25
Patch: unbekannt
Zuweisende CNA: secure@microsoft.com

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-89102

CVSS: 6.5 · MEDIUM
EPSS: 0.3%
Über das Netz: ja
Anmeldung nötig: ja
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Integrität
Patch: unbekannt
Zuweisende CNA: facts@wolfssl.com

CVE-2026-89136

CVSS: unbekannt
EPSS: 0.6%
Über das Netz: unbekannt
Anmeldung nötig: unbekannt
Nutzerinteraktion nötig: unbekannt
Angriffskomplexität: unbekannt
Beeinträchtigt: unbekannt
Patch: unbekannt
Zuweisende CNA: facts@wolfssl.com

CVE-2026-93302

CVSS: unbekannt
EPSS: 0.3%
Über das Netz: unbekannt
Anmeldung nötig: unbekannt
Nutzerinteraktion nötig: unbekannt
Angriffskomplexität: unbekannt
Beeinträchtigt: unbekannt
Patch: unbekannt
Zuweisende CNA: facts@wolfssl.com

Betroffen

Organisationen, die OpenSSL oder WolfSSL in ihren Anwendungen nutzen, insbesondere in VPNs, VoIP-Produkten, IoT-Geräten sowie in Webservern wie Nginx, HAProxy und Apache httpd.

Hersteller

MicrosoftWolfssl

Produkte

SharePointSharepoint Server2 VersionenWolfssl

▸ CPE-Rohbezeichner anzeigen (4)

cpe:2.3:a:microsoft:sharepoint_server:*:*:*:*:subscription:*:*:*
cpe:2.3:a:microsoft:sharepoint_server:2016:*:*:*:enterprise:*:*:*
cpe:2.3:a:microsoft:sharepoint_server:2019:*:*:*:*:*:*:*
cpe:2.3:a:wolfssl:wolfssl:*:*:*:*:*:*:*:*

Prüfen

▸Überprüfen Sie alle Systeme und Anwendungen auf die verwendeten Versionen von OpenSSL und WolfSSL.
▸Stellen Sie sicher, dass Patches für CVE-2026-84782, CVE-2026-93302, CVE-2026-89102 und CVE-2026-89136 angewendet wurden.

▸ 1 weitere

▸Führen Sie Scans durch, um ungepatchte Instanzen von OpenSSL und WolfSSL in Ihrer Umgebung zu identifizieren.

Offene Punkte

▸ anzeigen

▸Es ist nicht spezifiziert, welche spezifischen Versionen von OpenSSL und WolfSSL genau betroffen sind, außer dass Patches veröffentlicht wurden.
▸Die genauen Auswirkungen der Umgehung der Peer-Authentifizierung in Bezug auf Datenzugriff oder Systemkontrolle sind nicht detailliert beschrieben.
▸Es ist nicht spezifiziert, ob die Schwachstellen bereits aktiv ausgenutzt werden.

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?Ja
Detection / Logging prüfbar?Ja
Für Purple-Team-Szenario geeignet?Ja

Kundenfragen

Haben wir Citrix extern erreichbar?
Haben wir SharePoint extern erreichbar?
Können wir Defense Evasion detektieren?

MITRE ATT&CK(4)

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

T1005Data from Local Systemzugeordnet

„obtain heap memory fragments“

T1499Endpoint Denial of Servicezugeordnet

„crash applications using Datagram TLS (DTLS)“

T1550Utility Impairmentzugeordnet

„bypass peer authentication“

T1656Impersonationabgeleitet

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

Kill-Chain-Phasen

Wie weit im Ablauf die belegten Techniken liegen — je Technik die früheste Phase.

Auskundschaften

›

Bewaffnung

›

Zustellung

›

Ausnutzung

›

Einnistung

›

Fernsteuerung

›

Zielhandlung

1 Techniken ohne Phasenzuordnung (z. B. Verteidigungsumgehung, die quer zu allen Phasen läuft)

Quellen & Belege· 1 Quelle

SecurityWeekKontextPUBLICZuverlässigkeit Cdiese Meldung

Redaktionelle Berichterstattung, meist Zweitverwertung einer Primaerquelle.

High-Severity Vulnerabilities Patched in OpenSSL, WolfSSL

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-65660 CVE-2026-84782 CVE-2026-84783 CVE-2026-89102 CVE-2026-89136 CVE-2026-93302

ATT&CK-Heatmap

Themen

VulnerabilitiesOpenSSLpatchesvulnerabilityWolfSSL

Vollständigen Artikel lesen bei SecurityWeek

Erwähnte CVEs (6)

CVE-2026-65660HIGH(8.8)

KEVEPSS 2.1%

Improper control of generation of code ('code injection') in Microsoft Office SharePoint allows an authorized attacker to execute code over a network.

Details NVD

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-89102MEDIUM(6.5)

EPSS 0.3%

In wolfSSL versions 5.7.2 through 5.9.2 there is a client-side implementation flaw in RFC 6961, multiple OCSP response stapling, which can lead to certificate forgery. When a wolfSSL client enables OCSP stapling with the HAVE_CERTIFICATE_STATUS_REQUEST_V2 feature and calls wolfSSL_UseOCSPStaplingV2(ssl, WOLFSSL_CSR2_OCSP_MULTI, options), the client accepts any certificate in the peer's chain as a certificate authority without verifying that the certificate is actually authorized to act as one. This means that an attacker who possesses any certificate that chains to a CA trusted by the client (along with its private key) can forge certificates for arbitrary identities that will be accepted as valid by the client. The end entity certificate of the server is stored in the persistent trust store, affecting subsequent connections that reuse the context even when OCSP multi usage is not employed. Found by internal wolfSSL testing.

Details NVD

CVE-2026-89136NONE

EPSS 0.6%

When using RPK (Raw Public Key), the client side of a TLS 1.2, 1.3 and DTLS 1.2 connection could accept an unsolicited server_cert_type=RawPublicKey which allowed a malicious or misbehaving server to bypass authentication. RPK is off by default and only enabled in --enable-rpk OR --enable-all OR --enable-distro AKA HAVE_RPK builds.

Details NVD

CVE-2026-93302NONE

EPSS 0.3%

MatchTrustedPeer ignores the public key used, leading to forged CA clones passing verification. Affected builds are any that enable the macro WOLFSSL_TRUST_PEER_CERT and load CA certificates with wolfSSL_CTX_trust_peer_cert() or wolfSSL_trust_peer_cert(). The peer must know the certificates being loaded to either of those APIs to take advantage of the issue. When OPENSSL_COMPATIBLE_DEFAULTS is also defined this widens the affected API to include all CA certificate loading. Both macros are defined when using autoconf builds such as (nginx, haproxy, stunnel, wpas, apache httpd, hitch, bind, rsyslog, ffmpeg, all, distro). When the certificate is listed as a trusted peer certificate the issue previously allowed for a malicious (D)TLS server to bypass authentication once knowing which CA’s the client would accept. This also affects mutual authentication cases where the client knows which CA’s the server has loaded. If building with any of these configurations and using (D)TLS where the loaded CA’s could be known and authentication of the peer is desired, users should either: update to the latest wolfSSL version, apply the fix patch, or use the configure flag --disable-openssl-compatible-defaults and not load CA’s with wolfSSL_CTX_trust_peer_cert() or wolfSSL_trust_peer_cert() to mitigate the issue.

Details NVD

SecBoard-Einordnung

Im erfassten Bestand

Key Facts

Betroffen

Prüfen

Offene Punkte

Red-Team-Relevanz

MITRE ATT&CK(4)

Kill-Chain-Phasen

Quellen & Belege· 1 Quelle

Verknüpfte Intelligence

Verwandte Artikel