Am 21. Oktober 2026 hat das PHP-Projekt zwei kritische Sicherheitslücken geschlossen, die unter dem Namen PHP2Shell bekannt geworden sind (CVE-2026-109618 und CVE-2026-109619). Über sie können Angreifer ohne Anmeldung eigenen Code auf einem Webserver ausführen. Betroffen sind praktisch alle PHP-Versionen seit 5.4, und damit auch die meisten WordPress-Seiten. Wenn Sie eine Website mit WordPress, Joomla, Drupal oder einem anderen PHP-System betreiben, sollten Sie heute prüfen, ob Ihr Server schon aktualisiert ist.
Was ist PHP2Shell?
PHP2Shell ist ein Sammelname für zwei Fehler in PHP selbst, also in der Programmiersprache, auf der WordPress läuft. Ein Plugin oder ein Theme ist hier nicht schuld.
- CVE-2026-109618: Wenn PHP beim Annehmen einer Anfrage der Speicher ausgeht, bleiben interne Daten halb fertig zurück. Das anschließende Aufräumen behandelt sie trotzdem als gültig.
- CVE-2026-109619: Daten aus einer Anfrage zeigen nach deren Ende noch auf freigegebenen Speicher. Die nächste Anfrage, die derselbe PHP-Prozess bearbeitet, kann darauf zugreifen.
Das PHP-Projekt bewertet beide Lücken mit 9,2 von 10 Punkten (CVSS 4.0). Laut PHP-Sicherheitsteam ist jede Installation gefährdet, die Webanfragen beantwortet: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Am größten ist das Risiko bei mod_php, weil der Angriff dort greift, bevor überhaupt Code der Website läuft.
Welche PHP-Versionen sind betroffen?
Die Korrekturen stecken in diesen Versionen:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
Für PHP 7.4, 8.0 und 8.1 gibt es keine offiziellen Releases mehr. Das PHP-Team hat wegen der Schwere aber minimale Korrekturen im Quellcode bereitgestellt, und einige Linux-Distributionen liefern eigene Updates. PHP 7.3 und älter bleibt ohne Korrektur.
Wie viele Server betroffen sind, hängt von der Zählweise ab. Ein Sicherheitsforscher schätzt gut 1,3 Millionen erreichbare Server, Palo Alto Networks zählt über 22,6 Millionen Installationen, die möglicherweise verwundbar sind. Laut W3Techs nutzen rund 69 Prozent aller Websites mit bekannter Server-Sprache PHP.
Wird die Lücke schon ausgenutzt?
Die Lage hat sich innerhalb weniger Tage zugespitzt:
- 17. Oktober: Amazon beobachtet in einer Falle für Angreifer (Honeypot) einen ersten Angriffsversuch, vier Tage vor der Veröffentlichung.
- 20. Oktober: Details gelangen vorzeitig in soziale Netzwerke. Das PHP-Projekt zieht die Veröffentlichung um einen Tag vor.
- 21. Oktober: Die Updates erscheinen. Sicherheitsfirmen wie watchTowr und Cloudflare melden erste Angriffe.
- 22. Oktober: Das BSI aktualisiert seine Warnung. Eine erfolgreiche Ausnutzung in der Breite ist dem BSI zu diesem Zeitpunkt nicht bekannt, Amazon spricht dagegen von breiten Angriffen durch mehrere Gruppen.
Das Forschungsteam von Calif, das die Lücken untersucht hat, konnte nach eigenen Angaben bestimmte Versionen von WordPress, Drupal, Joomla und Magento ohne Anmeldung übernehmen. Wir gehen deshalb davon aus, dass ungepatchte Server angegriffen werden.
Was Sie jetzt tun sollten
Wenn Ihre Website bei einem Hoster liegt (Shared Hosting, Managed WordPress): Fragen Sie nach, ob Ihr Server schon auf einer der korrigierten Versionen läuft. Ihre PHP-Version sehen Sie in WordPress unter Werkzeuge → Website-Zustand → Bericht → Server. Steht dort eine Version unter 8.2, sollten Sie auf eine aktuelle Version wechseln. Viele Hoster bieten das im Kundenmenü an.
Wenn Sie einen eigenen Server oder Container betreiben:
- Alle Systeme mit PHP auflisten, zuerst die öffentlich erreichbaren und alle mit mod_php.
- Auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 aktualisieren bzw. das Paket Ihrer Distribution einspielen.
- Alle PHP-Prozesse neu starten. Laufende Prozesse behalten den alten Code im Speicher.
- Prüfen, ob sich seit dem 17. Oktober unbekannte Dateien eingeschlichen haben, etwa PHP-Dateien in Upload- oder Cache-Ordnern.
Wer nicht sofort aktualisieren kann, kann das Risiko vorübergehend senken. Das PHP-Projekt nennt dafür memory_limit = -1, ein niedriges post_max_size und session.upload_progress.enabled = 0, unter PHP 8.5 zusätzlich fatal_error_backtraces = 0. Diese Werte gehören in die php.ini oder den FPM-Pool, nicht in .user.ini. Eine vollständige Absicherung ist das laut PHP-Team nicht, nur das Update schließt die Lücken. Die US-Behörde CISA empfiehlt, Systeme mit PHP 8.1 oder älter vom Netz zu nehmen, wenn sie sich nicht aktualisieren lassen.
Warum WordPress-Seiten besonders oft betroffen sind
PHP2Shell ist für WordPress-Betreiber der dritte Ernstfall in wenigen Monaten:
- Juli 2026, wp2shell: Eine Kette aus zwei Fehlern im WordPress-Kern (CVE-2026-63030 und CVE-2026-60137) erlaubte es, eine Standard-Installation ohne Login und ohne Plugins zu übernehmen. WordPress hat am 17. Juli die Versionen 7.0.2 und 6.9.5 veröffentlicht. Innerhalb eines Tages lagen öffentliche Angriffswerkzeuge auf GitHub, und die CISA meldete aktive Angriffe.
- Oktober 2026, Bricksforge: Eine Lücke in diesem Plugin (CVE-2026-85097) mit der Höchstwertung 10 von 10 erlaubte es, PHP-Code hochzuladen und auszuführen. Sie wurde aktiv ausgenutzt.
- Oktober 2026, PHP2Shell: diesmal eine Ebene tiefer, in PHP selbst.
Der Grund ist der Aufbau. Bei jedem Seitenaufruf führt der Server PHP-Code aus, aus dem Kern, dem Theme und oft aus 20 oder mehr Plugins. Jede dieser Schichten muss aktuell bleiben, und eine einzige veraltete reicht für einen Angriff.
Muss es gleich ein Umzug sein?
Nicht unbedingt. Eine gut gepflegte WordPress-Seite mit aktuellem PHP, wenigen Plugins und jemandem, der Updates zeitnah einspielt, lässt sich sicher betreiben.
Ein Umzug lohnt sich eher, wenn mehrere dieser Punkte zutreffen:
- Ihre Seite zeigt vor allem Inhalte und braucht keine Logins oder Shop-Funktionen.
- Niemand ist wirklich für Updates zuständig, oder sie bleiben wochenlang liegen.
- Sie nutzen viele Plugins, teils ohne zu wissen, wofür.
- Ihr Server läuft noch mit PHP 8.1 oder älter.
Die Alternative ist eine statisch erzeugte Website. Die Seiten werden einmal gebaut und als fertige Dateien ausgeliefert. Auf dem Server läuft bei einem Seitenaufruf kein PHP und keine Datenbank, Lücken wie PHP2Shell oder wp2shell haben dort keinen Angriffspunkt. Inhalte pflegen Sie trotzdem bequem über ein Redaktionssystem. So ist auch diese Website gebaut: mit Astro und dem Redaktionssystem Keystatic, ganz ohne PHP auf dem Server.
Quellen
- PHP-Projekt: Sicherheits-Releases vom 21. Oktober 2026, Advisory CVE-2026-109618, Advisory CVE-2026-109619
- BSI: Cybersicherheitswarnung „PHP: Kritische Schwachstellen bedrohen Webanwendungen weltweit“
- CERT-EU: Security Advisory 2026-018
- Tenable: php2shell FAQ
- watchTowr: PHP2Shell FAQ
- Palo Alto Networks Unit 42: Threat Brief PHP2Shell
- Elastic Security Labs: wp2shell: WordPress RCE
- Security Affairs: wp2shell-Exploits
- The Hacker News: Bricksforge CVSS 10.0
Stand: 23. Oktober 2026. Die Lage entwickelt sich weiter. Maßgeblich sind die Hinweise des PHP-Projekts und des BSI.
