Am 21. Oktober 2026 hat das PHP-Team zwei kritische Sicherheitslücken mit einem Notfall-Update geschlossen. Unter dem Namen PHP2Shell haben sie es bis in die Hauptnachrichten geschafft. Das BSI hat gewarnt, die Stadt Mainz hat ihr Webportal vorsichtshalber abgeschaltet. Der Fehler sitzt im PHP-Interpreter, also in dem Programm auf dem Server, das jede WordPress-Seite ausführt. Ein aktuelles WordPress schützt deshalb nicht davor.
Dieser Beitrag erklärt, was hinter den Lücken steckt, wie gefährlich sie für eine Firmenwebsite sind und was Sie jetzt prüfen sollten. Er richtet sich an Geschäftsführung und Marketingverantwortliche ohne IT-Hintergrund. Für Administratoren stehen die technischen Übergangsmaßnahmen in einem eigenen Abschnitt.
Das Wichtigste in Kürze
- Zwei Lücken, beide mit 9,2 von 10 Punkten bewertet: CVE-2026-109618 und CVE-2026-109619. Im schlimmsten Fall führt ein Angreifer über das Internet eigenen Code auf dem Webserver aus, ohne ein Passwort zu kennen. Damit kann er die Website verändern, Daten aus der Datenbank mitnehmen und den Server für eigene Zwecke nutzen.
- Betroffen ist PHP selbst. Nach Angaben des BSI sind alle bekannten Versionen verwundbar, mindestens zurück bis PHP 5. Eine sauber gepflegte WordPress-Installation ist angreifbar, solange PHP auf dem Server nicht aktualisiert ist.
- Korrekturen gibt es für PHP 8.2 bis 8.5. Für PHP 8.1 und älter veröffentlicht das PHP-Projekt keine Updates mehr.
- Ein WordPress- oder Plugin-Update aktualisiert PHP nicht. Das erledigt der Hoster oder wer den Server betreibt.
- Erste Angriffsversuche wurden am 21. Oktober beobachtet, unter anderem von Cloudflare und watchTowr. Eine bestätigte Massenausnutzung gab es zu diesem Zeitpunkt noch nicht.
- Die Lösung ist das Update. Übergangsmaßnahmen senken das Risiko, ersetzen das Update nach Aussage des PHP-Teams aber nicht.
Ist Ihre Website betroffen?
Geben Sie Ihre Domain ein. Wir lesen die PHP-Version aus, die Ihr Server öffentlich meldet, und ordnen sie ein.
Gut zu wissen: Die meisten Websites halten ihre PHP-Version aus Sicherheitsgründen verborgen. Dann kann sie niemand von außen auslesen, auch dieser Prüfer nicht. In dem Fall bekommen Sie eine kurze Anleitung, mit der Sie die Version in zwei Minuten selbst finden und hier eintragen.
Die Einordnung beruht allein auf der Versionsnummer, die Ihr Server meldet oder die Sie eingeben. Sie ersetzt keine Prüfung des Servers. Die Domain halten wir zehn Minuten im Zwischenspeicher, um doppelte Abfragen zu vermeiden, und werten sie nicht aus.
So gehen Sie vor
Wenn Sie wenig Zeit haben, arbeiten Sie diese fünf Schritte ab. Der Rest des Beitrags erklärt, warum sie so aussehen.
- PHP-Version prüfen. Mit dem Prüfer oben oder selbst in WordPress unter Werkzeuge → Website-Zustand → Bericht, Abschnitt „Server”. Dort steht die Versionsnummer, zum Beispiel 8.3.36.
- Mit der Tabelle unten abgleichen. Ab 8.2.35, 8.3.36, 8.4.27 oder 8.5.12 ist die Korrektur enthalten. Der Prüfer erledigt diesen Abgleich für Sie.
- Beim Hoster nachfragen, wenn die Nummer niedriger ist. Fragen Sie, ob die Korrektur installiert ist und nicht nur eingeplant. Einige Linux-Distributionen bauen Korrekturen in ältere Versionsnummern ein. Im Zweifel zählt deshalb die Auskunft des Hosters.
- Bei PHP 8.1 oder älter die Umstellung planen. Für diese Versionen gibt es keine offizielle Korrektur. PHP 8.2 erhält ab dem 1. Januar 2027 ebenfalls keine Sicherheitsupdates mehr. Wer jetzt umstellt, wählt deshalb 8.3 oder neuer und testet die Website vorher auf einer Kopie.
- Nach Spuren eines Angriffs sehen lassen. Das BSI empfiehlt, PHP-Webserver genau auf ungewöhnliche Aktivitäten zu beobachten. Das übernimmt Ihr Hoster oder der Dienstleister, der Ihre Website wartet.
Hinweis für Technikinteressierte: Bei großen Lücken tauchen im Netz regelmäßig angebliche Angriffswerkzeuge auf, die in Wahrheit den Rechner dessen infizieren, der sie startet. Solchen Code nur lesen oder in einer abgeschotteten virtuellen Maschine ausführen.
Was ist PHP, und warum betrifft das Ihre Website?
PHP ist die Programmiersprache, in der WordPress geschrieben ist. Auch Joomla, Drupal, TYPO3 und Moodle laufen damit. Ruft jemand eine Seite Ihrer Website auf, startet auf dem Server ein PHP-Prozess. Er holt die Inhalte aus der Datenbank und baut daraus die Seite.
WordPress selbst, das Theme und die Plugins sind Dateien in Ihrem Webspace. Die aktualisieren Sie oder Ihre Agentur im WordPress-Backend. PHP dagegen ist ein Programm auf dem Server, und das pflegt der Hoster. Ein Update im WordPress-Backend ändert bei dieser Lücke deshalb nichts.
Auf Webservern läuft PHP meist in einer von zwei Varianten:
- mod_php: PHP ist als Modul direkt in den Webserver Apache eingebaut.
- PHP-FPM: PHP läuft als eigener Dienst mit mehreren Prozessen, der Webserver reicht die Anfragen dorthin weiter.
In beiden Fällen werden die PHP-Prozesse wiederverwendet. Ein Prozess bearbeitet eine Anfrage, räumt auf und nimmt die nächste an. Für jede Anfrage bekommt er einen eigenen Speicherbereich, der am Ende freigegeben wird. Das ist sicher, solange danach nichts mehr auf den freigegebenen Speicher verweist. Beide Lücken nutzen Fälle, in denen ein solcher Verweis übrig bleibt.
Wie die Lücken funktionieren
Jede Anfrage durchläuft in PHP drei Phasen. Beim Start liest PHP die Daten der Anfrage ein, zum Beispiel ein ausgefülltes Formular oder einen Dateiupload. Danach läuft das Programm selbst, bei Ihnen also WordPress. Zum Schluss räumt PHP auf.
Pro Anfrage darf PHP nur eine begrenzte Menge Arbeitsspeicher belegen, in der Grundeinstellung 128 Megabyte. Wurde das Limit überschritten, hat PHP bisher keinen sauberen Fehler gemeldet. Es ist sofort aus der laufenden Funktion herausgesprungen, mitten in der Arbeit. Hatte die Funktion zum Beispiel schon vermerkt, dass es einen neuen Eintrag gibt, ihn aber noch nicht befüllt, blieb dieser halbfertige Zustand im Speicher zurück. PHP hat später damit weitergearbeitet, als wäre alles in Ordnung.
Lücke 1 (CVE-2026-109618)
Wenn PHP einen Eintrag in eine interne Liste schreibt, erhöht es zuerst den Zähler und reserviert danach den Speicher für den Namen des Eintrags. Reißt genau diese Reservierung das Limit, bricht PHP ab. Der Zähler meldet einen Eintrag mehr, der aber nie befüllt wurde. Beim Aufräumen geht PHP alle gezählten Einträge durch und verarbeitet auch den leeren, in dem noch alte Daten liegen. Wer diese Daten kontrolliert, bestimmt, was PHP damit tut.
Dafür muss der Angreifer das Limit an exakt dieser Stelle überschreiten, obwohl Uploads in der Grundeinstellung auf 8 Megabyte begrenzt sind. Laut den Entdeckern gelingt das zum Beispiel mit Dateifeldern ohne Dateinamen. Sie zählen nicht als Upload, PHP legt für jedes trotzdem mehrere Verwaltungseinträge an. Mit verschachtelten Feldnamen wächst dieser Aufwand stark. Eine Anfrage unter 8 Megabyte belegt so mehr als 128 Megabyte Speicher.
Lücke 2 (CVE-2026-109619)
PHP hat Verweise, die zwischen zwei Anfragen erhalten bleiben, während einer Anfrage aber auf deren Speicher zeigen. Am Ende jeder Anfrage müssen sie zurückgesetzt werden. Bricht ein Fehler die Anfrage vorher ab, bleibt der Verweis stehen und zeigt auf bereits freigegebenen Speicher. Greift die nächste Anfrage im selben Prozess darauf zu, verarbeitet PHP fremde Daten, als wären es seine eigenen. Fachleute nennen das „Use after free”.
Der Einstieg ist eine wenig bekannte Funktion namens Session Upload Progress. Sie ist für Fortschrittsbalken bei Uploads gedacht, standardmäßig eingeschaltet und schreibt schon Daten, während PHP die Anfrage noch einliest. Der Angriff läuft also, bevor WordPress überhaupt startet. Die Forscher von Wiz haben zusätzlich gezeigt, dass PHP dabei Inhalte aus dem freigegebenen Speicher an den Angreifer zurückschicken kann. Darin können Passwörter oder API-Schlüssel aus anderen Anfragen stehen.
| Apache mit mod_php | PHP-FPM | |
|---|---|---|
| Lücke 1 | Codeausführung mit Standardeinstellungen gezeigt | Der Prozess beendet sich, die kaputten Daten verschwinden. Auf diesem Weg nicht gezeigt. |
| Lücke 2 | Codeausführung ohne Login gezeigt | Gezeigt, braucht aber eine passende Stelle in der Anwendung |
| Risiko laut PHP-Team | Am höchsten, der Angriff läuft vor der ersten Zeile Anwendungscode | Geringer, abhängig von der Anwendung |
Hinweis: Welche Variante Ihr Server nutzt, steht ebenfalls im Website-Zustand unter „Server”, im Eintrag „PHP SAPI”. „apache2handler” bedeutet mod_php, „fpm-fcgi” bedeutet PHP-FPM. Aktualisiert werden muss in beiden Fällen.
Wie gefährlich die Lücken für eine Firmenwebsite sind
In den vorab durchgesickerten Beiträgen stand oft die Höchstwertung 10. Das PHP-Team vergibt 9,2, weil der Angriff komplex ist und vom PHP-Build, vom Webserver und vom Zustand des Speichers abhängt. Ein Angreifer braucht unter Umständen viele Versuche. Er braucht aber weder einen Login noch die Mithilfe eines Nutzers, und das reicht für automatisierte Angriffe auf viele Server gleichzeitig.
Die Entdecker von Calif berichten von Codeausführung ohne Login unter anderem bei WordPress, Drupal, Joomla und MediaWiki. Für die typische Firmenwebsite heißt das: Ein Kontaktformular, ein Shop oder ein Login-Bereich sind keine Voraussetzung. Es genügt, dass die Website mit PHP läuft.
Zum Stand der Angriffe gab es am 21. Oktober unterschiedliche Meldungen. Cloudflare beobachtete erste Angriffe, watchTowr meldete Zugriffe auf seine Köder-Server. Andere Stellen sahen überwiegend Abtastversuche. Die US-Behörde CISA führte die Lücken zu diesem Zeitpunkt noch nicht in ihrem Katalog aktiv ausgenutzter Schwachstellen. Das BSI rechnete dagegen mit einer schnellen und breiten Ausnutzung innerhalb weniger Stunden nach dem Patch und sprach von unverzüglichem Handlungsbedarf.
Warum ein 20 Jahre alter Fehler jetzt zum Problem wird
Das Grundproblem ist lange bekannt. Es galt nur als zu aufwendig, um es auszunutzen.
| Jahr | Was geschah |
|---|---|
| 2004 | Der Sicherheitsforscher Stefan Esser findet eine Lücke über das Speicherlimit. Seinen Angriffscode veröffentlicht er nicht. |
| 2020 | Ein verwandter Fehler wird gemeldet und als harmlos eingestuft. |
| 2024 | Ein Sicherheitsaudit findet das Problem erneut. Weil die Ausnutzbarkeit nicht bewiesen ist, wird es nicht behoben. |
| August 2026 | Forscher von Calif, Wiz und OpenAI führen diesen Beweis, mit Unterstützung von KI-Modellen. |
| 20. Oktober 2026 | Details, ein Screenshot des Angriffswerkzeugs und ein kurzes Video werden vorzeitig öffentlich. |
| 21. Oktober 2026 | Das PHP-Team veröffentlicht die Korrekturen einen Tag früher als geplant. |
Wie viel davon die KI geleistet hat, beschreibt Calif selbst. Der Forscher von Calif kannte die alten Lücken und ließ das Modell gezielt nach dieser Art Fehler suchen. Ein KI-Agent durchsuchte den Quellcode nach Stellen, an denen PHP unterbrochen werden kann, später wurde das Fehlermuster mit Hilfe eines Sprachmodells verallgemeinert. Kein Modell finde mit einfachen Anweisungen „alle Fehler”, heißt es dort. Nach dieser Darstellung hat die KI die aufwendige Arbeit beschleunigt, die Suchrichtung gab der Forscher vor.
Für Websitebetreiber ziehen wir daraus einen Schluss: Lücken, die bisher als zu kompliziert galten, werden mit KI-Unterstützung günstiger auszunutzen. Die Zeit zwischen dem Bekanntwerden einer Lücke und den ersten Angriffen dürfte eher kürzer werden. Deshalb kommt es darauf an, wer bei Ihrer Website eine solche Meldung liest und wie schnell er reagiert.
Welche PHP-Versionen sind sicher?
| PHP-Zweig | Korrigiert ab | Hinweis |
|---|---|---|
| 8.5 | 8.5.12 | aktueller Zweig |
| 8.4 | 8.4.27 | |
| 8.3 | 8.3.36 | |
| 8.2 | 8.2.35 | Sicherheitsunterstützung endet am 31. Dezember 2026 |
| 8.1 und älter | keine offizielle Version | Für 7.4, 8.0 und 8.1 gibt es nur Quellcode-Korrekturen zum Selberbauen. Einige Linux-Distributionen und Anbieter mit Langzeitsupport liefern eigene Korrekturen. |
Nach dem Update muss PHP-FPM neu gestartet werden. Sonst arbeiten die laufenden Prozesse mit der alten Version weiter.
Was die Korrektur ändert
Der Patch entfernt den abrupten Abbruch bei Speichermangel. Wird das Limit überschritten, darf die laufende Funktion ihre Arbeit sauber beenden, erst danach bricht PHP ab. Bei einem zweiten, höheren Limit wird der Prozess sofort beendet, ohne aufzuräumen. Ein halbfertiger Zustand kann so nicht mehr zurückbleiben.
Übergangsmaßnahmen für Administratoren
Wer nicht sofort aktualisieren kann, findet in der Sicherheitsmeldung des PHP-Teams diese Maßnahmen. Sie verkleinern die Angriffsfläche und sind ausdrücklich kein Ersatz für das Update.
- Speicherlimit pro Anfrage abschalten:
memory_limit = -1, so gesetzt, dass Anwendungen es nicht überschreiben können. Das klingt widersinnig, nimmt dem Angreifer aber den vorhersehbaren Abbruch, den er für Lücke 1 braucht. Den Speicher dabei nicht überRLIMIT_ASoderRLIMIT_DATAbegrenzen, weil genau diese Grenzen den verwundbaren Abbruch wieder auslösen können. - Anfragegröße begrenzen:
post_max_size = 8Mohne Uploads,32Mmit Uploads,upload_max_filesizedarunter. Zusätzlich Größe, Feldanzahl und Verschachtelungstiefe am Webserver oder Proxy begrenzen. - Upload-Fortschritt abschalten:
session.upload_progress.enabled = 0in derphp.inioder im FPM-Pool, danach alle Prozesse neu starten. Überini_set()oder.user.iniwirkt die Einstellung zu spät. - Bei PHP 8.5 zusätzlich:
fatal_error_backtraces = 0setzen und die Prozesse neu starten.
Am 23. Oktober hat das PHP-Team eine weitere Meldung zum Upload-Fortschritt veröffentlicht (CVE-2026-115560). Sie setzt eine besondere Konfiguration voraus und wird im regulären Release-Zyklus behoben. Bis dahin empfiehlt das PHP-Team ebenfalls, den Upload-Fortschritt abzuschalten.
Wie wir mit der Lücke umgehen
Bei 153 Kunden haben wir PHP aktualisiert. Vier Websites liefen noch auf PHP 8.1 oder älter. Diese Kunden haben wir gesondert angesprochen und planen mit ihnen die Umstellung. Zurzeit gleichen wir ab, wo ein Angriff versucht wurde und ob er gelungen ist. Betroffene Kunden sprechen wir einzeln an.
Häufige Fragen
Was kann ein Angreifer mit einer ganz normalen Firmenwebsite anstellen?
Das war die häufigste Frage, die uns nach der BSI-Warnung erreicht hat. Wer über die Lücke Code auf dem Server ausführt, kann alles, was die Website selbst kann, und meist noch mehr:
- Die Website verändern. Er blendet Werbung für Fake-Shops ein oder leitet Besucher auf Betrugsseiten um. Google warnt dann vor der Seite, und die Anfragen bleiben aus.
- Daten mitnehmen. Alles, was in der Datenbank liegt: Kontaktanfragen aus Formularen, Kundenkonten, Bewerbungen. Sind personenbezogene Daten betroffen, muss der Vorfall nach Artikel 33 DSGVO innerhalb von 72 Stunden der Datenschutzbehörde gemeldet werden.
- Zugangsdaten abgreifen. Auf dem Server liegen Passwörter, etwa für die Datenbank, den E-Mail-Versand der Website oder angebundene Dienste. Damit kommt er an weitere Systeme.
- Den Server missbrauchen. Er verschickt darüber Spam oder greift andere Rechner an. Der Hoster sperrt den Server dann, und die eigenen E-Mails landen im Spam.
Oft fällt so ein Angriff zunächst niemandem auf. Die Website läuft weiter, und der Schaden zeigt sich erst später.
Muss ich meine Website abschalten?
Läuft sie auf einer korrigierten Version, nein. Das BSI hat Betreibern geraten, Server im Zweifel vom Netz zu nehmen. Das betrifft Websites, bei denen das Update nicht sofort möglich ist und deren Ausfall weniger schadet als ein Angriff. Diese Abwägung treffen Sie am besten mit Ihrem Hoster.
Schützt mich eine Firewall oder ein Sicherheits-Plugin?
Nur vorübergehend. Cloudflares Technikchef bezeichnet Firewall-Maßnahmen selbst als Notlösung. Ein Sicherheits-Plugin in WordPress kommt bei mod_php ohnehin zu spät, weil der Angriff abläuft, bevor WordPress startet.
Bin ich betroffen, obwohl meine Website kein Formular und keinen Shop hat?
Ja. Bei mod_php haben die Entdecker den Angriff gegen beliebige PHP-Skripte gezeigt. Bei WordPress wird jede Seite über PHP ausgeliefert.
Zusammenfassung
PHP2Shell ist ein Fehler in der Art, wie PHP mit Speichermangel umgeht, und betrifft damit fast jede WordPress-Website. Die Korrektur muss auf dem Server eingespielt werden, ein WordPress-Update reicht dafür nicht. Für PHP 8.1 und älter gibt es keine offizielle Korrektur, PHP 8.2 läuft zum Jahresende aus. Prüfen Sie Ihre PHP-Version heute und lassen Sie sich vom Hoster bestätigen, dass die Korrektur installiert ist.
Ihre Website braucht ein Update oder eine neue PHP-Version, oder Sie wissen nicht, wer bei Ihrem Hoster die Updates einspielt? In einem 30-minütigen Termin sehen wir uns Ihre Website gemeinsam an und sagen Ihnen, was zu tun ist.
Quellen:
- PHP-Projekt: Security Release vom 21. Oktober 2026 – korrigierte Versionen, Bewertung nach CVSS 4.0, Übergangsmaßnahmen, Ende der Unterstützung für PHP 8.2, Meldung zu CVE-2026-115560 vom 23. Oktober
- BSI: Pressemitteilung vom 21. Oktober 2026 – betroffene Versionen bis zurück zu PHP 5, Empfehlungen für Betreiber
- Calif: PHP2Shell – Entdeckung, Rolle der KI-Modelle, Vorgeschichte seit 2004, betroffene Anwendungen (21. Oktober 2026)
- ZDFheute: Sicherheitslücke bei PHP, Millionen Webseiten bedroht – Abschaltung von mainz.de, Empfehlungen des BSI (21. Oktober 2026)
- Tanium: Responding to PHP2Shell – Stand der Angriffe am 21. Oktober, Meldungen von watchTowr und Patchstack, CISA-Katalog
- Malwarebytes: Warum Websites wegen dringender Sicherheitsupdates offline gehen – Einschätzung von Cloudflare, Abgrenzung von WordPress- und PHP-Updates (21. Oktober 2026)
- Artikel 33 DSGVO – Meldung von Verletzungen des Schutzes personenbezogener Daten an die Aufsichtsbehörde binnen 72 Stunden
- Hood Informatik: PHP2Shell, wie ein Speicherfehler zur Shell wird – verständliche Erklärung der Funktionsweise, Ablauf der Veröffentlichung, Wirkung des Patches (Video, 21. Oktober 2026)
Eigene Einordnung: Die Einschätzung, dass KI-Unterstützung die Zeit bis zu ersten Angriffen verkürzt, ist unsere Schlussfolgerung aus dem Fall und steht so in keiner der genannten Quellen. Der Rat, bei einer Umstellung gleich auf PHP 8.3 oder neuer zu gehen und vorher auf einer Kopie zu testen, ist unsere Empfehlung aus der Wartungspraxis. Die Liste möglicher Folgen eines Angriffs (Umleitung, Google-Warnung, Spam-Versand, Sperre durch den Hoster) beschreibt typische Fälle aus der Wartung von WordPress-Websites und ist keine Aussage über einen konkreten Angriff mit PHP2Shell.
