Veröffentlicht am 11.07.2026
Ein einziger Serveraufruf kann Ihre komplette Website vom Netz nehmen – und das ganz ohne Hackertricks, ohne gestohlene Passwörter und ohne aufwendig präparierten Angriffscode. Genau dieses Szenario beschreibt CVE-2026-12184, eine gravierende Sicherheitslücke in PHP-FPM, die das PHP-Entwicklungsteam am 2. Juli 2026 gepatcht hat. Zusammen mit einer zweiten Schwachstelle in der OpenSSL-Verschlüsselung (CVE-2026-14355) betrifft das Update praktisch jeden Webserver, der PHP einsetzt – und das sind laut W3Techs rund 70,8 % aller Websites mit bekannter serverseitiger Programmiersprache.
Wenn Sie eine Website betreiben, die auf WordPress, WooCommerce, Joomla, Drupal oder einer eigenen PHP-Anwendung läuft, sollten Sie diesen Artikel bis zum Ende lesen. Wir erklären Ihnen verständlich, was passiert ist, ob Sie betroffen sind und was Sie jetzt konkret tun müssen.
Am 2. Juli 2026 veröffentlichte das PHP-Team gleichzeitig Sicherheitsupdates für alle vier aktuell unterstützten PHP-Zweige (8.2, 8.3, 8.4 und 8.5). Am 6. Juli 2026 wurden die Details öffentlich bekannt gemacht und von zahlreichen Sicherheitsmedien dokumentiert. Es geht um zwei Schwachstellen:
openssl_encrypt() bei einem speziellen Verschlüsselungsverfahren.Die gute Nachricht vorweg: Bislang wurden keine aktiven Angriffe für beide Schwachstellen in freier Wildbahn gemeldet. Die schlechte Nachricht: Bei CVE-2026-12184 ist die Hürde für einen Angriff extrem niedrig – und die Erfahrung zeigt, dass PHP-Schwachstellen schnell ausgenutzt werden. Die berüchtigte Lücke CVE-2024-4577 wurde 2024 innerhalb von nur 24 Stunden nach Bekanntwerden aktiv missbraucht.
PHP-FPM (FastCGI Process Manager) ist die Komponente, die auf den meisten Webservern die PHP-Anfragen verarbeitet. Sie verwaltet einen sogenannten Worker-Pool – eine Gruppe von Arbeitsprozessen, die sich die eingehenden Anfragen teilen.
Das Problem steckt im HTTP-Stream-Wrapper von PHP – also in dem Mechanismus, mit dem PHP Verbindungen ins Internet aufbaut, etwa über file_get_contents('https://...'), fopen oder HTTP-Bibliotheken. Baut PHP eine ausgehende HTTPS-Verbindung auf und schlägt dabei die TLS-Aushandlung fehl – zum Beispiel wegen eines abgelaufenen Zertifikats oder eines nicht übereinstimmenden Hostnamens –, wird die Verbindung korrekt geschlossen. Eine nachfolgende Aufräumroutine geht jedoch fälschlicherweise davon aus, dass die Verbindung noch gültig ist, und versucht, den Namen der Gegenstelle zurückzusetzen. Das erzeugt einen Zustand ähnlich einem Use-after-free (Zugriff auf bereits freigegebenen Speicher) und bringt den PHP-Prozess zum Absturz.
Und hier wird es kritisch: Weil sich unter PHP-FPM alle Worker einen Pool teilen, reicht ein einziger Absturz, um den gesamten Pool zu beenden. Die Website ist dann komplett offline.
„In php_stream_url_wrap_http_ex wird der Stream bei fehlgeschlagenem TLS-Aufbau geschlossen und auf NULL gesetzt. Der nachfolgende Cleanup-Block versucht jedoch bedingungslos, den Peer-Namen zurückzusetzen. Auslösbar durch eine fehlgeschlagene Peer-Namen-Validierung oder ein abgelaufenes Zertifikat. Dies ist ohne speziell präparierten Code und über einen entfernten Server auslösbar. Die Folge ist ein aus der Ferne auslösbarer DoS, der den gesamten FPM-Prozess mit allen Workern lahmlegt.“ – PHP Development Team (Jakub Zelenka), GHSA-mhmq-mmqj-2v39
Der PHP-Entwickler und SaaS-Architekt Joseph Charnin bringt die Gefahr auf den Punkt:
„One request can nuke the whole pool. […] No auth, low complexity. The condition is remotely triggerable by any server your code talks to. There's no login and no exotic payload. Huge attack surface: Moderne PHP-Apps machen ständig ausgehende HTTPS-Aufrufe: Webhooks, Payment Gateways, REST/GraphQL-APIs, RSS-Feeds, oEmbed/Link-Previews, SSO/OAuth-Callbacks, wp_remote_get() in WordPress, Composer und SOAP-Clients. Jeder dieser Endpunkte mit ungültigem TLS kann die Website umwerfen.“ – Joseph Charnin, josephcharnin.com
Entdeckt wurde die Lücke vom Sicherheitsforscher ndossche mithilfe eines hybriden statisch-dynamischen Analysewerkzeugs. Betroffen sind PHP-Versionen vor 8.3.32, 8.4.21 und 8.5.6. PHP 8.2 ist von dieser Lücke nicht betroffen.
Die zweite Lücke ist enger begrenzt. Sie betrifft nur Anwendungen, die die Funktion openssl_encrypt() mit dem Verschlüsselungsverfahren AES-WRAP-PAD (nach RFC 5649, „AES Key Wrap with Padding“) nutzen – ein eher selten eingesetztes Verfahren.
Das Problem: PHP berechnet die Größe des Ausgabepuffers allein aus der Länge des Klartexts. AES-WRAP-PAD macht den verschlüsselten Text aber länger als die Eingabe – es rundet auf die nächste 8-Byte-Grenze auf und fügt einen 8 Byte langen Kopfsatz hinzu. Der reservierte Speicher ist damit zu klein. OpenSSL schreibt über das Ende hinaus und beschädigt die Verwaltungsdaten des Speichers. Das Ergebnis: ein Absturz mit der Meldung zend_mm_heap corrupted – oft erst bei einer späteren Speicheroperation sichtbar. Betroffen sind PHP-Versionen vor 8.2.32, 8.3.32, 8.4.23 und 8.5.8.
Das Ausmaß ist enorm. PHP wird von 70,8 % aller Websites mit bekannter serverseitiger Sprache genutzt. WordPress allein betreibt rund 41,9 % aller Websites weltweit – und jede WordPress-Installation läuft auf PHP. Rechnerisch sind bei rund 205 Millionen aktiv gepflegten Websites weltweit über 145 Millionen potenziell betroffen. In Deutschland zählen laut Statistischem Bundesamt rund 3,2 Millionen Unternehmen zu den KMU, von denen ein Großteil eine eigene, oft PHP-basierte Website betreibt.
Besonders tückisch bei CVE-2026-12184: Fast jede moderne Website stellt ausgehende HTTPS-Verbindungen her. Denken Sie an einen Zahlungsanbieter, eine externe Wetter- oder Karten-API, einen Webhook, einen RSS-Feed oder eine „Anmelden mit Google“-Funktion. Reicht einer dieser kontaktierten Server ein ungültiges TLS-Zertifikat aus – oder erzwingt ein Angreifer per SSRF (Server-Side Request Forgery, das Erzwingen serverseitiger Anfragen) eine solche Verbindung, etwa über eine „Bild von URL importieren“- oder Avatar-Upload-Funktion –, kann die Website gezielt lahmgelegt werden.
php -v sowie php-fpm -v (ggf. php-fpm8.3 -v) aus. Vergleichen Sie die Version mit den Mindestwerten: 8.3.32 / 8.4.21 / 8.5.6 (für CVE-2026-12184) bzw. 8.2.32 / 8.3.32 / 8.4.23 / 8.5.8 (für CVE-2026-14355).<?php phpinfo(); ?> auf dem Server ab und rufen Sie sie auf. Wichtig: Datei danach sofort löschen.find /usr/bin /usr/sbin -name 'php*' -type f 2>/dev/null und jede gefundene Version mit -v prüfen.systemctl status php8.3-fpm (Version anpassen). Läuft FPM, ist CVE-2026-12184 relevant.wp_remote_get().grep -r 'wrap-pad\|WRAP_PAD\|wrap_pad' /var/www/ (Pfad anpassen).Der einzige wirksame Schutz ist das Update. Einen Workaround gibt es für CVE-2026-12184 nicht.
sudo apt update && sudo apt upgrade php8.3 php8.3-fpm (Version anpassen). Distributionen liefern Backports – prüfen Sie den Changelog auf die CVE-Referenz.sudo dnf update php php-fpm. Bei Remi-Repository: sudo dnf update --enablerepo=remi php.yum update ea-php83 ea-php84.sudo systemctl restart php8.3-fpm und mit php-fpm8.3 -v prüfen, dass die gepatchte Version geladen ist.journalctl -u php8.3-fpm -f | grep -Ei 'SIGSEGV|exited on signal|restart' – wiederholte Abstürze bei ausgehenden Anfragen können auf Ausnutzungsversuche hinweisen.Wer Managed Hosting nutzt, hat Glück: Plattformen wie Pantheon haben die Updates bereits am 7. Juli 2026 ausgerollt. Prüfen Sie dennoch bei Ihrem Anbieter nach, ob und wann gepatcht wurde.
Auch wenn CVE-2026-12184 in erster Linie die Verfügbarkeit betrifft, hat das eine rechtliche Dimension. Nach Art. 32 DSGVO sind Website-Betreiber, die personenbezogene Daten verarbeiten (Kontaktformulare, Online-Shops, Mitgliederbereiche), verpflichtet, „geeignete technische und organisatorische Maßnahmen“ zu ergreifen – ausdrücklich auch die Fähigkeit, die Verfügbarkeit der Daten bei einem technischen Zwischenfall rasch wiederherzustellen. Das Unterlassen eines bekannten Sicherheitsupdates kann als Verstoß gegen Art. 32 gewertet werden.
Ein reiner DoS ist zunächst keine Datenpanne. Wird jedoch bei einer Ausnutzung – etwa über SSRF-Techniken oder den Heap-Overflow von CVE-2026-14355 (Vertraulichkeitsimpact: niedrig) – unbefugt auf personenbezogene Daten zugegriffen, entsteht eine meldepflichtige Verletzung nach Art. 33 DSGVO (Meldung binnen 72 Stunden an die Aufsichtsbehörde). Bei hohem Risiko müssen nach Art. 34 DSGVO auch die Betroffenen informiert werden.
Die Bußgeldrisiken sind real: Nach Art. 83 DSGVO drohen bis zu 10 Millionen Euro oder 2 % des Jahresumsatzes (bei Verstößen gegen Art. 32). Deutsche Datenschutzbehörden verhängten 2025 mindestens 249 Bußgelder mit einer Gesamtsumme von 46,9 Millionen Euro – darunter allein ca. 45 Millionen Euro gegen Vodafone Deutschland. Zudem hat der BGH 2024 die Hürden für DSGVO-Schadensersatz nach Cyberangriffen gesenkt: Bereits ein „Kontrollverlust“ über Daten kann einen Anspruch begründen. Dokumentieren Sie daher den Vorfall und Ihre Gegenmaßnahmen gemäß Art. 33 Abs. 5 DSGVO – auch wenn keine Meldepflicht besteht.
Das Gesamtrisiko für KMU in Deutschland ist hoch. CVE-2026-12184 ist die wirklich gefährliche der beiden Lücken: Sie benötigt keine Authentifizierung, keinen präparierten Payload und legt bei Auslösung den gesamten PHP-FPM-Pool lahm. Die Angriffsfläche ist gewaltig, weil nahezu jede moderne PHP-Anwendung ausgehende HTTPS-Verbindungen herstellt – und einen Workaround gibt es nicht. CVE-2026-14355 ist mittelschwer und betrifft nur Anwendungen mit AES-WRAP-PAD, sollte aber ebenfalls zeitnah geschlossen werden.
Die Handlungsempfehlung ist eindeutig: Aktualisieren Sie PHP jetzt auf die höchste gepatchte Version Ihres Zweigs (8.2.32, 8.3.32, 8.4.23 oder 8.5.8), starten Sie PHP-FPM neu und überprüfen Sie, dass tatsächlich die gepatchte Version läuft. Wer noch PHP 8.1 oder älter betreibt, sollte die Migration nicht länger aufschieben – hier ist das Risiko kritisch, weil gar keine Patches mehr erscheinen. Bislang gibt es keine aktiven Angriffe, aber bei der enormen Verbreitung von PHP ist das nur eine Frage der Zeit. Handeln Sie, bevor ein einziger fehlerhafter TLS-Handshake Ihre Website vom Netz nimmt.