Kritische PHP-Lücke php2shell: Was Unternehmen jetzt tun müssen

Was ist passiert?

Stand dieser Seite: 22.10.2026. Die Updates sind erschienen; Versionen und Betroffenheit stammen aus der offiziellen Sicherheitsmitteilung von php.net.

Das PHP-Team hatte ein Sicherheitsupdate für zwei kritische Lücken angekündigt. Bevor es erschien, sind die Details durchgesickert, und es gab bereits Angriffe.

• 20.10.2026: php.net kündigt ein Sicherheitsrelease für den 21.10.2026 an: zwei kritische Lücken, beide mit CVSS v4.0 9,2 bewertet (php.net).
• 20.10.2026: Die Details sickern vorab durch. Ein Beitrag auf Hacker News wird gelöscht, Screenshots verbreiten sich in sozialen Netzwerken; das Sicherheitsunternehmen watchTowr bestätigt, dass die Lücken echt sind (Huntress).
• 21.10.2026, 09:34 Uhr: Patchstack erhält von mehreren Hosting-Partnern Meldungen über aktive Angriffe (Patchstack).
• 21.10.2026, 09:43 Uhr: Der CTO von Cloudflare meldet auf X erste Angriffe. Cloudflare stellt Schutzregeln für alle Tarife bereit, auch den kostenlosen (Patchstack).
• 21.10.2026: php.net veröffentlicht PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12 und die Sicherheitsmitteilung zu beiden Lücken (php.net).

Was Remote Code Execution bedeutet

Beide Lücken erlauben Remote Code Execution, kurz RCE: Ein Angreifer bringt Ihren Server über das Internet dazu, Code auszuführen, den er selbst mitbringt. Laut den Meldungen des PHP-Teams braucht er dafür keine Anmeldung; der Code läuft mit den Rechten des Webservers (CVE-2026-109618, CVE-2026-109619).

Wer Code auf dem Server ausführt, kann in der Regel alles, was die Website selbst darf: Dateien lesen und ändern, mit den Zugangsdaten aus der Konfiguration auf die Datenbank zugreifen, Kundendaten abziehen oder Schadcode einbauen, der Ihre Besucher angreift.

Technisch geht es um Speicherfehler. Bei CVE-2026-109618 kann PHP mitten in der Vorbereitung einer Anfrage abbrechen, wenn der Speicher ausgeht, und hält beim Aufräumen halb vorbereitete Daten für gültig. Bei CVE-2026-109619 bleiben interne Daten einer Anfrage erhalten, obwohl ihr Speicher schon freigegeben ist; eine spätere Anfrage im selben PHP-Prozess kann sie benutzen (php.net).

Das PHP-Team stuft beide Lücken als kritisch ein, mit 9,2 von 10 Punkten nach CVSS v4.0. Auf X kursierte anfangs eine 10; das ist nicht die offizielle Bewertung.

Wer betroffen ist

Die Lücken stecken in PHP selbst, nicht in einem bestimmten CMS oder Plugin. Laut php.net betreffen sie alle PHP-Installationen, die Webanfragen beantworten: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Am höchsten ist das Risiko bei mod_php (php.net). Der Angriff trifft PHP, bevor der Code von Shop oder CMS überhaupt läuft (Sansec). Betroffen ist also jede Anwendung auf einem nicht aktualisierten PHP:

• Websites mit WordPress, TYPO3, Joomla oder anderen PHP-Systemen
• Onlineshops mit Shopware, Magento oder WooCommerce
• Kundenportale, Intranets, Schnittstellen und selbst entwickelte Anwendungen in PHP
• Testsysteme, Container und alte Unterseiten, die noch erreichbar sind (Patchstack)

Welche PHP-Versionen betroffen sind

Betroffen sind alle Versionen vor PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12 (CVE-2026-109618, CVE-2026-109619). Offiziell gepflegt werden nur die Reihen 8.2 bis 8.5 (php.net). Für PHP 8.1 und älter erscheinen keine neuen Versionen (php.net). Das PHP-Team hat für 7.4, 8.0 und 8.1 nur minimale Korrekturen im Quellcode veröffentlicht, für alle, die PHP selbst kompilieren; manche Linux-Distributionen und LTS-Anbieter liefern Backports (php.net).

Das betrifft viele Websites. PHP läuft laut W3Techs auf 69,3 % aller Websites, deren Serversprache bekannt ist, und 48,5 % der PHP-Websites laufen auf PHP 8.1 oder älter, also auf einer Version ohne neues PHP-Update. Die Anteile je Version haben wir aus den Zahlen von W3Techs vom 21.10.2026 errechnet und gerundet.

Was das Update für Ihre Version bedeutet

Wie viel Arbeit das Update macht, hängt fast nur davon ab, welche PHP-Version Sie heute nutzen. Es gibt drei Fälle: Patch, Upgrade und Migration.

Achtung bei Linux-Paketen: Die Versionsnummer kann gleich bleiben

Linux-Distributionen bauen den Fix oft in ihre eigene PHP-Fassung ein, statt auf die neue Version von php.net zu wechseln. Ubuntu 24.04 zum Beispiel behebt beide Lücken mit dem Paket 8.3.6-0ubuntu0.24.04.13; „php -v“ zeigt danach weiterhin 8.3.6. Entscheidend ist dann die Paketversion, nicht die PHP-Versionsnummer (Ubuntu).

Ubuntu liefert Fixes auch für ältere PHP-Versionen seiner Langzeitfassungen, etwa für PHP 8.1 in Ubuntu 22.04; für noch ältere Fassungen wie Ubuntu 20.04 mit PHP 7.4 nur mit Ubuntu Pro (Ubuntu). Welche Paketversion bei Ihnen den Fix enthält, steht in der Sicherheitsmeldung Ihrer Distribution.

Sofortplan in vier Schritten

1. 1PHP-Version feststellen, überall. Die Version steht in der Verwaltung Ihres Hosters, bei WordPress unter Werkzeuge, Website-Zustand, Reiter Bericht, Abschnitt Server. Den ganzen Bericht wertet unser kostenloses Werkzeug WordPress-Zustand prüfen aus. Auf dem Server zeigt „php -v“ nur die Version der Kommandozeile; die Website kann eine andere nutzen. Denken Sie an Testsysteme, Container und alte Unterseiten (Patchstack).
2. 2Update einspielen und PHP neu starten. Die Fix-Versionen sind PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12 (php.net); bei Paketen Ihrer Linux-Distribution ist es deren aktuelles Sicherheitsupdate. Starten Sie danach PHP-FPM oder den Webserver neu, damit keine alten PHP-Prozesse weiterlaufen. Bei gemietetem Webspace fragen Sie Ihren Hoster, ob er das Update schon eingespielt hat. Verzichten Sie auf inoffizielle „Fix“-Plugins und kopierte Code-Schnipsel (Patchstack).
3. 3Ältere Versionen abschirmen und das Upgrade starten. Für 8.1 und älter gibt es keine neue PHP-Version. Fragen Sie Ihren Hoster oder den Anbieter Ihres Betriebssystems nach einem Backport (php.net). Besonders gefährdete Websites, die Sie nicht sofort absichern können, versetzen Sie in den Wartungsmodus oder nehmen sie vom Netz (Patchstack). Parallel planen Sie das Upgrade oder die Migration.
4. 4Nach Spuren suchen. Prüfen Sie nach dem Update, ob schon jemand eingedrungen ist, und zwar rückwirkend mindestens bis Juni 2026 (Aikido). Ein Update schließt die Lücke, entfernt aber nichts, was ein Angreifer schon eingebaut hat. Woran Sie das erkennen, steht unten.

Was nicht reicht

• Nur PHP-Einstellungen ändern: php.net nennt Notmaßnahmen, etwa session.upload_progress.enabled=0 oder ein kleineres post_max_size, sagt aber ausdrücklich, dass sie eine Installation nicht sicher machen. Vollständig hilft nur das Update (php.net).
• Cloudflare-Regeln: Cloudflare hat Regeln gegen die bekannten Angriffswege bereitgestellt. Sie helfen nur, wenn Ihr Server ausschließlich Anfragen über Cloudflare annimmt (Patchstack), und ersetzen das Update nicht.
• CMS- oder Plugin-Update: Ein Update von WordPress, Shopware, TYPO3 oder Magento ändert nichts an PHP. Die Lücke bleibt, bis PHP selbst aktualisiert ist.
• Update ohne Neustart: PHP-Prozesse, die schon laufen, arbeiten mit dem alten Code weiter, bis sie neu gestartet werden.

Warnzeichen eines Angriffs

Huntress beschreibt, woran sich ein erfolgreicher Angriff am ehesten zeigt (Huntress). Ihr Hoster oder Ihre IT kann das in den Prozess- und Dateiprotokollen prüfen:

• PHP-Prozesse wie php-fpm, php-cgi, httpd oder apache2 starten eine Shell, einen Interpreter oder Download- und Netzwerkwerkzeuge.
• In Befehlszeilen tauchen Muster für Fernzugriffe auf, etwa /dev/tcp/, fsockopen oder mkfifo.
• Im Webverzeichnis liegen neue, unbekannte Dateien, zum Beispiel sogenannte Webshells.
• Es gibt neue Cronjobs, geplante Aufgaben oder Benutzerkonten, die niemand angelegt hat.

Hilfe bei Update und Migration

Sie wissen nicht, welche PHP-Version Ihre Website nutzt, oder Ihre Version bekommt keinen offiziellen Fix mehr? Schreiben Sie uns über das Kontaktformular, an info@schwerpunkt.tech oder rufen Sie an: +49 177 2336479. Wir prüfen kurzfristig, wo Sie stehen.

Danach spielen wir den Patch ein, bringen Ihre Anwendung innerhalb von PHP 8 auf eine gepflegte Version oder migrieren sie von PHP 7 und älter, jeweils erst auf einer Kopie getestet. Nach dem Erstgespräch nennen wir einen Festpreis je Etappe, bevor wir anfangen. Auf Wunsch übernehmen wir danach die Website-Pflege mit regelmäßigen Updates, bei eigenen Anwendungen Betrieb und Wartung. Läuft Ihre Website auf PHP 8.1 oder älter, verlangt Ihr Hoster dafür womöglich schon eine Gebühr; dazu der Ratgeber PHP Extended Support.

Quellen

Alle Quellen abgerufen am 21. und 22.10.2026.

• php.net: Sicherheitsmitteilung vom 21.10.2026 und Ankündigung vom 20.10.2026
• PHP-Team auf GitHub: CVE-2026-109618 und CVE-2026-109619
• Ubuntu: CVE-2026-109618
• php.net: gepflegte Versionen und eingestellte Versionen
• watchTowr: FAQ zu CVE-2026-109618
• Sansec: php2shell
• Huntress: php2shell, durchgesickerte kritische PHP-Lücken
• Patchstack: Warnung zu den PHP-Lücken, Oktober 2026
• Aikido: kritische Lücken in PHP (php2shell)
• W3Techs: Verbreitung von PHP und PHP-Versionen