CVE-Datenbank

Problemzusammenfassung: Ein CMP-Client, der den Widerruf eines Zertifikats auf Grundlage einer PKCS#10-CSR anfordert, kann beim Verarbeiten einer speziell präparierten Widerrufsantwort einen NULL-Zeiger dereferenzieren und abnormal beendet werden. Auswirkungszusammenfassung: Die Dereferenzierung des NULL-Zeigers erfolgt bei einem Lesezugriff, was zu einem Absturz und einem Denial-of-Service der betroffenen Clientanwendung führt. CWE: CWE-476: Dereferenzierung eines NULL-Zeigers Beschreibung: Ein CMP-Client, der ein Zertifikat widerruft, muss dem Server mitteilen, welches Zertifikat widerrufen werden soll, und kann dazu eine PKCS#10-CSR statt des Zertifikats selbst oder seines Ausstellernamens und seiner Seriennummer bereitstellen. Dies ist in der Befehlszeile 'openssl cmp -cmd rr -csr <file>' oder über die API OSSL_CMP_exec_RR_ses() mit dem über OSSL_CMP_CTX_set1_p10CSR() bereitgestellten Zertifikat. Eine CSR enthält nicht den Ausstellernamen und die Seriennummer des Zertifikats, daher sendet der Client diese nicht. Ein Server kann in seiner Antwort optional das von ihm widerrufene Zertifikat benennen, woraufhin der Client diesen Namen mit dem vergleicht, was er gesendet hat. Da er weder einen Ausstellernamen noch eine Seriennummer gesendet hat, hat er nichts, womit er ihn vergleichen kann, und ein Server, der einen speziell präparierten Namen zurückgibt, veranlasst den Client, von einem NULL-Zeiger zu lesen und abzustürzen. Die Widerrufsantwort wird auf gültigen Nachrichtenschutz geprüft, bevor der betroffene Code erreicht wird. Ein Angreifer muss daher ein böswilliger oder kompromittierter CMP-Server oder ein Man-in-the-Middle sein, der im Besitz des für den Nachrichtenschutz verwendeten Geheimnisses ist. Clients, die das zu widerrufende Zertifikat anhand eines Zertifikats oder anhand von Aussteller und Seriennummer statt anhand einer PKCS#10-CSR identifizieren, sind nicht betroffen. FIPS-Auswirkung: nein Dieses Problem betrifft keine FIPS-Module, da sich die CMP-Protokollimplementierung außerhalb der Grenze des OpenSSL-FIPS-Moduls befindet.

Zusammenfassung des Problems: Der QUIC-Stack von OpenSSL erzwingt keine verbindungsweite Flusskontrolle für Streams. Entfernte Peers können weitere Bytes senden, solange diese innerhalb der Flusskontrollgrenzen des Streams liegen. Zusammenfassung der Auswirkungen: Ein bösartiger entfernter Peer kann das Fehlen einer verbindungsweiten Flusskontrolle für Streams ausnutzen und den QUIC-Stack dazu bringen, ~100MB Speicher statt 768 KiB (Standardgröße des Flusskontrollfensters) zu empfangen. CWE: CWE-770: Zuweisung von Ressourcen ohne Begrenzungen oder Drosselung Beschreibung: Der lokale QUIC-Stack gibt seinem entfernten Peer zwei Flusskontrollgrenzen bekannt: die Flusskontrollgrenze für Streams und die Flusskontrollgrenze für die Verbindung. Der entfernte Peer muss beim Übertragen von Stream-Daten beide Grenzen einhalten. Immer wenn der lokale QUIC-Stack einen Stream-Frame empfängt, prüft er, ob die Größe des empfangenen Stream-Frames innerhalb der Flusskontrollgrenzen liegt. Wird eine der beiden Grenzen überschritten (auf Stream- oder Verbindungsebene), muss der QUIC-Stack die Verbindung mit einem Flusskontrollfehler schließen. Der anfällige QUIC-Stack von OpenSSL erzwingt die Grenze auf Stream-Ebene, aber nicht die auf Verbindungsebene. Um das Problem auszunutzen, müssen drei Bedingungen erfüllt sein: - der entfernte Peer öffnet mehrere Streams - jeder Stream muss innerhalb der Flusskontrollgrenze auf Stream-Ebene bleiben - auf keinem der Streams darf ein Byte mit Offset null gesendet werden (um zu verhindern, dass der anfällige QUIC-Stack Daten verbraucht). Durch Erfüllung der obigen Bedingungen kann der entfernte Peer den lokalen Stack dazu bringen, 2 x MAX_STREAMS x (Flusskontrollgrenze des Streams) Bytes Speicher zuzuweisen. MAX_STREAMS hat standardmäßig den Wert 100, und die Grenze gilt sowohl für bidirektionale als auch für unidirektionale Streams, sodass sie insgesamt 200 beträgt. Das Standard-Flusskontrollfenster für einen Stream beträgt 512kB. Der entfernte Peer kann den anfälligen QUIC-Stack dazu zwingen, pro Verbindung 100MB Heap-Speicher zuzuweisen. FIPS-Auswirkung: nein Das FIPS-Modul ist nicht betroffen, da die QUIC-Implementierung außerhalb der Grenze des OpenSSL-FIPS-Moduls liegt.

Zusammenfassung des Problems: Ein TLS-Server, der SSL_set_SSL_CTX() aufruft, um eine Verbindung mitten während eines Handshakes auf einen anderen SSL_CTX umzustellen, kann auf Speicher hinter dem Ende eines internen Arrays zugreifen, wenn der Ersatzkontext mehr Provider-Signaturalgorithmen kennt als der Kontext, aus dem die Verbindung erstellt wurde. Anwendungen, die SSL_set_SSL_CTX() nie aufrufen, sind nicht betroffen. Zusammenfassung der Auswirkungen: Ein entfernter Kommunikationspartner kann möglicherweise einen kleinen Lesezugriff außerhalb der Grenzen und unter bestimmten Umständen einen Schreibzugriff außerhalb der Grenzen mit festem Wert auf dem Server-Heap verursachen. Dies kann zu einem Denial of Service führen. CWE: CWE-787: Schreibzugriff außerhalb der Grenzen Beschreibung: Eine TLS-Verbindung speichert beim Erstellen, übernommen aus dem SSL_CTX, durch den sie erstellt wurde, die Anzahl ihrer Zertifikatsslots: die integrierten Zertifikatstypen plus einen Slot für jeden Provider-TLS-SIGALG-Eintrag, den dieser Kontext kannte. Diese Anzahl bestimmt die Größe eines internen Arrays mit Gültigkeitsflags für Zertifikate pro Slot. Eine Anwendung kann den SSL_CTX einer Verbindung mitten während des Handshakes durch einen Aufruf von SSL_set_SSL_CTX() ersetzen, meist über einen Servername-Callback, um einen anderen virtuellen Host bereitzustellen. Dabei wurde die gespeicherte Anzahl nicht aktualisiert. Der Slot-Index eines Provider-Signaturalgorithmus entspricht seiner Position in der Liste des jeweiligen Kontexts, der ihn auflöst. Kennt der Ersatzkontext also mehr solcher Algorithmen als der ursprüngliche Kontext, kann ein vom Kommunikationspartner angebotener Algorithmus zu einem Index hinter dem Ende des Arrays aufgelöst werden. Bei der Verarbeitung der Signaturalgorithmen des Kommunikationspartners wird dann für jeden solchen Algorithmus ein Vier-Byte-Wort hinter dem Ende gelesen und, wenn das gelesene Wort null ist, ein fester Wert darübergeschrieben. Ein Kommunikationspartner, der viele solcher Algorithmen anbietet, kann Heap-Metadaten beschädigen und den Prozess zum Abbruch bringen. Diese Auswirkung haben nur Provider-Signaturalgorithmen, die einen der zusätzlichen Slots belegen und die der Server ebenfalls konfiguriert hat. Codepoints, die der Ersatzkontext nicht erkennt, werden verworfen, ohne einem Slot zugeordnet zu werden, und Provider-Signaturalgorithmen können nur ab TLS 1.3 verwendet werden. Die beiden Kontexte müssen daher unterschiedliche Anzahlen von Provider-Signaturalgorithmen kennen. Dafür sind separate Bibliothekskontexte, ein zwischen dem Erstellen der beiden Kontexten geladener Provider oder Provider erforderlich, die unterschiedliche Algorithmen bekanntgeben – in 4.0 gibt der Default-Provider beispielsweise SM2 bekannt, der FIPS-Provider hingegen nicht. Eine Bereitstellung, die diese Bedingung erfüllt, kann außerdem die betroffenen Algorithmen nicht mit legitimen Clients aushandeln, da dieselbe veraltete Anzahl die entsprechenden Zertifikate verbirgt. Daher wird die Fehlkonfiguration wahrscheinlich bemerkt. Aus diesem Grund und weil diese Konfiguration nicht die Standardeinstellung ist, wurde dieses Problem als Schweregrad „Niedrig“ eingestuft. FIPS-Auswirkung: nein Keine FIPS-Module sind von diesem Problem betroffen, da sich der betroffene Code außerhalb der Grenzen des OpenSSL-FIPS-Moduls befindet.

Zusammenfassung des Problems: Für SM2-Operationen mit privaten Schlüsseln wird auf ARM64- und RISC-V-Plattformen eine nicht konstantzeitoptimierte Implementierung der skalaren Punktmultiplikation verwendet. Zusammenfassung der Auswirkungen: Ein Angreifer, der die für SM2-Signaturen oder -Entschlüsselungen auf einer betroffenen Plattform benötigte Zeit messen oder das Cache-Line-Zugriffsmuster beobachten kann, kann Informationen über den geheimen Skalar erlangen. CWE: CWE-208: Beobachtbare Timing-Abweichung Beschreibung: Auf ARM64- und RISC-V-Prozessoren verwendet die SM2-Kurve eine optimierte Implementierung der skalaren Multiplikation, deren bedingte Verzweigungen und Tabellenzugriffe abhängig von den Bits des geheimen Skalars ausgewählt werden. Die Ausführungszeit und das Cache-Zugriffsmuster hängen daher vom langfristigen privaten Schlüssel (bei der SM2-Entschlüsselung) oder vom Nonce pro Signatur (bei der Erzeugung einer SM2-Signatur) ab, wodurch ein Timing- und Cache-Seitenkanal entsteht. Auswirkungen auf FIPS: nein SM2 ist kein FIPS-Algorithmus und die optimierte SM2-Implementierung ist nicht Teil des FIPS-Moduls. OpenSSL 4.0, 3.6, 3.5 und 3.4 sind auf AArch64 und RISC-V von diesem Problem betroffen. OpenSSL 3.0, 1.1.1 und 1.0.2 sind von diesem Problem nicht betroffen. Benutzer von OpenSSL 4.0 sollten auf OpenSSL 4.0.3 aktualisieren. Benutzer von OpenSSL 3.6 sollten auf OpenSSL 3.6.5 aktualisieren. Benutzer von OpenSSL 3.5 sollten auf OpenSSL 3.5.9 aktualisieren. Benutzer von OpenSSL 3.4 sollten auf OpenSSL 3.4.8 aktualisieren. Dieses Problem wurde am 2. Mai 2026 von Abhinav Agarwal gemeldet. Es wurde unabhängig davon am 6. Juni 2026 von Feng Xue gemeldet. Die Korrektur wurde von Igor Ustinov entwickelt. -- Schnitt (nicht veröffentlichende Metadaten zur internen Verwendung) -- Gemeldet von: Abhinav Agarwal, Feng Xue Behoben von: Igor Ustinov

Problemzusammenfassung: Die generische Skalarmultiplikation auf elliptischen Kurven, die für ECDSA- und SM2-Signaturoperationen mit Kurven verwendet wird, für die keine dedizierte Implementierung existiert, gibt über das Timing Informationen über den geheimen Nonce preis. Zusammenfassung der Auswirkungen: Ein Angreifer, der Signaturzeiten messen kann, könnte Informationen über den geheimen Nonce pro Signatur gewinnen, was über viele Signaturen hinweg mittels eines Angriffs auf Basis eines Gitters / des Hidden Number Problem zur Wiederherstellung des privaten Schlüssels führen kann. CWE: CWE-208: Beobachtbare Timing-Abweichung Beschreibung: Die generische Skalarmultiplikation auf elliptischen Kurven, die für Kurven ohne dedizierte Implementierung mit konstanter Laufzeit verwendet wird, polstert den geheimen Skalar mit BIGNUM-Operationen ohne konstante Laufzeit auf, sodass die benötigte Zeit vom Wert des geheimen Skalars abhängt, der aus dem ECDSA- und SM2-Nonce abgeleitet wird. Das Leck ist sehr klein; für seine Beobachtung ist eine große Anzahl von Messungen erforderlich. Der Effekt ist bei Kurven am stärksten, deren Gruppenordnung an einer Maschinenwortgrenze liegt, wie etwa brainpoolP384r1. Anwendungen, die ECDSA-Signaturen mit Brainpool- und anderen generischen Primzahlkurven erzeugen, sowie SM2-Signaturen auf Plattformen, die die generische Implementierung verwenden, sind von diesem Problem betroffen. Die NIST-Kurven P-256, P-384 und P-521 verwenden dedizierte Implementierungen mit konstanter Laufzeit und sind nicht betroffen. FIPS-Auswirkung: nein Die FIPS-Module sind nicht betroffen: Die zugelassenen NIST-Kurven, die im FIPS-Provider verwendet werden, verfügen über dedizierte Implementierungen mit konstanter Laufzeit und verwenden nicht den betroffenen Codepfad.

Zusammenfassung des Problems: Der OpenSSL-QUIC-Server kann, wenn er so konfiguriert ist, dass er keine Adressvalidierung durchführt, dazu gebracht werden, eingehende Pakete bei der Berechnung des nicht validierten Guthabens mehrfach zu zählen. Dies führt zu einer Verletzung der in RFC 9000 festgelegten Grenze für die Verstärkung nicht validierter Verbindungen um das Dreifache der empfangenen Datenmenge. Zusammenfassung der Auswirkungen: Ein Angreifer aus der Ferne, der Pakete an einen Server mit der OpenSSL-QUIC-Implementierung fälschen kann, könnte den Server zur Verstärkung eines DDoS-Angriffs nutzen. CWE: CWE-440: Verstoß gegen erwartetes Verhalten Beschreibung: Der QUIC-Stack von OpenSSL erzwingt im Serverbetrieb die Validierung der Clientadresse (RFC 9000, Abschnitt 8), um zu bestätigen, dass die Peer-Adresse nicht für einen Traffic-Verstärkungsangriff verwendet wird. Ist diese Funktion auf dem Server deaktiviert, begrenzt der QUIC-Stack die Menge der Serverdaten, die gesendet werden können, auf das Dreifache der von der Peer-Adresse empfangenen Datenmenge, bis der TLS-Handshake abgeschlossen ist. Der OpenSSL-QUIC-Server addiert im Nichtvalidierungsmodus beim Verarbeiten jedes QUIC-Pakets im Datagramm die Länge des gesamten empfangenen Datagramms zum Limit des nicht validierten Guthabens. Ein Peer aus der Ferne kann nach dem Herstellen einer Verbindung mit einem anfänglichen Client-Hello-Frame ein nachfolgendes Datagramm mit mehreren QUIC-Paketen senden. Dadurch wird der Server dazu gebracht, für jedes Paket im Datagramm die gesamte Datagrammlänge anzurechnen. Der Server glaubt dadurch, dass der Peer mehr Daten gesendet hat, als tatsächlich der Fall ist, und verletzt somit das in RFC vorgeschriebene Verstärkungslimit von 3x. FIPS-Auswirkungen: nein Da sich der QUIC-Stack außerhalb der Grenze des FIPS-Moduls befindet, sind keine FIPS-Module von diesem CVE betroffen.

Zusammenfassung des Problems: Ein Zertifikat mit vielen nameRelativeToCRLIssuer-CRL-Verteilungspunkten verursacht ein überproportionales Heap-Wachstum, wenn OpenSSL X.509-Erweiterungen zwischenspeichert. Zusammenfassung der Auswirkungen: Der Empfang eines manipulierten Zertifikats von einem bösartigen Peer kann zu erheblichem Speicherdruck und einem möglichen Denial-of-Service bei Clients oder bei Servern führen, die Clientzertifikate anfordern. CWE: CWE-770: Zuweisung von Ressourcen ohne Begrenzung oder Drosselung Beschreibung: Ein Zertifikat oder eine Gruppe von Zertifikaten, deren Größe unter dem Grenzwert für vom Peer akzeptierte Zertifikate (~100 KiB) liegt, kann während eines normalen TLS-Handshake dazu führen, dass auf der Empfängerseite mehrere Hundert MiB residenter Speicher zugewiesen werden. Dies kann ausreichen, um den Client oder Server zum Absturz zu bringen, wenn mehrere gleichzeitige Verbindungen zu ähnlich großen Speicherzuweisungen führen. Die Fehlerbehebung verschiebt die Verarbeitung der CRL-Verteilungspunkterweiterungen in Zertifikaten auf den Zeitpunkt, zu dem der verarbeitete Wert für die CRL-Verarbeitung benötigt wird. Dadurch werden große Speicherzuweisungen nicht über längere Zeit beibehalten, wenn solche Zertifikate empfangen werden. FIPS-Auswirkung: nein Der betroffene Code liegt außerhalb der FIPS-Modulgrenze.

Eine unzureichende Pfadvalidierung im lokalen IPC-Dienst von TeamViewer Full Client und Host unter Windows, Linux und macOS vor Version 15.82 ermöglicht es einem lokal authentifizierten Benutzer mit geringen Berechtigungen, beliebige Dateien mit erweiterten Berechtigungen (NT AUTHORITY/SYSTEM \ root) zu schreiben. Durch das Senden präparierter IPC-Befehle an den lokalen Dienst-Daemon könnte ein Angreifer Dateipfade manipulieren, was zu einer lokalen Rechteausweitung führt.

Fehlerhafte Randbedingungen in der Komponente Audio/Video: Playback. Diese Schwachstelle wurde in Firefox ESR 153.4, Thunderbird 157, Thunderbird 140.17, Thunderbird 153.4, Firefox 157, Firefox ESR 115.42 und Firefox ESR 140.17 behoben.

Fehlkompilierung durch JIT in der JavaScript-Engine-Komponente. Diese Sicherheitslücke wurde in Thunderbird 157 und Firefox 157 behoben.

Endlosschleife und Speicherleck im USB-HID-Protokolldissektor in 4.6.0 bis 4.6.8 und 4.4.0 bis 4.4.18 ermöglicht Denial of Service

Ein Absturz beim Profilimport in 4.6.0 bis 4.6.8 und 4.4.0 bis 4.4.18 ermöglicht Denial-of-Service und mögliche Codeausführung.

Ein Absturz des ZigBee-ZCL-Protokolldissektors in Version 4.6.0 bis 4.6.8 ermöglicht einen Denial-of-Service.

Ein Absturz des SCTP-Protokoll-Dissektors in 4.6.0 bis 4.6.8 und 4.4.0 bis 4.4.18 ermöglicht einen Denial-of-Service.

In betroffenen Versionen von Octopus Server kann ein authentifizierter Benutzer mit Berechtigungen zum Bearbeiten eines Environment oder Project speziell präparierte JSON-Inhalte für das Objekt festlegen. Eine unsichere Deserialisierung dieser Inhalte ermöglicht es dem Benutzer, beliebigen Code im Octopus Server-Prozess auszuführen.

Ein Out-of-Bounds-Schreibzugriff wurde durch eine verbesserte Bereichsprüfung behoben. Dieses Problem ist in iOS 26.7.1 und iPadOS 26.7.1, macOS Sequoia 15.8.1 und macOS Tahoe 26.7.1 behoben. Die Verarbeitung einer schädlich gestalteten Datei kann zur Ausführung beliebigen Codes führen. Apple ist ein Bericht bekannt, dem zufolge dieses Problem bei einem äußerst ausgeklügelten Angriff auf bestimmte gezielte Personen mit Versionen von iOS vor iOS 27 ausgenutzt worden sein könnte.

Authlib (v1.7.2 and below) enthält eine Schwachstelle zur Umgehung der Signaturprüfung. Die Methode JsonWebSignature.deserialize_json() akzeptiert ein JSON-Serialisierungs-JWS-Objekt und gibt die Nutzlast als erfolgreich verifiziert zurück, ohne eine Signatur zu prüfen und ohne einen kryptografischen Schlüssel zu verlangen.

Axios ist ein promise-basierter HTTP-Client für den Browser und Node.js. Von 0.28.0 bis 0.34.0 und von 1.15.1 bis 1.20.0 verarbeitet ToFormData geerbte Serialisierungsoptionen und Visitor-Eigenschaften, die durch Prototype Pollution bereitgestellt werden. Eine separate Prototype-Pollution-Schwachstelle innerhalb desselben Prozesses stellt geerbte Werte für dots, indexes, metaTokens, maxDepth, visitor oder Blob vor der Objektserialisierung bereit. Die geerbten Optionen verändern die Feldbenennung und Dateninterpretation von toFormData, maxDepth kann einen Request-Fehler erzwingen, Blob ändert die Werteverarbeitung und ein durch Pollution eingeschleuster visitor kann ausgeführt werden, wenn ein Angreifer bereits über die stärkere Fähigkeit verfügt, eine Funktion einzuschleusen. Die Feldbenennung und Dateninterpretation der Serialisierung können sich ändern, maxDepth kann einen Request-Fehler verursachen, Blob kann die Werteverarbeitung verändern und ein durch Pollution eingeschleuster visitor kann mit dem stärkeren Function-Injection-Primitiv ausgeführt werden. Dieses Problem ist in den Versionen 0.34.0 und 1.20.0 behoben.

Axios ist ein promise-basierter HTTP-Client für den Browser und Node.js. Von 1.17.0 bis 1.20.0 umgeht der fetch adapter die Redirect-Richtlinie maxRedirects: 0. Eine Axios-Anfrage verwendet den fetch adapter mit maxRedirects auf null gesetzt und erhält eine Redirect-Antwort. Die zugrunde liegende fetch-Implementierung folgt dem Redirect, anstatt die Redirect-Antwort unverändert zurückzugeben. Die umgeleitete Anfrage kann auf interne Antworten zugreifen oder trotz deaktivierter Redirects zustandsändernde interne Endpunkte erreichen. Dieses Problem wurde in Version 1.20.0 behoben.

Axios ist ein Promise-basierter HTTP-Client für den Browser und Node.js. Von Version 1.15.0 bis Version 1.20.0 wendet Axios shouldBypassProxy einen quadratischen regulären Ausdruck für nachgestellte Punkte auf Hostnamen bei Weiterleitungen an. HTTP_PROXY oder HTTPS_PROXY ist konfiguriert, NO_PROXY oder no_proxy ist nicht leer, Weiterleitungen werden verfolgt und ein präparierter Redirect-Location-Header enthält viele Punkte, auf die ein Zeichen folgt, das kein Punkt ist. Hostname.replace(/.+$/, '') führt beim Verarbeiten des präparierten Weiterleitungs-Hostnamens zu quadratischem Backtracking. Die synchrone Verarbeitung des regulären Ausdrucks kann die Node.js-Event-Schleife blockieren und einen Denial-of-Service verursachen. Dieses Problem wurde in Version 1.20.0 behoben.