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 in PHP, 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 für Geschäftsführung und Marketingverantwortliche ohne IT-Hintergrund, was hinter den Lücken steckt und was Sie jetzt prüfen sollten.
Das Wichtigste in Kürze
- Ein Angreifer kann im schlimmsten Fall eigenen Code auf dem Webserver ausführen. Damit kann er die Website verändern, Daten mitnehmen und den Server für eigene Zwecke nutzen.
- Betroffen ist PHP selbst, nicht WordPress oder ein Plugin. Ein WordPress-Update hilft deshalb nicht, die Korrektur spielt der Hoster ein.
- Für PHP 8.1 und älter gibt es keine offizielle Korrektur mehr. Diese Websites brauchen eine neuere PHP-Version.
- Erste Angriffsversuche gab es schon am 21. Oktober, gemeldet unter anderem von Cloudflare und watchTowr.
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
- PHP-Version prüfen. Mit dem Prüfer oben oder selbst in WordPress unter Werkzeuge → Website-Zustand → Bericht, Abschnitt „Server“.
- Mit der Tabelle weiter unten abgleichen. Ab 8.2.35, 8.3.36, 8.4.27 oder 8.5.12 ist die Korrektur enthalten. Der Prüfer erledigt das für Sie.
- Beim Hoster nachfragen, wenn die Nummer niedriger ist. Fragen Sie, ob die Korrektur installiert ist und nicht nur eingeplant. Manche Hoster bauen sie ein, ohne die Versionsnummer zu ändern.
- Bei PHP 8.1 oder älter die Umstellung planen. Am besten gleich auf 8.3 oder neuer, mit einem Test auf einer Kopie der Website.
- Nach Spuren eines Angriffs sehen lassen. Das übernimmt Ihr Hoster oder der Dienstleister, der Ihre Website wartet.
Was ist PHP, und warum betrifft das Ihre Website?
PHP ist die Programmiersprache, in der WordPress geschrieben ist. Auch Joomla, Drupal und TYPO3 laufen damit. Bei jedem Seitenaufruf startet auf dem Server ein PHP-Prozess, holt die Inhalte aus der Datenbank und baut daraus die Seite.
Das pflegen Sie oder Ihre Agentur
WordPress, Theme und Plugins. Diese Updates laufen über das WordPress-Backend.
Das pflegt der Hoster
PHP selbst. Es ist ein Programm auf dem Server, und genau dort steckt PHP2Shell.
Wie die Lücken funktionieren
Jeder Seitenaufruf läuft in PHP in drei Schritten ab. Pro Aufruf darf PHP dabei nur eine begrenzte Menge Arbeitsspeicher belegen, in der Grundeinstellung 128 Megabyte.
Lücke 1 · CVE-2026-109618
- Was passiert
- PHP zählt einen Eintrag mit, bricht aber ab, bevor er befüllt ist. Beim Aufräumen verarbeitet PHP den leeren Eintrag samt alter Daten.
- Wie der Angreifer es auslöst
- Mit einer präparierten Formularanfrage unter 8 Megabyte, die mehr als 128 Megabyte Speicher belegt.
Lücke 2 · CVE-2026-109619
- Was passiert
- Nach dem Abbruch zeigt ein Verweis auf schon freigegebenen Speicher. Die nächste Anfrage arbeitet mit diesen fremden Daten weiter.
- Wie der Angreifer es auslöst
- Über die Funktion für Upload-Fortschrittsbalken. Sie ist standardmäßig eingeschaltet und läuft, bevor WordPress startet.
Für Technikinteressierte: der genaue Ablauf
Lücke 1: 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. Reißt genau diese Reservierung das Limit, meldet der Zähler einen Eintrag mehr, der nie befüllt wurde. Laut den Entdeckern gelingt der gezielte Abbruch mit Dateifeldern ohne Dateinamen: Sie zählen nicht als Upload, erzeugen aber mehrere Verwaltungseinträge, mit verschachtelten Feldnamen sehr viele.
Lücke 2: Einige Verweise in PHP bleiben zwischen zwei Anfragen erhalten und müssen am Ende jeder Anfrage zurückgesetzt werden. Bricht ein Fehler die Anfrage vorher ab, zeigt der Verweis auf freigegebenen Speicher („Use after free“). Die Forscher von Wiz haben gezeigt, dass PHP dabei Speicherinhalte an den Angreifer zurückschicken kann, darunter Passwörter oder API-Schlüssel aus anderen Anfragen.
Server-Varianten: Bei mod_php ist PHP direkt in den Webserver Apache eingebaut, bei PHP-FPM läuft es als eigener Dienst. Welche Variante Ihr Server nutzt, steht im Website-Zustand unter „Server“ im Eintrag „PHP SAPI“: apache2handler bedeutet mod_php, fpm-fcgi bedeutet PHP-FPM.
Ob ein Angriff gelingt, hängt davon ab, wie PHP auf dem Server eingebunden ist:
| Apache mit mod_php | PHP-FPM | |
|---|---|---|
| Lücke 1 | Angriff nachgewiesen schon mit Standardeinstellungen | nicht nachgewiesen der Prozess beendet sich, die fehlerhaften Daten verschwinden |
| Lücke 2 | Angriff nachgewiesen ohne Login | Angriff nachgewiesen nur, wenn die Anwendung eine passende Stelle bietet |
| Risiko laut PHP-Team | am höchsten | geringer |
„Nachgewiesen“ heißt: Die Sicherheitsforscher haben den Angriff im Test tatsächlich durchgeführt. Aktualisiert werden muss PHP in beiden Fällen.
Wie gefährlich die Lücken für eine Firmenwebsite sind
Das PHP-Team bewertet beide Lücken mit 9,2 von 10 Punkten. Der Angriff ist kompliziert und 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 haben Angriffe ohne Login unter anderem auf WordPress, Drupal und Joomla nachgewiesen. Ein Formular oder Shop ist dafür keine Voraussetzung.
Wer über die Lücke Code auf dem Server ausführt, kann vier Dinge tun:
Website verändern
Werbung für Fake-Shops einblenden oder Besucher auf Betrugsseiten umleiten. Google warnt dann vor der Seite, und die Anfragen bleiben aus.
Daten mitnehmen
Kontaktanfragen, Kundenkonten, Bewerbungen. Sind personenbezogene Daten betroffen, muss der Vorfall binnen 72 Stunden der Datenschutzbehörde gemeldet werden.
Zugangsdaten abgreifen
Passwörter für Datenbank, E-Mail-Versand oder angebundene Dienste liegen auf dem Server. Damit kommt er an weitere Systeme.
Server missbrauchen
Spam verschicken oder andere Rechner angreifen. Der Hoster sperrt den Server dann, und die eigenen E-Mails landen im Spam.
Oft fällt ein solcher Angriff zunächst niemandem auf. Die Website läuft weiter, und der Schaden zeigt sich erst später.
Am 21. Oktober meldete Cloudflare erste Angriffe, watchTowr Zugriffe auf seine Köder-Server. Andere Stellen sahen vor allem Abtastversuche. Das BSI rechnete mit einer breiten Ausnutzung innerhalb weniger Stunden nach dem Patch.
Warum ein 20 Jahre alter Fehler jetzt zum Problem wird
- 2004Stefan Esser findet eine Lücke über das Speicherlimit und veröffentlicht seinen Angriffscode nicht.
- 2020Ein verwandter Fehler wird gemeldet und als harmlos eingestuft.
- 2024Ein Sicherheitsaudit findet das Problem erneut. Weil die Ausnutzbarkeit nicht bewiesen ist, bleibt es liegen.
- August 2026Forscher von Calif, Wiz und OpenAI führen den Beweis, mit Unterstützung von KI-Modellen.
- 20. Oktober 2026Details und ein Video des Angriffswerkzeugs werden vorzeitig öffentlich.
- 21. Oktober 2026Das PHP-Team veröffentlicht die Korrekturen einen Tag früher als geplant.
Der Forscher von Calif kannte die alten Lücken und ließ ein KI-Modell gezielt nach dieser Art Fehler suchen. Nach seiner Darstellung hat die KI die aufwendige Arbeit beschleunigt, die Suchrichtung gab er vor.
Unsere Einordnung: Lücken, die als zu kompliziert galten, werden mit KI-Unterstützung günstiger auszunutzen. Die Zeit zwischen Bekanntwerden und ersten Angriffen dürfte 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 | Sicher ab | Hinweis |
|---|---|---|
| 8.5 | 8.5.12 | aktueller Zweig |
| 8.4 | 8.4.27 | |
| 8.3 | 8.3.36 | |
| 8.2 | 8.2.35 | Sicherheitsupdates nur noch bis 31. Dezember 2026 |
| 8.1 und älter | keine Korrektur | Wechsel auf eine neuere Version nötig. Einige Linux-Distributionen liefern eigene Korrekturen. |
Die Korrektur sorgt dafür, dass PHP bei Speichermangel seine laufende Arbeit sauber beendet, bevor es abbricht. Halbfertige Daten bleiben so nicht mehr zurück. Nach dem Update muss PHP-FPM neu gestartet werden, sonst laufen die alten Prozesse weiter.
Für Administratoren: Übergangsmaßnahmen, wenn das Update nicht sofort geht
Diese Maßnahmen aus der Sicherheitsmeldung des PHP-Teams verkleinern die Angriffsfläche. Sie ersetzen das Update ausdrücklich nicht.
- Speicherlimit pro Anfrage abschalten:
memory_limit = -1, so gesetzt, dass Anwendungen es nicht überschreiben können. Den Speicher dabei nicht überRLIMIT_ASoderRLIMIT_DATAbegrenzen, weil 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 kam eine weitere Meldung zum Upload-Fortschritt hinzu (CVE-2026-115560). Sie wird im regulären Release-Zyklus behoben; bis dahin gilt ebenfalls: Upload-Fortschritt abschalten.
Wie wir mit der Lücke umgehen
Betroffene Kunden sprechen wir einzeln an.
Was kann ein Angreifer mit einer ganz normalen Firmenwebsite anstellen?
Er kann die Website verändern, Daten aus der Datenbank mitnehmen, Zugangsdaten für weitere Systeme abgreifen und den Server für Spam oder Angriffe nutzen. Die Einzelheiten stehen weiter oben im Abschnitt „Wie gefährlich die Lücken für eine Firmenwebsite sind“.
Muss ich meine Website abschalten?
Läuft sie auf einer korrigierten Version, nein. Das BSI hat 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, und bei WordPress wird jede Seite über PHP ausgeliefert.
Reicht es, wenn ich WordPress und die Plugins aktualisiere?
Nein. PHP ist ein Programm auf dem Server und wird vom Hoster aktualisiert. Fragen Sie dort nach, ob die Korrektur vom 21. Oktober 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.
30-Minuten-Termin buchenQuellen:
- 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
- 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 an die Aufsichtsbehörde binnen 72 Stunden
- Hood Informatik: PHP2Shell, wie ein Speicherfehler zur Shell wird – verständliche Erklärung der Funktionsweise (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. Der Rat, gleich auf PHP 8.3 oder neuer umzustellen und vorher auf einer Kopie zu testen, stammt aus unserer Wartungspraxis. Die vier möglichen Folgen eines Angriffs beschreiben typische Fälle aus der Wartung von WordPress-Websites, keinen konkreten Angriff mit PHP2Shell.
