Vorwort

Am 27. Januar 2026 hat das OpenSSL-Projekt ein Security Advisory mit mehreren Schwachstellen veröffentlicht.

Das Interessante daran war, dass alle Sicherheitslücken von den selben Sicherheitsforschern, mit Hilfe einer KI-Quellcodeanalyse, entdeckt wurden und teilweise schon Jahrzehnte im Code schlummerten.

OpenSSL ist dabei nicht „irgendeine Library“, sondern in vielen Umgebungen ein zentrales Fundament für TLS/SSL, Zertifikate und kryptografische Funktionen.

Genau deshalb gilt: Jetzt ist ein guter Zeitpunkt, in den nächsten Tagen und Wochen systematisch alle Systeme auf Updates zu prüfen – nicht nur auf Servern, sondern auch auf Appliances, Embedded-Geräten (Firewalls, TV, Router, Hausautomation, etc.) und Software-Produkten, die OpenSSL mitliefern.

Was ist OpenSSL und warum ist es auf fast allen Geräten?

OpenSSL ist eine Kryptografie-Bibliothek, die unter anderem eine Open-Source-Implementierung von TLS/SSL bereitstellt und darüber hinaus zahlreiche Krypto-Funktionen (Schlüssel, Zertifikate, Signaturen, Hashes, Encoder/Decoder) liefert.

Wenn Software verschlüsselt kommuniziert oder Zertifikate verarbeitet, ist OpenSSL (oder eine Alternative) oft mit im Spiel – insbesondere, weil es als Open-Source-Software quelloffen, kostenlos und frei verfügbar ist. 

OpenSSL ist quasi „allgegenwärtig“:

• De-facto Standard im Open-Source-Ökosystem: Viele verbreitete Server-Stacks und Tools hängen historisch und praktisch an OpenSSL (direkt oder indirekt).
• Portabel & in C: Läuft von Embedded-Linux bis Enterprise-Server, lässt sich in sehr viele Produkte einbetten.
• Lange Historie: OpenSSL entstand Ende der 90er aus der SSLeay-Linie; die lange Historie sorgt dafür, dass es in sehr vielen Distributionen/Produkten seit Jahrzehnten verankert ist.
• „Supply chain“ im positiven Sinn: Nicht jede Software implementiert Kryptografie selbst (zum Glück), sondern nutzt bewährte Bibliotheken – und OpenSSL ist eine der häufigsten.

Wichtig: OpenSSL steckt nicht nur „auf dem Server“. Viele VPN-Gateways, NAS, Firewalls, Telefonanlagen/UC-Appliances, Drucker, Kameras, IoT-Geräte oder Software-Pakete nutzen OpenSSL entweder über das Betriebssystem oder bringen eine eigene Version mit.

Warum Sicherheitslücken in OpenSSL so viel "Impact" haben

Wenn OpenSSL verwundbar ist, hat das häufig schwerwiegende Folgen:

1. Breite Angriffsfläche: TLS, Zertifikate, PKCS#12/PKCS#7/CMS – das sind Formate/Protokolle, die in vielen Workflows vorkommen (Mail, S/MIME, Identity, VPN, Geräteprovisionierung, Zertifikatsverwaltung).
2. „Ein Fix, viele Abhängigkeiten“: Selbst wenn Sie OpenSSL nicht bewusst einsetzen, tun es viele Ihrer "Systeme", Ihr Reverse-Proxy, Ihr VPN-Stack oder ein Hersteller-Image.
3. Patch-Verzögerung in der Fläche: Bei Distributionen geht es oft schnell – bei Appliances/Embedded dauert es manchmal Wochen/Monate.

Zur Einordnung: OpenSSL hatte in der Vergangenheit Schwachstellen mit enormer Tragweite (z. B. Heartbleed) – nicht, weil alle Systeme gleich betroffen waren, sondern weil so viele Systeme OpenSSL nutzen.

Was ist am 27. Januar passiert?

Das Advisory enthält mehrere CVEs (Common Vulnerabilities and Exposures) in unterschiedlichen Schweregraden.

NB:  Common Vulnerabilities and Exposures ist ein vom US-amerikanischen National Cybersecurity FFRDC betriebenes und von der Mitre Corporation gepflegtes System zur standardisierten Identifikation und Benennung von öffentlich bekannten Sicherheitslücken und anderen Schwachstellen in Computersystemen.

Ein paar Beispiele:

• High: Stack Buffer Overflow in CMS AuthEnvelopedData Parsing (CVE-2025-15467) – kann je nach Umgebung zu Crash/Denial of Service (DoS) führen, potentiell auch zu Code-Ausführung (abhängig von Mitigations).
• Moderate: PKCS#12 PBMAC1 Parameter Validation (CVE-2025-11187) – betrifft PKCS#12-Verarbeitung in bestimmten OpenSSL-Versionen.
• Mehrere Low-Findings: u. a. DoS-Szenarien, ein Thema rund um TLS-Certificate-Compression-Speicherallokation sowie ein Edge-Case im openssl dgst-CLI-Verhalten.

Die meisten Low-/Moderate-Lücken erlauben es Angreifern, das Zielsystem abstürzen zu lassen oder außer Betrieb zu setzen, indem dieses z.B. Unmengen an Speicher reservieren muß oder falsche Annahmen bezüglich der zu verarbeitenden Daten trifft.

Betroffene Versionen & Zielversionen:

Im Advisory werden u. a. Updates auf 3.6.1 / 3.5.5 / 3.4.4 / 3.3.6 / 3.0.19 empfohlen (je nach eingesetzter Major-Line).

Hinweis: OpenSSL nennt außerdem, dass 3.1 und 3.2 "out of support" sind und im Advisory nicht analysiert wurden.

Parallel dazu haben Distributionen begonnen, Security-Updates auszurollen (Beispiel: Debian Security Announcement).

Was zu tun ist

1. Inventarisieren: „Wo steckt OpenSSL bei uns drin?“
Priorisieren Sie grob diese Klassen:

1. • Internet-exponierte Systeme: Reverse Proxies, Webserver, VPN-Gateways, Mail-Server, API-Gateways
   • Security-Kernkomponenten: PKI-Server, S/MIME-Verarbeitung, Identity-Workflows, Zertifikatsmanagement
   • Appliances/Embedded: Firewalls, NAS, UC/VoIP-Appliances, Kameras/IoT

2. Auf Updates prüfen – nicht nur Betriebssystem!

• Linux/Unix: OS-Updates (apt/yum/zypper) und Rebuilds/Restarts der relevanten Services
• Container: Base-Images aktualisieren und Images neu bauen/rollen
• Appliances: Firmware/Hersteller-Release-Notes prüfen (hier hängt es oft am Vendor-Cycle)

3. Fokus setzen:

Alles, was CMS/PKCS#7/PKCS#12 aus externen Quellen verarbeitet oder TLS-Terminiert und extern erreichbar ist, gehört nach oben in die Liste.

Hinweis: Manche Produkte nutzen System-OpenSSL, andere bringen vendored OpenSSL mit. Ein „OpenSSL ist installiert“ heißt nicht automatisch „diese App ist betroffen“ – aber es ist ein sehr brauchbarer Startpunkt für die Prüfung.

Details zu den Lücken

CVE-2025-11187 – Moderate

(PKCS#12 / PBMAC1 Parameter-Validierung)

• Problem/Lücke: Fehlende Validierung von PBKDF2-Parametern (Salt/Keylength) bei PBMAC1 in PKCS#12 kann Stack-Buffer-Overflow oder (NULL/invalid) Pointer-Dereferenz auslösen.
• Wie ausnutzbar: Angreifer liefert eine bösartig präparierte PKCS#12-Datei, die von einer Anwendung importiert/verifiziert wird (z. B. Zertifikats-/Key-Import).
• Folge: Typisch Crash/DoS; Overflow kann je nach Mitigations auch Code-Ausführung ermöglichen.

CVE-2025-15467 – High

(CMS AuthEnvelopedData / AEAD Parameter)

• Problem/Lücke: Beim Parsen von CMS AuthEnvelopedData mit AEAD (z. B. AES-GCM) wird eine IV aus ASN.1 in einen fixen Stack-Buffer kopiert, ohne Längenprüfung → Stack-Overflow.
• Wie ausnutzbar: Angreifer liefert eine präparierte CMS/PKCS#7-Nachricht (z. B. S/MIME AuthEnvelopedData), die ein Dienst/Client als „untrusted“ parst; Trigger passiert vor Auth/Tag-Verify, d. h. es braucht kein gültiges Schlüsselmaterial, um den Fehler auszulösen.
• Folge: Crash/DoS bis potenziell Remote Code Execution (plattformabhängig).

CVE-2025-15468 – Low

(QUIC / SSL_CIPHER_find unbekannte Cipher-ID)

• Problem/Lücke: In QUIC-Kontext kann SSL_CIPHER_find() bei unbekannter Cipher Suite ID zu NULL-Dereferenz führen (bestimmte Callback-Nutzung).
• Wie ausnutzbar: Peer sendet eine nicht unterstützte/unerwartete Cipher-ID, und die Anwendung ruft im QUIC-Pfad in einem client_hello_cb/ähnlich SSL_CIPHER_find() darauf auf.
• Folge: Prozessabbruch → DoS.

CVE-2025-15469 – Low

(openssl dgst trunciert >16MB bei One-Shot-Signaturen)

• Problem/Lücke: CLI-Tool openssl dgst puffert bei One-Shot-Algorithmen (Ed25519/Ed448/ML-DSA) nur 16 MB und trunkiert still statt Fehler zu werfen.
• Wie ausnutzbar: In Workflows, die Signieren und Verifizieren beide mit diesem betroffenen openssl dgst-Pfad machen, kann ein Angreifer Daten hinter den ersten 16 MB verändern/anhängen, ohne dass die betroffene Verifikation es merkt.
• Folge: Integritätslücke (falsches Sicherheitsgefühl: „gültig“, obwohl trailing bytes nicht abgesichert sind).

CVE-2025-66199 – Low

(TLS 1.3 CompressedCertificate Speicherallokation)

• Problem/Lücke: Bei TLS 1.3 Certificate Compression kann vor dem Dekomprimieren ein großer Heap-Buffer allokiert werden, ohne an max_cert_list zu binden.
• Wie ausnutzbar: Angreifer triggert Handshakes mit CompressedCertificate, sodass pro Verbindung hohe Memory-Allokation + CPU-Arbeit entsteht (nur wenn Compression gebaut/aktiv & verhandelt ist; Server nur bei mTLS-Client-Cert-Pflicht).
• Folge: Ressourcenverbrauch/Degradation → DoS.
  Mitigation laut Advisory: SSL_OP_NO_RX_CERTIFICATE_COMPRESSION.

CVE-2025-68160 – Low

(BIO_f_linebuffer / short writes)

• Problem/Lücke: In der Line-Buffering-BIO-Filterkette (BIO_f_linebuffer) kann es bei short writes des nachfolgenden BIO zu Heap Out-of-Bounds Write kommen (bei großen newline-freien Daten).
• Wie ausnutzbar: Nur wenn eine Anwendung explizit diesen Filter nutzt und ein Angreifer Einfluss auf große newline-freie Daten hat, die durch diese BIO-Kette laufen (nicht Standard in TLS-Pfaden).
• Folge: Meist Crash/DoS durch Memory Corruption.

CVE-2025-69418 – Low

(Low-Level OCB API: trailing bytes unverschlüsselt/un-auth)

• Problem/Lücke: Bei direkter Nutzung von CRYPTO_ocb128_encrypt/decrypt() mit HW-beschleunigten Pfaden und nicht 16-Byte-ausgerichteter Länge können die letzten 1–15 Bytes unverschlüsselt bleiben und nicht in den Auth-Tag eingehen.
• Wie ausnutzbar: Betrifft nur Anwendungen, die low-level OCB direkt in einem Call verwenden (EVP-Nutzer i. d. R. nicht betroffen; TLS nutzt keine OCB-Ciphersuites). Ein Angreifer, der Datenfluss/Format beeinflusst, kann die Trailing-Bytes lesen oder verändern.
• Folge: Vertraulichkeits- und Integritätsbruch für die letzten Bytes.

CVE-2025-69419 – Low

(PKCS12_get_friendlyname UTF-8 Konvertierung)

• Problem/Lücke: Bei BMPString→UTF-8 Konvertierung in PKCS12_get_friendlyname() kann ein 1-Byte Write vor den Heap-Buffer passieren (negativer Offset durch fehlerhafte Längen-/Capacity-Weitergabe).
• Wie ausnutzbar: Angreifer liefert präparierte PKCS#12; die Anwendung ruft explizit PKCS12_get_friendlyname() im Parsing-Pfad auf (Hinweis: PKCS12_parse() nutzt laut Advisory einen anderen Pfad).
• Folge: Memory Corruption, praktisch meist Crash/DoS.

CVE-2025-69420 – Low

(TS_RESP_verify_response ASN1_TYPE Validation)

• Problem/Lücke: Type Confusion bei RFC3161 TimeStamp-Response-Verifikation: ASN1_TYPE-Unionmember wird ohne Typprüfung verwendet → invalid/NULL deref.
• Wie ausnutzbar: Angreifer liefert eine malformierte TimeStamp Response, die eine Anwendung verifiziert (TS/RFC3161 ist eher Nischen-Use-Case).
• Folge: Crash/DoS.

CVE-2025-69421 – Low

(PKCS12_item_decrypt_d2i_ex NULL deref)

• Problem/Lücke: Fehlender NULL-Check für Parameter oct in PKCS12_item_decrypt_d2i_ex() → NULL-Dereferenz beim Parsing bestimmter malformed PKCS#12.
• Wie ausnutzbar: Angreifer bringt eine Anwendung dazu, eine malformierte PKCS#12 zu verarbeiten.
• Folge: Crash/DoS (laut Advisory nicht zu Code-Exec/Leak eskalierbar).

CVE-2026-22795 – Low

(PKCS#12 Parsing ASN1_TYPE Validation)

• Problem/Lücke: Type Confusion in PKCS#12-Parsing führt zu invalid pointer read; Zieladresse ist laut Advisory auf 0x00–0xFF begrenzt (Zero-Page), daher i. d. R. reproduzierbarer Crash.
• Wie ausnutzbar: Wieder: Anwendung muss bösartig präparierte PKCS#12 verarbeiten.
• Folge: DoS durch Crash.

CVE-2026-22796 – Low

(PKCS#7 signature verification / PKCS7_digest_from_attributes)

• Problem/Lücke: Type Confusion bei PKCS#7 Signed-Data-Verifikation: Zugriff auf messageDigest-Attribut ohne Typvalidierung → invalid/NULL deref.
• Wie ausnutzbar: Angreifer liefert malformiertes signed PKCS#7, das eine Anwendung verifiziert (PKCS#7 API ist „legacy“, CMS wird empfohlen).
• Folge: Crash/DoS.

Zusammenfassung

OpenSSL ist ein zentraler Kryptografie-Baustein und deshalb extrem weit verbreitet.

Das Advisory vom 27. Januar 2026 umfasst mehrere Schwachstellen mit unterschiedlicher Schwere – darunter mindestens eine High-Severity im CMS-Parsing.

Empfehlung: Prüfen Sie in den nächsten Tagen und Wochen systematisch die Update-Verfügbarkeit für Server, Container, Software-Stacks und insbesondere Appliances/Embedded-Geräte – und spielen Sie Updates zeitnah ein.