PHP2Shell: Kritische Lücke in PHP – was jetzt zu tun ist

Stand: 22. Oktober 2026, 9:45 Uhr. Seit der Nacht stellt CloudLinux korrigierte Pakete für alle PHP-Versionen von 5.2 bis 8.5 bereit (alt-php und ea-php, laut Statusseite). Auf den Servern meiner Hosting-Kunden ist die Lücke geschlossen, Details im Kasten „Für meine Hosting-Kunden“. Ich ergänze diesen Beitrag, sobald es neue gesicherte Informationen gibt.

Was ist passiert?

Am 20. Oktober 2026 kündigte das PHP-Team ein Notfall-Update für zwei kritische Sicherheitslücken an. Eigentlich sollten die Details erst zwei Tage später veröffentlicht werden, doch Informationen waren vorab durchgesickert, und ein Video zeigte bereits die Angriffskette. In Anlehnung an die Lücke Log4Shell von 2021 bekam das Ganze schnell einen Namen: PHP2Shell.

Am 21. Oktober gegen 16 Uhr deutscher Zeit erschienen die korrigierten PHP-Versionen. Schon am Morgen hatte Cloudflare erste Angriffe gemeldet, und Hoster berichteten von Angriffsversuchen. Mit dem Update wurden auch die technischen Details öffentlich: Die Forscher, die die Lücken entdeckt hatten, haben Angriffe ohne Anmeldung unter anderem gegen aktuelle Versionen von WordPress, Drupal, Joomla, Nextcloud und Magento nachgewiesen. Das BSI stufte die Lage mit der zweithöchsten Warnstufe „3 / Orange“ ein und hält eine breite Ausnutzung innerhalb weniger Stunden nach Erscheinen der Updates für wahrscheinlich. Behörden und öffentliche Einrichtungen nehmen ihre Websites vorsorglich vom Netz, in den Niederlanden etwa das staatliche Login DigiD, das Bürgerportal MijnOverheid, die Website des Parlaments und die des nationalen Cyber-Sicherheitszentrums.

Der Grund für die Aufregung: PHP ist die Grundlage eines großen Teils des Internets. Laut W3Techs läuft es auf 69,3 % der Websites, deren Server-Sprache sich erkennen lässt – darunter alle Websites mit WordPress, TYPO3, Joomla, Shopware oder Magento.

Warum diese Lücke anders ist

Die meisten Sicherheitslücken, über die ich hier schreibe, stecken in WordPress-Plugins oder Themes. Dann heißt die Lösung: Plugin aktualisieren. PHP2Shell steckt dagegen in PHP selbst, also in der Sprache, in der WordPress und die meisten anderen Systeme geschrieben sind. Der Angriff greift in dem Moment, in dem PHP eine Anfrage entgegennimmt – noch bevor WordPress geladen wird.

Daraus folgt:

• Kein Sicherheits-Plugin hilft. Es kommt gar nicht erst zum Zug.
• Auch der Wartungsmodus von WordPress hilft nicht. PHP verarbeitet die Anfrage, bevor WordPress prüft, ob der Wartungsmodus an ist.
• Es spielt keine Rolle, wie gut Ihre Website gepflegt ist. Eine top aktuelle WordPress-Installation ist genauso betroffen wie eine veraltete.

Schützen kann nur, wer PHP auf dem Server betreibt: mit dem Update – und bis dahin mit Einstellungen auf Server-Ebene.

Gelingt ein Angriff, läuft der Code des Angreifers mit den Rechten des Webservers. Er kann dann alles, was Ihre Website auch kann: die Zugangsdaten zur Datenbank aus der Konfiguration lesen, Kundendaten abgreifen, Dateien verändern, Hintertüren einbauen oder Ihren Webspace für Spam und Angriffe auf andere missbrauchen. Außerdem lassen sich über die Lücken Teile des Arbeitsspeichers von PHP auslesen, auch ohne dass fremder Code läuft. Darin können Passwörter, Sitzungsdaten und API-Schlüssel aus anderen Anfragen stehen.

Die beiden Lücken im Überblick

Am höchsten ist das Risiko laut PHP-Team bei Apache mit mod_php: Dort wurde gezeigt, dass eine einzige Anfrage ohne Anmeldung den Angriff auslösen kann, bevor irgendein Code der Website läuft. Bei PHP-FPM, LiteSpeed und anderen Varianten sind Angriffe schwieriger, aber nicht ausgeschlossen – einer der beiden Angriffswege wurde auch gegen PHP-FPM nachgewiesen.

Welche PHP-Versionen betroffen sind

Ältere Versionen gelten nach den bisherigen Berichten mindestens ab PHP 5.4 als verwundbar. Für PHP 7.4, 8.0 und 8.1 hat das PHP-Team wegen der Schwere der Lücken ausnahmsweise minimale Korrekturen als Quelltext bereitgestellt – für alle, die PHP selbst bauen. Eine fertige, abgesicherte Version gibt es dafür nur von Linux-Distributionen, Hostern und Anbietern mit Langzeit-Support.

Wichtig: Distributionen wie Debian, Ubuntu oder Red Hat und viele Hoster bauen Korrekturen in ihre bestehenden Pakete ein, ohne die Versionsnummer auf den neuen Stand zu heben. Eine Nummer wie „8.2.28“ kann dann abgesichert sein – oder eben nicht. Maßgeblich ist der Sicherheitshinweis Ihres Anbieters.

Shared Hosting: Was Sie jetzt tun sollten

Die meisten Websites kleiner Unternehmen liegen im Shared Hosting: Viele Kunden teilen sich einen Server, den der Hoster verwaltet. PHP können Sie dort nicht selbst aktualisieren – das muss Ihr Hoster tun. Ihre Aufgaben sind trotzdem wichtig:

1. Beim Hoster nachfragen

   Prüfen Sie die Statusseite oder den Blog Ihres Hosters, oder fragen Sie direkt: Ist PHP auf allen Servern aktualisiert, auch in der Version, die meine Website nutzt? Welche Übergangsmaßnahmen gelten bis dahin?

2. Schutzmaßnahmen nicht aushebeln

   Einige Hoster haben den Upload-Fortschritt von PHP (session.upload_progress) zentral abgeschaltet. Schalten Sie ihn nicht über eine eigene .user.ini oder php.ini in Ihrem Webspace wieder ein. Uploads funktionieren weiterhin, nur die PHP-eigene Fortschrittsanzeige fällt weg – und die nutzen WordPress, TYPO3 und Co. ohnehin nicht. Sperrt Ihr Hoster bis zum Update vorübergehend auch Datei-Uploads über die Website, laden Sie Dateien so lange per SFTP oder über den Dateimanager hoch.

3. Auf eine unterstützte PHP-Version wechseln

   Läuft Ihre Website noch mit PHP 8.1 oder älter, ist sie nur geschützt, wenn Ihr Hoster die Korrektur selbst nachrüstet. Wechseln Sie im Kundenmenü auf PHP 8.3 oder 8.4 – vorher mit Backup und am besten zuerst auf einer Testkopie. PHP 8.2 bekommt nur noch bis Jahresende Sicherheitsupdates.

4. Ein sauberes Backup sichern

   Laden Sie jetzt eine vollständige Sicherung (Dateien und Datenbank) herunter, die vor dem 20. Oktober entstanden ist. Viele Hoster bewahren Backups nur 14 oder 30 Tage auf. Sollte sich später zeigen, dass Ihre Website angegriffen wurde, brauchen Sie einen Stand von vor dem Angriff.

5. Die Website in den nächsten Tagen beobachten

   Wie das geht, steht weiter unten.

Ihr WordPress, die Plugins und Themes aktualisieren Sie natürlich weiterhin wie gewohnt. Gegen PHP2Shell selbst hilft das aber nicht.

Eigene Server: Was Betreiber jetzt tun müssen

Betreiben Sie einen eigenen Server, einen VPS oder Container mit PHP, liegt die Verantwortung bei Ihnen. Und die Zeit drängt.

1. Alle PHP-Installationen finden

Denken Sie nicht nur an den Webserver der Hauptwebsite. PHP steckt auch in Testumgebungen, Containern, internen Werkzeugen und in Geräten und Produkten wie Nextcloud, pfSense oder OPNsense. Das niederländische Cyber-Sicherheitszentrum führt eine Liste von Produkten mit PHP, die betroffen sein können.

2. PHP aktualisieren – und alle PHP-Prozesse neu starten

Spielen Sie die Updates Ihrer Distribution ein und gleichen Sie die Paketversion mit deren Sicherheitshinweis ab (etwa beim Debian Security Tracker oder der Ubuntu-CVE-Seite). Entscheidend ist der Neustart: Laufende PHP-Prozesse behalten den alten, verwundbaren Code im Speicher, bis sie neu starten.

# Debian / Ubuntu
sudo apt update && sudo apt upgrade
# PHP-FPM neu starten (Versionsnummer anpassen)
sudo systemctl restart php8.3-fpm
# bei Apache mit mod_php
sudo systemctl restart apache2

# Red Hat, AlmaLinux, Rocky Linux
sudo dnf upgrade 'php*'
sudo systemctl restart php-fpm httpd

Drei Sonderfälle:

• Remi-Repository: Wer PHP aus dem ehrenamtlich gepflegten Repository rpms.remirepo.net bezieht, bekam laut PHP-Team am 21. Oktober noch keine Updates. Das PHP-Team rät, auf die Pakete der Distribution umzusteigen oder PHP selbst zu bauen.
• Container: Images mit PHP müssen mit aktuellem Basis-Image neu gebaut und neu ausgerollt werden (docker build --pull …).
• Selbst gebaut: Die Quelltexte von PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 stehen auf php.net, die Korrekturen für 7.4, 8.0 und 8.1 verlinkt der Sicherheitshinweis des PHP-Teams.

3. Prüfen, ob das Update wirklich greift

php -v zeigt nur das PHP der Kommandozeile. Ihr Webserver kann ein anderes nutzen. Prüfen Sie deshalb die installierten Pakete:

# Debian / Ubuntu
dpkg -l 'php*' | grep ^ii

# Red Hat, AlmaLinux, Rocky Linux
rpm -qa 'php*'

Welche PHP-Version eine WordPress-Website tatsächlich nutzt, steht im Backend unter „Werkzeuge → Website-Zustand → Bericht → Server“.

4. Wenn Sie nicht sofort aktualisieren können

Das PHP-Team nennt Übergangsmaßnahmen. Sie verringern das Risiko für bestimmte Angriffswege, machen eine Installation aber nicht sicher. Setzen Sie die Werte in der php.ini, in conf.d oder in der FPM-Pool-Konfiguration – nicht per ini_set() oder .user.ini, denn die greifen zu spät – und starten Sie danach alle PHP-Prozesse neu.

; php.ini oder conf.d
session.upload_progress.enabled = 0
; 32M, wenn Uploads nötig sind
post_max_size = 8M
; immer kleiner als post_max_size
upload_max_filesize = 6M
; nur PHP 8.5
fatal_error_backtraces = 0

; oder im FPM-Pool, z. B. in
; /etc/php/8.3/fpm/pool.d/www.conf
php_admin_flag[session.upload_progress.enabled] = off

Außerdem empfiehlt das PHP-Team, memory_limit gegen die erste Lücke administrativ auf -1 zu setzen. Das nimmt dem Angreifer die berechenbare Speichergrenze, öffnet aber eine andere Tür: Eine einzelne Anfrage kann dann den ganzen Speicher belegen. Setzen Sie das nur zusammen mit einer Speichergrenze für den Dienst oder Container (cgroup), und nutzen Sie dafür keine ulimit-Grenzen wie RLIMIT_AS – die lösen genau den verwundbaren Pfad aus.

Wo keine Datei-Uploads nötig sind, können Sie Multipart-Anfragen schon im Webserver abweisen. Das bricht allerdings jeden Upload und manche Formulare – testen Sie danach Mediathek, Kontaktformulare mit Anhang und Kasse.

# nginx: in jedem server-Block, der an PHP weitergibt
if ($http_content_type ~* "multipart") {
    return 403;
}

# Apache: in jedem VirtualHost mit PHP
RewriteEngine On
RewriteCond %{HTTP:Content-Type} multipart [NC]
RewriteRule ^ - [F]

Eine Web Application Firewall vor dem Server kann bekannte Angriffsmuster abfangen. Cloudflare hat dafür Regeln für alle Kunden ausgerollt, auch im kostenlosen Tarif. Das hilft aber nur, wenn Ihr Server ausschließlich Anfragen von Cloudflare annimmt – sonst umgehen Angreifer den Schutz über die IP-Adresse des Servers.

Bleibt als letzter Ausweg: den Server vom Netz nehmen, bis das Update eingespielt ist. Das empfehlen BSI, CERT-EU und das britische NCSC ausdrücklich, wenn sich nicht schnell aktualisieren lässt.

5. Danach: die Lehren daraus

• mod_php ablösen. Das Risiko ist laut PHP-Team bei Apache mit mod_php am höchsten. Wer es noch nutzt, sollte auf PHP-FPM umstellen.
• Upload-Fortschritt aus lassen. Das PHP-Team hält es für klug, session.upload_progress auch nach dem Update abgeschaltet zu lassen, wenn man es nicht braucht – Angreifer werden diese selten genutzte Funktion jetzt genau untersuchen.
• Auf unterstützte Versionen gehen. PHP 8.2 endet am 31. Dezember 2026. Planen Sie den Wechsel auf 8.3 oder 8.4 jetzt.
• Den Ernstfall regeln. Wer spielt bei Ihnen ein kritisches Update innerhalb von Stunden ein – auch am Wochenende? Diese Frage sollte vor der nächsten Lücke beantwortet sein.

Wie Sie prüfen, ob Sie schon angegriffen wurden

Vorweg ehrlich: Bestätigte Erkennungsmerkmale für PHP2Shell gibt es nach Angaben des BSI noch nicht (Stand: 21. Oktober). Im Internet kursierende Listen sind ungeprüft. Und das PHP-Team betont: Fehlen verdächtige Einträge in den Protokollen, ist das kein Beweis, dass nichts passiert ist.

Prüfen lässt sich aber, was ein erfolgreicher Angreifer typischerweise hinterlässt: neue oder veränderte Dateien, neue Benutzer, geplante Aufgaben, Spam und Weiterleitungen. Schauen Sie dabei auf alles, was seit dem 20. Oktober 2026 passiert ist.

Im Shared Hosting (ohne Server-Zugang)

Auf eigenen Servern

Mit Zugang zur Kommandozeile können Sie gründlicher suchen. Die Pfade sind Beispiele für Debian und Ubuntu (Webserver-Benutzer www-data); unter Red Hat und Co. heißen sie etwa /var/log/httpd und apache.

# PHP-Dateien, seit dem 20. Oktober neu angelegt oder verändert.
# -newerct nutzt die Änderungszeit des Dateisystems, die ein Angreifer
# nicht einfach zurückdatieren kann (anders als das sichtbare Datum).
sudo find /var/www -type f -name '*.php*' -newerct '2026-10-20' -ls

# PHP-Dateien in Upload-Ordnern – dort gehören keine hin
sudo find /var/www -type f -path '*/uploads/*' -name '*.php*' -ls

# Prozesse, Cronjobs und Dateien des Webserver-Benutzers
ps -u www-data -o pid,lstart,cmd
sudo crontab -l -u www-data
sudo find /tmp /var/tmp /dev/shm -user www-data -type f -ls

# Offene Netzwerkverbindungen von PHP und Webserver
sudo ss -tpn | grep -E 'php|apache|httpd|nginx'

In den Protokollen sind diese Einträge Hinweise auf Angriffsversuche – nicht auf einen erfolgreichen Einbruch, aber ein Grund, genauer hinzusehen. Das PHP-Team nennt Speicherfehler, schwere PHP-Fehler und Zeitüberschreitungen, besonders wenn sie gehäuft vor dem eigentlichen Skript auftreten. Abgestürzte PHP-Prozesse passen ebenfalls ins Bild, denn ein fehlgeschlagener Angriff auf eine Speicherlücke bringt den Prozess oft zum Absturz.

# Abgestürzte PHP- und Apache-Prozesse
sudo grep -E 'Segmentation fault|SIGSEGV' /var/log/apache2/error.log* /var/log/php*-fpm.log*

# Speicherfehler, schwere Fehler und Zeitüberschreitungen
sudo grep -E 'Allowed memory size|PHP Fatal error|Maximum execution time' /var/log/apache2/error.log* /var/log/php*-fpm.log*

# POST-Anfragen je Absender, Adresse und Status
sudo awk '$6 == "\"POST"' /var/log/apache2/access.log | awk '{print $1, $7, $9}' | sort | uniq -c | sort -rn | head -30

Finden Sie solche Spuren, behandeln Sie den Server als möglicherweise kompromittiert und ändern Sie vorsorglich die Zugangsdaten, die dort hinterlegt sind, etwa für Datenbank, Schnittstellen und Zahlungsanbieter. Denn über die Lücken lässt sich auch Arbeitsspeicher auslesen, ohne dass dabei Dateien verändert werden.

Für WordPress-Websites lohnt zusätzlich ein Abgleich mit den Originaldateien über WP-CLI:

# WordPress-Kern unverändert?
wp core verify-checksums

# Plugins aus wordpress.org unverändert?
wp plugin verify-checksums --all

# Alle Administratoren bekannt?
wp user list --role=administrator

Die Prüfsummen decken nur Dateien ab, die es auf wordpress.org gibt. Kaufplugins, Ihr Theme, die Uploads und die wp-config.php müssen Sie selbst ansehen.

Wenn Sie etwas finden

1. Nichts überstürzt löschen

   Sichern Sie zuerst Protokolle und verdächtige Dateien. Sie zeigen, was passiert ist und seit wann.

2. Die Website vom Netz nehmen

   Oder lassen Sie sie durch eine statische Wartungsseite ersetzen. Im Shared Hosting hilft Ihnen dabei der Hoster.

3. Erst PHP absichern, dann aufräumen

   Sonst kommt der Angreifer sofort wieder herein.

4. Ein Backup von vor dem Angriff einspielen

   Im Zweifel von vor dem 20. Oktober. Nur Schadcode zu entfernen ist riskant, weil Hintertüren leicht übersehen werden.

5. Alle Zugangsdaten ändern

   Hosting-Konto, SFTP, Datenbank, alle WordPress-Administratoren, API-Schlüssel in der Konfiguration. Bei WordPress außerdem die Sicherheitsschlüssel („Salts“) in der wp-config.php neu erzeugen.

6. Datenschutz prüfen

   Konnten personenbezogene Daten abfließen, etwa Kundenkonten oder Bestellungen, müssen Sie das in der Regel innerhalb von 72 Stunden der Datenschutz-Aufsichtsbehörde melden (Art. 33 DSGVO), unter Umständen auch die Betroffenen informieren.

7. Hilfe holen, wenn Sie unsicher sind

   Ein unvollständig bereinigter Server ist gefährlicher als einer, von dem man weiß, dass er kompromittiert ist.

Fazit

PHP2Shell gehört zu den schwersten PHP-Lücken der letzten Jahre, weil sie fast jede PHP-Website trifft – egal, welches System darauf läuft und wie gut es gepflegt ist. Die gute Nachricht: Die Korrektur ist da. Im Shared Hosting kümmert sich Ihr Hoster darum, auf eigenen Servern müssen Sie jetzt schnell handeln. Für alle gilt: Schutzmaßnahmen nicht aushebeln, ein sauberes Backup von vor dem 20. Oktober sichern und die Website in den nächsten Tagen im Blick behalten.

Wie ich grundsätzlich mit kritischen Lücken umgehe, habe ich im Beitrag Kritische Sicherheitslücken erkennen und zeitnah beheben beschrieben. Was eine laufende Betreuung sonst noch umfasst, steht im Beitrag zum WordPress-Wartungsvertrag.

Quellen: Sicherheitshinweis des PHP-Teams · CVE-2026-109618 (GitHub) · CVE-2026-109619 (GitHub) · BSI-Warnung · CERT-EU · NCSC UK · Sansec · Patchstack (alle abgerufen am 21. Oktober 2026)