OpenSSL-Sicherheitsrelease: CVE-2026-45447 — wie eine leere ASN.1-Menge PKCS7_verify() einen fremden Puffer freigeben lässt

TL;DR — 90 Sekunden

Betroffen?

OpenSSL 4.0.0, 3.6.0–3.6.2, 3.5.0–3.5.6, 3.4.0–3.4.5, 3.0.0–3.0.20 sowie 1.1.1 vor 1.1.1zh und 1.0.2 vor 1.0.2zq — praktisch jede aktuelle Linie. Real betroffen vom High-Befund ist, wer angreiferkontrollierte PKCS#7-/S-MIME-Signaturen über die OpenSSL-PKCS7-API (PKCS7_verify(), PHP: openssl_pkcs7_verify()) verarbeitet. Die CMS-API ist von 45447 nicht betroffen.

Risiko?

CVE-2026-45447: Use-after-Free → Absturz, Heap-Korruption, in bestimmten Kontexten potenziell RCE. Dazu Moderate-Befunde: CMS-Integritäts-/Schlüssel-Oracle (34182), QUIC-Speicher-DoS (34183), OCSP-Stapling-Double-Free (35188).

Sofortmaßnahme?

OpenSSL auf die gepatchte Linie heben (4.0.1 / 3.6.3 / 3.5.7 / 3.4.6 / 3.0.21 bzw. 1.1.1zh / 1.0.2zq), Container-Basis-Images neu ziehen, TLS-terminierende Dienste und PHP-FPM/Worker neu starten.

Empfehlung?

Mittelstand und Enterprise: als Floor-Update im laufenden Patch-Zyklus einspielen; priorisieren, wenn ein Dienst signierte E-Mail/Dokumente per PKCS#7 prüft oder ein QUIC-/HTTP-3-Endpunkt öffentlich erreichbar ist.

Kritikalität?

high (referenziert das Hero-Badge — RCE-Potenzial bei 45447, aber vorbedingungs-gebunden; kein bekannter Masseneinsatz).

 

Was ist das Problem?

Der Sammelrelease vom 9. Juni schließt mehrere voneinander unabhängige Lücken. Wir behandeln ihn als ein Stück, weil OpenSSL keine einzelne austauschbare Bibliothek ist, sondern der Krypto-Boden unter fast allem, was im Mittelstand TLS spricht: PHP (ext/openssl), Node.js, nginx und Apache, PostgreSQL, Redis, curl und die meisten Container-Basis-Images. Ein OpenSSL-Update ist deshalb selten ein punktueller Patch, sondern ein Boden, der sich unter mehreren Diensten gleichzeitig bewegt.

Der schwerste Befund, CVE-2026-45447 (High), sitzt in PKCS7_verify(). Beim Verarbeiten einer PKCS#7- oder S-MIME-signierten Nachricht prüft OpenSSL das SignedData-Objekt. Ist dessen digestAlgorithms-Feld als leere ASN.1-SET vorhanden, gibt OpenSSL im Verlauf der Prüfung einen vom Aufrufer übergebenen BIO fälschlich frei. Die aufrufende Anwendung hält danach weiter eine Referenz auf genau diesen Puffer — typischerweise schlägt das zu, wenn sie später BIO_free() auf dem ursprünglich an PKCS7_verify() übergebenen BIO aufruft. Ab da liegt ein klassischer Use-after-Free vor: Je nach Allokator-Verhalten und BIO-Nutzungsmuster der Anwendung reicht die Folge von einem Absturz über Heap-Korruption bis — in bestimmten Kontexten — zu angreiferkontrollierter Code-Ausführung. Wichtig für die Einordnung: Anwendungen, die dieselbe Aufgabe über die CMS-API lösen, sind von 45447 nicht betroffen; die Lücke hängt am älteren PKCS7-Pfad.

Drei Moderate-Befunde gehören in dieselbe Betrachtung. CVE-2026-34182 lässt CMS-AuthEnvelopedData-Container mit gefälschten Parametern durchgehen: Ein On-Path-Angreifer kann eine echte AES-GCM-Nachricht so umschreiben, dass der Empfänger sie unter einem unauthentifizierten Keystream-Modus (AES-256-OFB) entschlüsselt und den MAC nie prüft — woraus sich ein Schlüssel-Oracle oder ein Integritäts-Bypass bauen lässt. CVE-2026-34183 ist ein QUIC-Speicherfresser: Ein bösartiger Peer flutet den lokalen QUIC-Stack mit PATH_CHALLENGE-Frames; für jeden wird ein PATH_RESPONSE alloziert, der erst beim (nie kommenden) Acknowledgement freigegeben wird — unbeschränktes Wachstum, Denial of Service. CVE-2026-35188 ist ein Double-Free im Client beim Prüfen einer OCSP-gestapleten Antwort (nur relevant, wenn OCSP-Stapling clientseitig aktiv ist — kein Default). Dazu kommen Low-Befunde in der ASN.1-Verarbeitung (34180, 7383) und eine PKCS#12-PBMAC1-Schwäche (34181).

Wer ist betroffen?

Die Versions-Betroffenheit ist nahezu universell — fast jede laufende OpenSSL-Installation. Die Risiko-Betroffenheit ist je Lücke enger: 45447 trifft nur, wer PKCS#7-/S-MIME-Signaturen aus angreifbarer Quelle über die Legacy-PKCS7-API prüft (signierte Inbound-Mails, AS2/EDI, signierte Dokument-Uploads, Lizenz-/Token-Validierung). 34183 trifft, wer einen öffentlich erreichbaren QUIC-/HTTP-3-Endpunkt betreibt. 34182 braucht eine On-Path-Position und CMS-Entschlüsselung mit Erfolgs-/Fehler-Rückmeldung. 35188 braucht clientseitig aktives OCSP-Stapling. Entschärfend wirkt durchweg, wer auf die CMS-API statt PKCS7 setzt, QUIC nicht exponiert und OpenSSL ohnehin über gepinnte Basis-Images zentral aktualisiert.

Auswirkungen

OpenSSL stuft CVE-2026-45447 als High ein. Der Wirkpfad ist ein Use-after-Free auf einem caller-owned BIO: In der Breite ist die verlässlich erreichbare Wirkung ein Absturz (Denial of Service), in ungünstigen Konstellationen Heap-Korruption, und „in some application contexts this may potentially be exploitable for remote code execution“ (OpenSSL-Advisory). Verlässliche Code-Ausführung über einen UAF ist technisch anspruchsvoll und stark umgebungsabhängig — die ehrliche Einordnung lautet: ernster Handlungsdruck dort, wo angreiferkontrollierte PKCS#7-/S-MIME-Daten durch PKCS7_verify() laufen, ansonsten ein reguläres, aber zügiges Floor-Update.

Die Moderate-Befunde verschieben das Bild nicht ins Dramatische, sind aber je nach Setup relevant: 34182 ist eine echte Krypto-Integritätslücke (Bleichenbacher-artiges Oracle / Integritäts-Bypass im CMS-Pfad) und damit für jeden interessant, der CMS-verschlüsselte Nachrichten verarbeitet; 34183 ist ein unbeglaubigter, netzbasierter QUIC-DoS, der HTTP/3-Edges und Load-Balancer trifft, deren QUIC-Anteil zunehmend OpenSSL nutzt. In Architektur-Sprache: Die gefährlichste Lücke hängt an einer alten API, die viele Häuser nie auf CMS migriert haben — der Patch schließt die konkrete Stelle, die Migration schließt die Klasse.

Mitigation / Sofortmaßnahmen

Sofort: OpenSSL auf die gepatchte Linie heben

# Installierte Version je Host prüfen
openssl version -a          # Ziel je Linie: 4.0.1 / 3.6.3 / 3.5.7 / 3.4.6 / 3.0.21

# Debian/Ubuntu
apt update && apt install --only-upgrade openssl libssl3 libssl3t64
# RHEL/Alma/Rocky
dnf update openssl openssl-libs
# Alpine / Wolfi (Container-Basis)
apk upgrade --no-cache openssl libcrypto3 libssl3

# Dienste, die gegen OpenSSL gelinkt sind, neu starten (Library wird beim Start geladen)
systemctl restart nginx php-fpm postgresql redis-server

Container: Basis-Images neu bauen, nicht patchen

# Image-Bestand auf OpenSSL-Version prüfen
docker run --rm <image> openssl version 2>/dev/null || \
docker run --rm <image> sh -c 'apk info openssl 2>/dev/null || dpkg -l | grep -i libssl'

# Gepatchtes Basis-Image neu ziehen und App-Image neu bauen
docker pull <basis-image>:<gepatchter-tag>
docker build --no-cache -t <app-image>:<neuer-tag> .
# Rollout über Digest erzwingen (nicht über mutable Tag)

Wenn ein Update kurzfristig nicht möglich ist (Stopgaps, kein Ersatz für den Patch)

# 45447: keine angreiferkontrollierten PKCS#7-/S-MIME-Daten durch PKCS7_verify() leiten;
#        wo möglich auf die CMS-API (CMS_verify) umstellen.
# 34183: QUIC/HTTP-3 nur dort exponieren, wo gebraucht; QUIC-Listener sonst deaktivieren
#        oder hinter einem QUIC-fähigen Edge mit Rate-Limit/Address-Validation betreiben.
# 35188: clientseitiges OCSP-Stapling-Verifizieren nur gegen vertrauenswürdige Server.

Wichtig: Die OpenSSL-Bibliothek wird beim Prozessstart geladen. Ein apt upgrade ohne anschließenden Neustart der gelinkten Dienste lässt den alten, ungepatchten Code im laufenden Speicher — der häufigste Fehler bei OpenSSL-Updates.

Detection / Prüfung

Bestand feststellen: Wer linkt welche OpenSSL-Version?

# Laufende Prozesse, die libcrypto/libssl geladen haben (statt nur Paketstand)
for pid in $(pgrep -d' ' -f '.'); do
  maps=/proc/$pid/maps
  [ -r "$maps" ] && grep -qE 'libssl|libcrypto' "$maps" 2>/dev/null && \
    printf '%s\t%s\n' "$pid" "$(grep -oE 'libcrypto[^ ]*' "$maps" | head -1)"
done | sort -u

# Container-Flotte
docker ps --format '{{.Names}}' | while read c; do
  printf '%s: ' "$c"; docker exec "$c" openssl version 2>/dev/null || echo "n/a"
done

PHP-Anwendungen: nutzt der Code die anfällige PKCS7-API?

# Suche nach Legacy-PKCS7-Aufrufen auf angreifbaren Eingaben
grep -rnE 'openssl_pkcs7_(verify|read)|PKCS7_verify' \
  --include='*.php' --include='*.c' --include='*.go' path/to/app

# Gegenprobe: CMS-API (nicht von 45447 betroffen)
grep -rnE 'openssl_cms_(verify|read)|CMS_verify' --include='*.php' path/to/app

Abnahme nach dem Patch

# Version je Dienst nach Neustart bestätigen
openssl version            # erwartet: gepatchte Linie
# QUIC-Endpunkt: Speicherverhalten unter PATH_CHALLENGE-Last beobachten (nur Testumgebung)
# PKCS7-Pfad: Regressionstest mit einer Nachricht, deren digestAlgorithms leer ist —
#             auf gepatchtem OpenSSL kein UAF (mit ASAN-Build verifizieren).

Betreiberempfehlung

Operational Decision Block:

• Priorisiert einspielen (heute), wenn: ein Dienst angreiferkontrollierte PKCS#7-/S-MIME-Signaturen über die Legacy-API prüft oder ein öffentlich erreichbarer QUIC-/HTTP-3-Endpunkt betrieben wird.
• Im laufenden Patch-Zyklus (diese Woche), wenn: OpenSSL nur als TLS-Floor unter HTTP/1.1–HTTP/2-Diensten ohne PKCS7-Verifikation auf Fremdinput läuft.
• Nur verifizieren, wenn: Basis-Images bereits auf die gepatchte Linie aktualisiert und alle gelinkten Dienste neu gestartet wurden.

Mittelstand

Basis-Images neu ziehen und Container neu bauen, dann TLS-terminierende Dienste und PHP-FPM neu starten. Anschließend die eine Frage klären, die diese Lücke wirklich stellt: Prüft irgendein Code im Haus signierte E-Mails oder Dokumente über die alte PKCS7-API? Wenn ja, ist die dauerhafte Härtung der Umstieg auf die CMS-API, nicht nur der Patch.

Enterprise / mehrstufige Flotten

Patch-Stand über die Flotte per Inventar (SBOM / Image-Digest) verifizieren statt per Stichprobe, weil OpenSSL in zahllosen transitiven Image-Schichten steckt. QUIC-Edges zusätzlich mit Address-Validation und Rate-Limit gegen 34183 absichern.

Kubernetes / deklarative Stacks

Gepatchte Basis-Images über die Registry ausrollen, Image-Digest pinnen, Rollout über alle Replicas erzwingen. Admission-Policy ergänzen, die Images mit OpenSSL unterhalb der gepatchten Linie ablehnt. Daran denken: Ein rollierender Neustart ist nötig, damit Pods die neue Library laden.

Was wir konkret getan haben

Wir haben den Advisory am Erscheinungstag gegen unseren Bestand geprüft. Weil unsere Container zentral über Digest gepinnt und nächtlich aus gehärteten Basis-Images neu gebaut werden, war die Versionsfrage in Minuten beantwortet statt per Host-Stichprobe — genau der Nutzen, den ein gepflegtes Image-Inventar an einem solchen Tag ausspielt. Die gepatchten Basis-Images sind eingezogen, die TLS-terminierenden Dienste und PHP-Worker wurden rollierend neu gestartet, damit die neue libcrypto tatsächlich im Speicher liegt und nicht nur auf der Platte.

Operativ relevanter als der Patch selbst war die zweite Frage: Läuft bei uns irgendwo eine PKCS#7-/S-MIME-Verifikation auf Fremdinput über die alte API? Wir haben den Code danach durchsucht (openssl_pkcs7_verify, PKCS7_verify) und die wenigen Fundstellen gegen die CMS-Variante abgeglichen. Der Lesson-Learned ist eine Architektur-Aussage, keine Einzelmaßnahme: Die gefährlichste der zehn Lücken hängt nicht an „OpenSSL ist alt“, sondern an „wir rufen eine deprecated API auf Fremddaten auf“. Der Patch schließt CVE-2026-45447; die Migration von PKCS7 auf CMS schließt die ganze Klasse von Folgefehlern in diesem Pfad. Wir behandeln den OpenSSL-Floor außerdem bewusst als Inventar-Thema: Nicht „ist OpenSSL gepatcht?“, sondern „welche laufenden Prozesse haben die alte libcrypto noch im Adressraum?“.

Fazit

Der OpenSSL-Release vom 9. Juni ist kein Feueralarm, aber ein Pflichttermin. Die Versions-Betroffenheit ist nahezu universell, der gefährlichste Befund (CVE-2026-45447, Use-after-Free mit RCE-Potenzial) aber an eine konkrete Vorbedingung gebunden: die Verarbeitung angreiferkontrollierter PKCS#7-/S-MIME-Signaturen über die Legacy-API. Wer die hat, handelt im 48-Stunden-Fenster; wer OpenSSL „nur“ als TLS-Boden betreibt, spielt das Update im laufenden Zyklus ein — und vergisst dabei nicht den Neustart der gelinkten Dienste. Die nachhaltige Lehre liegt eine Ebene tiefer als der Patch: Die schwerste Lücke hängt an einer deprecated API, die viele nie migriert haben. Patchen schließt die Stelle, Migration auf CMS schließt die Klasse.

Quellen

• OpenSSL Security Advisory vom 9. Juni 2026 (Primärquelle, alle CVEs des Releases, betroffene/gefixte Versionen)
• OpenSSL — Vulnerabilities (Übersicht 2026) (Stand 09.06.2026)
• CVE Record — CVE-2026-45447 (PKCS7_verify Use-after-Free, High)
• CVE Record — CVE-2026-34182 (CMS AuthEnvelopedData, Moderate)
• CVE Record — CVE-2026-34183 (QUIC PATH_CHALLENGE DoS, Moderate)
• CVE Record — CVE-2026-35188 (OCSP-Stapling Double-Free, Moderate)