php2shell: Warum ein WordPress-Update diese PHP-Lücke nicht schließt

Illustration: Person stemmt sich gegen einen Schutzschild mit PHP-Symbol und wehrt Angriffspfeile ab – Symbolbild zur php2shell-Sicherheitslücke

Die PHP-Lücke php2shell betrifft jede Website auf einem Server mit ungepatchtem PHP, auch eine sorgfältig gepflegte WordPress-Seite. Geschlossen ist sie erst in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35, und diese Versionen muss der Betreiber des Servers installieren. Im WordPress-Dashboard gibt es dafür keinen Knopf. Wir zeigen, wie Sie Ihre Version in zwei Minuten prüfen, und fragen offen, warum Warnungen dazu so oft liegen bleiben.

Am 1. Oktober haben wir wieder einmal Kunden angeschrieben, deren Websites noch auf PHP 7 bis PHP 8.2 liefen. Diese Versionen bekommen keine Sicherheitsupdates mehr oder fallen Ende 2026 aus der Pflege. Einen Servicevertrag haben wir mit diesen Kunden nicht. Wir haben uns trotzdem gemeldet, weil uns ihre Seiten seit Langem Bauchschmerzen machen. Die Resonanz lag nahe null.

Am 21. Oktober um 16 Uhr wurde php2shell veröffentlicht, einen Tag früher als geplant, weil Details vorab durchgesickert waren. Seitdem gehören die Seiten aus unserer Mail zu den angreifbaren, solange niemand den Server aktualisiert.

php2shell steckt in PHP selbst, also in der Software auf dem Server, mit der WordPress und Shopware überhaupt erst laufen. Ein Update von WordPress, Plugins oder Theme schließt die Lücke deshalb nicht. Die abgesicherte PHP-Version installiert der Betreiber des Servers, also der Hoster, die eigene IT-Abteilung oder die Agentur bei einem Hosting-Vertrag.

Was über php2shell bisher bekannt ist

php2shell sind zwei kritische Lücken in PHP, über die Angreifer ohne Anmeldung eigenen Code auf einem Webserver ausführen können. Betroffen sind alle Versionen seit PHP 5, und seit der Veröffentlichung am 21. Oktober 2026 laufen weltweit automatisierte Angriffsversuche.

Die erste Lücke (CVE-2026-109618) sitzt in der Speicherverwaltung von PHP, die zweite (CVE-2026-109619) in der Fehlerbehandlung. Beide sind auf der CVSS-Skala mit 9,2 von 10 Punkten als kritisch eingestuft. Ein Angriff klappt selten beim ersten Versuch und braucht einige Tausend bis Zehntausend Anfragen. Für ein automatisiertes Programm ist das wenig: Die Entdecker von Calif zeigen in einem Video, wie sie einen Server mit dem PHP-Framework Laravel nach 38 Sekunden übernehmen.

Angreifbar sind die üblichen Anbindungen von PHP an den Webserver, darunter mod_php für Apache, PHP-FPM und LiteSpeed. Laut Reuters hat Cloudflare Millionen Angriffsversuche gezählt, die schon rund zehn Stunden vor der Veröffentlichung begannen. Amazon spricht von breiter Ausnutzung. Erfolgreiche Einbrüche waren nach dem Stand von heise security am 22. Oktober noch nicht belegt.

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat empfohlen, Websites vorsorglich vom Netz zu nehmen, solange keine aktualisierten PHP-Pakete bereitstehen. Die Charité hat ihre Seiten abgeschaltet, ebenso Behörden in Bayern und Niedersachsen. Die Internetwache der Berliner Polizei war zeitweise nicht erreichbar. So viele vorsorglich abgeschaltete Websites hat es nach Einschätzung von heise security noch nie gegeben.

Welche PHP-Versionen jetzt sicher sind

Abgesichert sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 sowie spätere Versionen derselben Reihe. Für PHP 7.4, 8.0 und 8.1 hat das PHP-Team Nachbesserungen angekündigt, für noch ältere Versionen kommt nichts mehr. heise security rät allen mit älterem PHP, mindestens auf PHP 8.3 umzusteigen.

PHP-ReiheAbgesicherte VersionSicherheitsupdates bis
8.58.5.12Ende 2029
8.48.4.27Ende 2028
8.38.3.36Ende 2027
8.28.2.35Ende 2026
8.1, 8.0 und 7.4angekündigt, Stand 22.10. noch offenPflege bereits beendet
7.3 und älterkeinePflege seit Jahren beendet

Quellen: heise security vom 21. Oktober 2026 für die Versionsnummern, php.net für die Pflegezeiträume.

PHP 8.2 bekommt nur noch gut zwei Monate lang Sicherheitsupdates. Ein Umstieg auf 8.3 oder neuer erspart deshalb im Januar das nächste Problem. Vor dem Wechsel auf eine neue Reihe lohnt ein Test auf einer Kopie der Website, weil ältere Plugins mit neueren PHP-Versionen manchmal Fehler werfen.

Das PHP-Team hat zusätzlich Einstellungen veröffentlicht, die einen Angriff erschweren, und nennt sie selbst eine temporäre Krücke. Cloudflare hat für seine Web Application Firewall Filterregeln eingerichtet, auch für kostenlose Konten, und spricht ebenfalls von einem vorübergehenden Flicken. Vollständig schützt nur das Update.

Warum WordPress das Problem verdeckt

WordPress läuft auch auf PHP-Versionen, die seit Jahren keine Sicherheitsupdates mehr bekommen. Die Seite funktioniert also einwandfrei, und im Alltag merkt niemand, dass der Server darunter veraltet ist. Ein Hinweis erscheint höchstens im Website-Zustand, den im Redaktionsalltag selten jemand öffnet.

Diese Gutmütigkeit hat gute Seiten. Updates von WordPress legen selten eine Website lahm, und auch ältere Installationen laufen stabil weiter. Bei php2shell zeigt sich die Kehrseite: Viele Betreiber wissen nicht, welche PHP-Version ihre Seite nutzt, weil sie nie danach fragen mussten.

Bei vielen unserer Kunden sind wir für die Updates von WordPress, Plugins und Theme zuständig. Diese Seiten sind auf dem neuesten Stand, soweit es WordPress betrifft. Ob der Server darunter ebenso aktuell ist, liegt bei einem Teil dieser Kunden außerhalb unserer Reichweite.

Wer bei Ihrer Website für PHP zuständig ist

Für PHP ist der Betreiber des Servers zuständig. Bei einem Hostingpaket ist das der Hoster, beim eigenen Server die IT-Abteilung und bei einem Hosting-Vertrag die Agentur. Die Pflege von WordPress und die Pflege des Servers liegen deshalb oft in verschiedenen Händen, und zwischen beiden geht leicht etwas verloren.

Viele Firmen geben die Hostingdaten nicht komplett heraus, gerade größere Unternehmen mit eigener IT-Abteilung. Wir bekommen dann Zugriff auf den Webspace, auf dem WordPress oder Shopware laufen, an die PHP-Einstellungen kommen wir aber nicht heran. Das hat oft gute Gründe, und wir respektieren es. Für uns heißt das aber: Wir sehen die veraltete PHP-Version im Website-Zustand und können nur Bescheid sagen.

Der Weg zur neuen PHP-Version ist bei jedem Hoster anders. Manche Hoster spielen PHP-Updates selbst ein. Bei anderen genügt ein Klick im Kundenmenü, und bei einigen muss jemand die neue Version per Mail oder Ticket beantragen. Einige Hoster haben ihre Kunden zu php2shell schon gewarnt, Uberspace hat seine PHP-Dienste am 21. Oktober zeitweise ganz abgeschaltet. Ein Blick auf die Wartungsseite des eigenen Hosters lohnt sich deshalb.

So prüfen Sie Ihre PHP-Version in zwei Minuten

Screenshot aus dem WordPress-Adminbereich mit Position des PHP-Versionshinweises

WordPress zeigt die PHP-Version im Adminbereich unter Werkzeuge > Website-Zustand > Bericht im Abschnitt Server. Bei Shopware und anderen Systemen steht sie in der Verwaltung des Hosters. Eine niedrigere Nummer als die abgesicherte Version derselben Reihe heißt: Ihr Hoster oder Ihre IT muss jetzt handeln.

  1. Öffnen Sie im WordPress-Adminbereich links den Punkt „Werkzeuge“ und wählen Sie „Website-Zustand“.
  2. Klicken Sie oben auf den Reiter „Bericht“.
  3. Klappen Sie den Abschnitt „Server“ auf und lesen Sie die Zeile „PHP-Version“ ab.
  4. Vergleichen Sie die Nummer mit der Tabelle oben.

Was ein Abschalten für Ihre Sichtbarkeit bedeutet

Eine Website im Wartungsmodus zeigt Suchmaschinen und KI-Assistenten keinen Inhalt mehr. ChatGPT, Perplexity und Googles KI-Übersicht greifen dann auf andere Quellen zurück. Eine gekaperte Seite, die Schadcode ausliefert, kann zusätzlich auf Googles Warnliste landen, und Chrome zeigt Besuchern dann eine rote Warnseite statt Ihrer Startseite.

Für die Behörden war Abschalten am 21. Oktober die vernünftige Notlösung, weil es noch keine Pakete gab. Inzwischen liefern Debian, Ubuntu, Red Hat, SUSE und Fedora aktualisierte Pakete aus. Ein Update hält die Seite erreichbar und ist deshalb für die Sichtbarkeit der bessere Weg.

Warum Warnungen ins Leere laufen

Wir wissen es nicht, und deshalb fragen wir hier öffentlich. Ignorieren klingt hart, und wir wollen niemandem Bequemlichkeit unterstellen. Nach mehreren Anläufen mit fast keiner Antwort sind wir als Agentur aber ratlos.

Zwei Erklärungen halten wir für möglich. In einer IT-Abteilung kommen jede Woche Warnungen an, viele davon von Herstellern mit Verkaufsinteresse, und die Mail einer Agentur ohne Servicevertrag liest sich dort vielleicht wie ein weiterer Verkaufsversuch. Oder die Mail erreicht die IT nie, weil sie bei der Person landet, die die Website inhaltlich pflegt, und von dort kein Draht zur Serverbetreuung führt.

Einen Teil der Verantwortung sehen wir bei uns. Die PHP-Version ist ein abstrakter technischer Begriff, und eine Mail voller Versionsnummern sagt Menschen außerhalb der IT wenig.

Deshalb bitten wir alle, die in einer IT-Abteilung arbeiten oder eine leiten, um eine ehrliche Antwort. Warum bleiben solche Hinweise liegen? Und wie müsste eine Warnung aussehen, damit sie bei Ihnen ankommt? Wir lesen jede Antwort, auch eine unbequeme, und richten unsere nächste Warnung danach aus.

Was wir ab jetzt beim Projektstart klären

Ab jetzt sprechen wir die PHP-Version bei jedem neuen Kunden und im Kick-off jedes Projekts an. Dort klären wir, wer den Server betreut und wer bei einer Lücke das PHP-Update beim Hoster auslöst. Damit steht die Zuständigkeit fest, bevor die nächste Warnung kommt.

Diese Lehre nehmen wir aus dem Oktober mit. Bei einer unbeantworteten Warnung sind wir trotzdem machtlos, weil wir keinen Zugriff auf den Server haben und die Entscheidung über ein Update beim Kunden liegt.

Die zweite Mail an dieselben Kunden

In diesen Tagen schreiben wir die Kunden vom 1. Oktober noch einmal an. Diesmal steht die Dringlichkeit schon im Betreff, und die Anleitung zum Prüfen der Version passt in einen Absatz. Ob die Resonanz diesmal höher liegt, ergänzen wir in diesem Beitrag.

Auf Wunsch prüfen wir Ihre PHP-Version und klären mit Ihrem Hoster oder Ihrer IT, wer das Update einspielt. Fragen zu diesem Artikel beantwortet Tobias Herold persönlich, eine kurze Nachricht über das Kontaktformular genügt. Mehr zu unserer WordPress-Pflege steht auf WordPress-Update-Service.


Häufige Fragen zu php2shell

Ist meine WordPress-Seite von php2shell betroffen?
Betroffen ist jede Seite auf einem Server mit ungepatchtem PHP. WordPress selbst ist nicht die Ursache, die Lücke steckt in PHP. Ihre Version finden Sie unter Werkzeuge > Website-Zustand > Bericht > Server.

Reicht ein Update von WordPress oder Shopware?
Ein Update von WordPress, Shopware oder Plugins schließt die Lücke nicht. Die neue PHP-Version muss auf dem Server installiert werden, und das erledigt der Hoster, die IT-Abteilung oder die Agentur mit Hosting-Vertrag.

Auf welche PHP-Version sollte ich jetzt umsteigen?
Steigen Sie mindestens auf PHP 8.3.36 um, weil PHP 8.2 Ende 2026 aus der Pflege fällt. Am längsten Ruhe haben Sie mit PHP 8.5.12. Testen Sie den Wechsel vorher auf einer Kopie der Website, weil ältere Plugins mit neuen PHP-Versionen manchmal Fehler werfen.

Hilft eine Firewall oder Cloudflare gegen php2shell?
Beides hilft nur vorübergehend. Cloudflare hat Filterregeln für alle bekannten Angriffswege eingerichtet, auch für kostenlose Konten, nennt sie aber selbst einen Flicken. Die Einstellungen, die das PHP-Team empfiehlt, sind laut PHP-Team eine temporäre Krücke. Dauerhaft hilft nur die neue PHP-Version.

Betrifft php2shell nur Websites?
Auch Geräte mit PHP in der Weboberfläche sind betroffen, etwa NAS-Systeme von QNAP und Synology oder Firewalls mit pfSense und OPNsense. Docker-Container mit eigener PHP-Version brauchen ebenfalls ein neues Abbild. Interne Anwendungen sind nicht automatisch sicher, weil Angreifer sie nach einem Einbruch ins Netz nutzen können.

Sollte ich meine Website vom Netz nehmen?
Das BSI hat das empfohlen, solange keine aktualisierten Pakete bereitstanden. Inzwischen liefern die großen Linux-Distributionen neue Pakete aus. Ein Update ist deshalb meist der bessere Weg, weil die Seite dabei erreichbar bleibt.


Transparenzhinweis: Für diesen Beitrag haben wir KI zur Recherche und für Rohfassungen einzelner Abschnitte eingesetzt. Fachliche Aussagen, Zahlen und Empfehlungen stammen von uns. Redaktionell geprüft und freigegeben von Tobias Herold. Wie wir KI einsetzen und wann eine Kennzeichnung Pflicht ist, steht auf unserer Seite zur KI-Transparenz.



Das könnte Sie auch interessieren