Veröffentlicht am 07.07.2026
Am 4. Juli 2026 haben die PHP-Entwickler gleich vier Sicherheitsreleases veröffentlicht: PHP 8.2.32, 8.3.32, 8.4.23 und 8.5.8. Der Anlass ist unter anderem eine Speicher-Schwachstelle mit der Kennung CVE-2026-14355, die es einem Angreifer unter bestimmten Umständen erlaubt, einen PHP-Prozess zum Absturz zu bringen. Die gute Nachricht vorweg: Für die allermeisten Website-Betreiber ist das konkrete Risiko dieser einen Lücke gering – betroffen sind nur Anwendungen, die eine sehr selten genutzte Verschlüsselungsfunktion verwenden. Die schlechte Nachricht: Die Sicherheitsreleases beheben gleichzeitig eine deutlich gefährlichere Lücke (CVE-2026-12184, CVSS 8.2), weshalb das Update trotzdem für praktisch jeden PHP-Server dringend empfohlen ist.
Wir erklären in diesem Artikel, was genau passiert ist, wer betroffen ist, wie Sie das in wenigen Minuten selbst prüfen und was Sie jetzt konkret tun sollten – auch mit Blick auf die DSGVO.
In der PHP-Erweiterung ext/openssl – dem Teil von PHP, der Verschlüsselungsfunktionen bereitstellt – steckt ein sogenannter Heap-basierter Buffer-Overflow (Speicherüberlauf im dynamisch verwalteten Arbeitsspeicher). Konkret betrifft er die häufig genutzte Funktion openssl_encrypt(), allerdings nur in einem ganz bestimmten Betriebsmodus: dem AES-WRAP-PAD-Modus (auch AES-128-WRAP-PAD oder AES-256-WRAP-PAD genannt). Dieser Modus dient dazu, kryptografische Schlüssel sicher zu „verpacken“, und ist in der Praxis extrem selten im Einsatz.
Gemeldet wurde das Problem am 29. Mai 2026 vom GitHub-Nutzer olegbaturin als Issue #22186 im offiziellen php-src-Repository. PHP-Kernentwickler Jakub Zelenka (bekannt als „bukka“) analysierte den Fehler und veröffentlichte am 2. Juli 2026 das Security Advisory GHSA-7jrw-539f-x6vr mit der offiziellen CVE-Nummer CVE-2026-14355. Kurz darauf erschienen die vier Sicherheitsreleases.
Der Fehler ist ein klassisches Dimensionierungsproblem. Wenn PHP im AES-WRAP-PAD-Modus Daten verschlüsselt, reserviert es einen Ausgabepuffer – also einen Speicherbereich für das Ergebnis. Die Größe dieses Puffers berechnet PHP allerdings nur anhand der Länge der Eingabedaten (Klartext).
Das ist der entscheidende Denkfehler: Der Algorithmus AES-WRAP-PAD (definiert im technischen Standard RFC 5649) macht das Ergebnis grundsätzlich länger als die Eingabe. Er rundet die Eingabe auf das nächste Vielfache von 8 Bytes auf und stellt zusätzlich einen 8 Byte langen Prüfwert (den sogenannten Authentication Integrity Value, AIV) voran. Die tatsächliche Ausgabelänge beträgt also aufgerundet(Länge, 8) + 8 Bytes – und ist damit immer größer als der reservierte Speicher.
Die Folge: OpenSSL schreibt beim Verschlüsseln über das Ende des zu kleinen Speicherbereichs hinaus und überschreibt dabei die internen Verwaltungsstrukturen des Zend Memory Managers (der Speicherverwaltung von PHP). Das äußert sich dann als Fehlermeldung zend_mm_heap corrupted – interessanterweise oft nicht sofort, sondern erst bei einer späteren Speicheroperation.
PHP-Entwickler Jakub Zelenka beschreibt das Problem im offiziellen Advisory so:
„Use of AES-WRAP-PAD can result in memory corruption and abort of application. The output buffer for the AES key-wrap-with-padding operation is sized from the plaintext length without accounting for RFC 5649 expansion. […] The zend_string PHP allocates is therefore too small for what OpenSSL's EVP_EncryptUpdate/EVP_EncryptFinal writes.“ (PHP GitHub Security Advisory GHSA-7jrw-539f-x6vr)
Ein Angreifer, der die Länge und den Inhalt der zu verschlüsselnden Daten beeinflussen kann, kann so den PHP-Prozess gezielt zum Absturz bringen – ein Denial of Service (DoS), also eine Störung der Verfügbarkeit. Eine Übernahme des Servers (Remote Code Execution) ist über diese Lücke nicht dokumentiert.
Die Schwachstelle erhält von der US-amerikanischen National Vulnerability Database (NVD) einen CVSS-Wert von 5.6 (Medium). Der Angriffsvektor ist netzwerkbasiert (AV:N), es werden keine Privilegien (PR:N) und keine Benutzerinteraktion (UI:N) benötigt. Die Angriffskomplexität ist jedoch hoch (AC:H), weil der Angreifer erst einmal eine Anwendung finden muss, die den seltenen AES-WRAP-PAD-Modus aktiv nutzt. Vertraulichkeit und Verfügbarkeit werden als „Low“ eingestuft, Integrität als nicht betroffen.
Der EPSS-Score – ein Maß für die Wahrscheinlichkeit einer Ausnutzung in den nächsten 30 Tagen – liegt bei nur 0,25 %. Einen öffentlichen Exploit gibt es (Stand 7. Juli 2026) nicht, und eine aktive Ausnutzung in freier Wildbahn ist nicht bekannt.
Do Son, Gründer von SecurityOnline.info, ordnet das so ein:
„The OpenSSL bug scores lower because it needs a rare code path. Still, both deserve a prompt update. So far, no in-the-wild exploitation has been reported for either flaw.“
Wichtig: Der Verweis auf „both“ betrifft die zweite, gefährlichere Lücke CVE-2026-12184 (CVSS 8.2, ebenfalls ein Remote-DoS über einen TLS-Handshake-Fehler), die dieselben Sicherheitsreleases beheben. Diese betrifft potenziell alle PHP-FPM-Installationen und ist der eigentliche Grund, warum das Update Priorität haben sollte.
Betroffen sind alle PHP-Installationen der folgenden Versionsbereiche, die den AES-WRAP-PAD-Modus in openssl_encrypt() verwenden:
Der entscheidende Punkt: Standard-CMS wie WordPress, Joomla, TYPO3, Shopware oder Magento nutzen den AES-WRAP-PAD-Modus in der Regel nicht. Schätzungen zufolge verwenden weniger als 1 % aller PHP-Anwendungen diesen Modus aktiv. Praktisch relevant ist die Lücke vor allem für spezialisierte Kryptografie-Anwendungen, bestimmte Zahlungsmodule oder individuell entwickelte Sicherheitslösungen.
Zur Einordnung der Reichweite: PHP wird laut W3Techs (Juli 2026) von rund 70,8 % aller Websites mit bekannter serverseitiger Programmiersprache eingesetzt, allein WordPress betreibt 41,9 % aller Websites. Die Verbreitung der PHP-Basis ist also enorm – die konkrete Angriffsfläche dieser einen Lücke jedoch klein.
php -v aus oder rufen Sie phpinfo() über eine PHP-Datei auf. Ist die Version kleiner als 8.2.32, 8.3.32, 8.4.23 oder 8.5.8, fehlt der Patch.php-fpm -v bzw. php-fpm8.x -v.grep -r 'WRAP-PAD' /var/www/. Nur wenn dieser Modus vorkommt, ist Ihre Anwendung aktiv angreifbar.dpkg -l | grep php – ist php8.2 auf Version 8.2.32-1~deb12u1 oder höher?rpm -q php – enthält das Paket den Fix aus RHSA-2026:34164?sudo apt update && sudo apt upgrade php8.2 (bzw. php8.3/php8.4/php8.5). Danach Webserver neu starten: sudo systemctl restart apache2 oder sudo systemctl restart php8.x-fpm.sudo dnf update php, anschließend Webserver neu starten.php:8.3.32, php:8.4.23 oder php:8.5.8 setzen und den Container neu bauen.grep -r 'WRAP-PAD' /var/www/, ob Ihre Anwendung den Modus überhaupt nutzt. Ist das nicht der Fall, ist das Risiko dieser konkreten Lücke gering – das Update bleibt wegen der weiteren Fixes (u. a. CVE-2026-12184, CVSS 8.2) dennoch dringend empfohlen.Für viele Linux-Distributionen sind die Fixes bereits verfügbar: Debian veröffentlichte am 4. Juli 2026 das Advisory DLA-4669-1 (php8.2 in Version 8.2.32-1~deb12u1 für Debian 12 „Bookworm“), Red Hat lieferte am 1. Juli 2026 RHSA-2026:34164.
Auch wenn CVE-2026-14355 primär einen Absturz (DoS) verursacht und kein Datenabfluss dokumentiert ist, ist der DSGVO-Bezug für KMU relevant – vor allem über die Pflicht zu technischen und organisatorischen Maßnahmen nach Art. 32 DSGVO. Website-Betreiber müssen den „Stand der Technik“ einhalten. Das Unterlassen verfügbarer Sicherheitsupdates kann als Verstoß gewertet werden.
Ein Präzedenzfall: Die niedersächsische Datenschutzbehörde verhängte 2021 ein Bußgeld von 65.000 € gegen einen Webshop-Betreiber, der veraltete Shop-Software einsetzte. Der Bußgeldrahmen bei Art.-32-Verstößen reicht bis zu 10 Mio. € oder 2 % des weltweiten Jahresumsatzes. Zur Einordnung: Deutsche Datenschutzbehörden verhängten 2025 mindestens 249 Bußgelder mit einer Gesamtsumme von 46,9 Mio. €.
Eine Meldepflicht nach Art. 33 DSGVO (binnen 72 Stunden) besteht nur dann, wenn die Schwachstelle aktiv ausgenutzt wurde, personenbezogene Daten betroffen sind und ein Risiko für die Rechte und Freiheiten natürlicher Personen nicht ausgeschlossen werden kann. Da CVE-2026-14355 aktuell nicht in freier Wildbahn ausgenutzt wird und primär einen Ausfall verursacht, löst die bloße Existenz der Lücke für die meisten KMU noch keine Meldepflicht aus.
Michael Will, Präsident des Bayerischen Landesamts für Datenschutzaufsicht, formulierte das übertragbare Grundprinzip zu IT-Schwachstellen einmal so:
„Verstöße gegen die Sicherheitsanforderungen der Datenschutz-Grundverordnung können von uns mit empfindlichen Geldbußen geahndet werden. Verantwortliche müssen nun umgehend aktiv werden, um die eigenen Systeme zu prüfen und die Schwachstelle zu beseitigen.“
CVE-2026-14355 ist für sich genommen eine Schwachstelle mit begrenztem Risiko: Sie erfordert eine hohe Angriffskomplexität, betrifft nur Anwendungen mit dem seltenen AES-WRAP-PAD-Modus und wird derzeit nicht ausgenutzt (EPSS 0,25 %). Für die überwiegende Mehrheit der Standard-CMS-Betreiber ist die konkrete Gefahr durch diese eine Lücke gering.
Der eigentliche Handlungsdruck ergibt sich aus dem Gesamtpaket der Sicherheitsreleases: Dieselben Versionen 8.2.32/8.3.32/8.4.23/8.5.8 beheben auch die deutlich gefährlichere Lücke CVE-2026-12184 (CVSS 8.2), die praktisch alle PHP-FPM-Installationen betrifft. Unsere klare Empfehlung lautet daher: Aktualisieren Sie PHP auf die gepatchte Version innerhalb der nächsten 7 bis 14 Tage. Nutzen Sie den AES-WRAP-PAD-Modus tatsächlich, sollten Sie sofort handeln. Dokumentieren Sie das Update – Sie erfüllen damit Ihre Pflichten nach Art. 32 DSGVO und minimieren Ihre Haftungsrisiken.