PHP2Shell: PHP-Sicherheitslücke und sichere Websites ohne PHP

Am Nachmittag des 21. Oktober 2026 hat das PHP-Projekt Notfall-Updates veröffentlicht. Sie schließen zwei Lücken, die unter dem Namen PHP2Shell bekannt geworden sind. Über beide kann ein Angreifer ohne Passwort eigenen Code auf einem Webserver ausführen. Das BSI stuft die Lage als orange ein, die zweithöchste von vier Stufen, und rät, unverzüglich zu handeln.

PHP ist die Sprache hinter WordPress, Joomla, Shopware, TYPO3 und vielen selbst programmierten Seiten. Laut W3Techs laufen 69,3 Prozent aller Websites, deren Serversprache bekannt ist, mit PHP. Eine Lücke in PHP selbst betrifft deshalb einen großen Teil des Netzes auf einmal.

Unten steht, was belegt ist und was du heute tun solltest. Und warum ich Websites, wo es passt, ganz ohne PHP baue.

Was ist PHP2Shell?

PHP2Shell ist der Sammelname für zwei Schwachstellen: CVE-2026-109618 und CVE-2026-109619. Das PHP-Projekt bewertet beide mit 9,2 von 10 Punkten im CVSS-System. Der Name lehnt sich laut BSI an Log4Shell an, die große Java-Lücke von 2021.

Die Fehler stecken im PHP-Interpreter selbst, also in dem Programm, das jede PHP-Seite erst ausführt. Plugins und Themes spielen dafür keine Rolle. Laut PHP-Team ist jede Installation gefährdet, die Webanfragen bedient, ob über PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP oder LiteSpeed. Am höchsten schätzt das Team das Risiko bei mod_php ein. Dort wurde gezeigt, dass eine Anfrage ohne Anmeldung den Angriff auslösen kann, bevor überhaupt Code der Website läuft.

Eine gepflegte WordPress-Installation mit allen Plugin-Updates war damit genauso angreifbar wie eine vernachlässigte. Der älteste betroffene Codepfad reicht laut den Entdeckern von Calif bis PHP 5.4 zurück, erschienen 2012.

Die zwei Lücken, verständlich erklärt

• CVE-2026-109618, Speicherfehler bei zu wenig Arbeitsspeicher: Stößt PHP an sein Speicherlimit, bricht es die Verarbeitung ab. Dabei können Daten der Anfrage erst halb vorbereitet sein, werden beim Aufräumen aber trotzdem verarbeitet. Ausgelöst werden kann das zum Beispiel über präparierte Upload-Anfragen.
• CVE-2026-109619, Altlasten im Speicher: Daten einer Anfrage bleiben im Speicher, obwohl sie schon freigegeben sind. Eine spätere Anfrage im selben PHP-Prozess greift dann darauf zu.

Das PHP-Team stuft die Angriffskomplexität als hoch ein. An der Bewertung ändert das wenig: Wer es schafft, übernimmt den Server.

Zeitleiste: von 2012 bis zum Notfall-Patch

Die Lücken wurden im August 2026 vertraulich an das PHP-Team gemeldet, unabhängig voneinander von der Sicherheitsfirma Calif, von OpenAI und von Wiz. Wiz hatte zuvor Angriffe ohne Anmeldung gegen Drupal und WordPress erfolgreich nachgestellt. Die PHP Foundation räumt offen ein, dass die Arbeit am Fix danach über Monate immer wieder ins Stocken geriet, und nennt die Verzögerung selbst ein strukturelles Versagen. Am 20. Oktober sickerten die CVE-Nummern vorzeitig durch, einen Tag später kamen die Updates.

Interessant ist der 17. Oktober: An diesem Tag registrierte AWS in seinen Lockvogel-Servern bereits einen Angriffsversuch, vier Tage vor der Veröffentlichung. Inzwischen melden AWS, Cloudflare und watchTowr Angriffe in freier Wildbahn. Das BSI schrieb am 21. Oktober noch von unbestätigten Berichten. Die Quellen widersprechen sich hier also, die Richtung ist trotzdem klar: Ungepatchte Server sind jetzt Ziel.

Welche Rolle spielt KI?

KI taucht bei PHP2Shell auf der Seite der Entdecker, der Verteidiger und der Angreifer auf.

Zuerst die Entdecker. Wiz schreibt, das Team habe mit dem eigenen Werkzeug Wiz Atlas sowie den Modellen Gemini 4 Argon und GPT-5.6 Sol gearbeitet. Gemini habe beim Finden der Lücke, beim Bau des Exploits, bei der Erkennung von Angriffen und bei der Prüfung des Patches geholfen. Calif ordnet das in seinem Bericht nüchterner ein: Für den ersten Fund seien keine besonderen Werkzeuge oder unveröffentlichten Modelle nötig gewesen, entscheidend sei das Wissen über die Geschichte alter PHP-Lücken gewesen. Kein Modell finde mit einfachen Anweisungen einfach alle Fehler.

Auf der anderen Seite steht das PHP-Team. Die PHP Foundation berichtet, dass durch KI-gestützte Forschung deutlich mehr Meldungen eingehen als früher. Seit dem 1. Juli 2026 hat das Team 15 CVEs veröffentlicht und über 100 Meldungen bearbeitet, die sich als ungültig, doppelt oder nicht nachvollziehbar herausstellten. KI hilft beim Sortieren. Entscheiden und patchen tun Menschen.

Am meisten ändert sich für Angreifer. AWS schreibt, KI-gestützte Analyse mache es billiger, aus einem Patch oder einer Sicherheitsmeldung einen funktionierenden Exploit zu bauen. Mehr Angreifer könnten deshalb innerhalb von Stunden oder Minuten handeln. Das BSI sieht es genauso. Der CrowdStrike Global Threat Report 2026 beziffert den Anstieg der Aktivität KI-gestützter Angreifer auf 89 Prozent gegenüber dem Vorjahr.

Was du jetzt sofort tun solltest

1. PHP-Version prüfen. In der Verwaltung deines Hosting-Pakets oder in WordPress unter Werkzeuge, Website-Zustand, Bericht, Abschnitt Server.
2. Auf eine abgesicherte Version wechseln: 8.5.12, 8.4.27, 8.3.36 oder 8.2.35. Bei Shared Hosting übernimmt das der Hoster, ein Blick auf seine Statusseite lohnt sich. Mittwald meldete zum Beispiel bis zum 22. Oktober, die Lücke für nahezu alle betroffenen Versionen behoben zu haben.
3. Eigener Server, VPS oder Docker: Pakete aktualisieren, Container-Images neu bauen und alle PHP-Prozesse neu starten. Das BSI weist darauf hin, dass auch Anwendungen in Docker-Containern aktualisiert oder neu gebaut werden müssen.
4. PHP 8.1 und älter ablösen. Diese Versionen bekommen vom PHP-Projekt keine regulären Updates mehr. PHP 8.2 folgt am 31. Dezember 2026.
5. Kein Update möglich? Das BSI empfiehlt dann, eine vorübergehende Trennung vom Internet zu erwägen. Regeln in einer Web Application Firewall, etwa von Cloudflare, verschaffen Zeit, ersetzen das Update laut Wiz und PHP-Team aber nicht.
6. Auf Spuren achten. Wiz nennt als Warnzeichen gehäufte Serverfehler (HTTP 500) nach ungewöhnlichen Uploads, auffällig große Session-Cookies und unerklärliche Neustarts von PHP-Prozessen. AWS rät, Untersuchungen ab dem 17. Oktober anzusetzen.

Falls du Hinweise auf einen erfolgreichen Angriff findest und auf dem Server personenbezogene Daten liegen, etwa aus Kontaktformularen, denk an die Meldepflicht: Nach Art. 33 DSGVO musst du eine Datenpanne in der Regel binnen 72 Stunden der Aufsichtsbehörde melden. Mehr dazu in meiner DSGVO-Checkliste.

Warum PHP-Websites so oft getroffen werden

PHP selbst ist kein schlechtes Werkzeug. Das PHP-Team pflegt die Sprache und schließt Lücken. Das Problem ist die Bauweise der meisten PHP-Websites: Bei einem Seitenaufruf läuft in der Regel Programmcode auf dem Server. Der Interpreter startet, das CMS lädt Plugins und Theme, fragt die Datenbank ab und baut die Seite zusammen. Der Admin-Login ist über die eigene Domain erreichbar. Jede dieser Schichten ist Code, der Fehler enthalten kann.

Dazu kommt die Verbreitung. Wenn fast 70 Prozent der Websites mit bekannter Serversprache auf derselben Technik laufen, lohnt sich jede gefundene Lücke für Angreifer besonders. PHP2Shell ist 2026 auch nicht der erste Fall dieser Art: Im Juli 2026 wurde mit wp2shell eine Lücke im WordPress-Kern bekannt, über die Angreifer ohne Anmeldung Code ausführen konnten. Gefunden hat sie Searchlight Cyber mit GPT-5.6 Sol, laut Wiz wurde sie danach aktiv ausgenutzt, auf betroffenen Servern fanden sich Webshells.

Die Alternative: Websites ohne PHP

Was statisch bedeutet

Eine statische Website wird nicht bei jedem Aufruf neu zusammengesetzt, sondern einmal vorab gebaut. Heraus kommen fertige HTML-, CSS- und JavaScript-Dateien. Der Webserver oder ein CDN liefert diese Dateien nur noch aus. Es läuft kein PHP, es gibt keine Datenbank im Netz und keinen Admin-Login auf deiner Domain.

Statisch heißt dabei nicht altmodisch. Moderne Werkzeuge wie Astro, Hugo, Eleventy oder Next.js im statischen Export erzeugen schnelle Seiten mit Animationen, Formularen und interaktiven Elementen. Was dynamisch sein muss, etwa das Absenden eines Kontaktformulars, übernimmt eine kleine, abgeschottete Funktion oder ein Fachdienst.

Wann PHP weiterhin sinnvoll ist

Nicht jede Website lässt sich statisch bauen. Ein Shop mit Warenkorb, ein Mitgliederbereich oder ein Portal mit Kundenkonten braucht Logik auf dem Server. Auch dann muss nicht die ganze Website dynamisch sein: Shop oder Login können als spezialisierter Dienst laufen, die übrigen Seiten bleiben statisch. Und wo PHP bleibt, braucht es eine verlässliche Wartung, die Updates zeitnah einspielt.

Für die typische Website eines Handwerksbetriebs, einer Praxis oder einer Kanzlei lautet die Antwort auf beide Fragen oft Nein. Leistungen, Team, Kontakt, Anfahrt und ein Formular: Dafür muss auf dem Server kein Programm laufen.

Wie KI beim Bauen sicherer Websites hilft

Lange war WordPress auch eine Kostenfrage. Eine individuell programmierte Website war teuer, ein CMS mit fertigem Theme günstig. KI-Modelle haben diese Rechnung verändert. Bei mir schreiben Modelle wie Claude und Codex einen großen Teil des Codes, nach klaren Vorgaben. Dadurch wird eine maßgeschneiderte statische Website wirtschaftlich, die früher am Aufwand gescheitert wäre.

Konkret hilft KI an vier Stellen. Seitenaufbau, Layout, Animationen und Formular-Funktion entstehen schneller. Modelle lesen Code gegen, finden typische Fehler und prüfen die Sicherheits-Header, dazu meldet ein Werkzeug wie npm audit bekannte Lücken in den verwendeten Paketen. Automatische Tests und Screenshots in mehreren Bildschirmbreiten zeigen, ob alles aussieht und funktioniert wie geplant. Und Updates von Paketen lassen sich vorbereiten und testen, bevor sie live gehen.

Aber: KI-Code ist nicht automatisch sicherer Code. Veracode hat 2025 über 100 Sprachmodelle mit 80 Programmieraufgaben getestet. In 45 Prozent der Fälle enthielt der erzeugte Code Sicherheitslücken. Deshalb darf KI bei mir schreiben, aber nichts freigeben. Jede Änderung wird geprüft, bevor sie live geht.

Hier spielt die statische Bauweise ihren zweiten Vorteil aus. Rutscht trotz Prüfung ein Fehler durch, steckt er in fertigen Dateien, nicht in einem Programm, das auf dem Server läuft und von außen angesprochen werden kann. Der mögliche Schaden bleibt deutlich kleiner.

Ehrlich bleiben: Auch ohne PHP gibt es Risiken

Ein Wechsel der Programmiersprache allein löst nichts. Im Dezember 2025 traf die Lücke React2Shell (CVE-2025-55182, CVSS 10,0) Anwendungen, die React-Server-Komponenten auf einem Server ausführen, darunter Next.js. Das React-Team schrieb dazu ausdrücklich: Wer React ohne Server betreibt, ist nicht betroffen. Entscheidend ist also, wie viel Code bei einem Seitenaufruf auf dem Server läuft. Die Sprache ist zweitrangig.

Auch eine statische Website braucht Pflege an anderen Stellen:

• Pakete, die beim Bauen verwendet werden, aktuell halten und auf bekannte Lücken prüfen.
• Zugänge zu Hosting, Git und Domain mit Zwei-Faktor-Anmeldung absichern.
• Die Formular-Funktion sauber programmieren: Eingaben prüfen, Spam abwehren, nur das Nötigste speichern.

Fazit

PHP2Shell wird nicht die letzte große Lücke gewesen sein. KI beschleunigt das Finden von Schwachstellen, und sie beschleunigt das Ausnutzen. Kurzfristig zählt nur eines: PHP auf eine abgesicherte Version bringen und prüfen, ob der Hoster das erledigt hat.

Langfristig lohnt sich die Frage, ob deine Website überhaupt Code auf dem Server braucht. Für viele Unternehmensseiten lautet die Antwort Nein. Eine statische Website, mit KI gebaut und von einem Menschen geprüft, lädt schnell und bietet Angreifern deutlich weniger Fläche.

Wenn du wissen willst, wie das für deine Website aussehen würde: Im kostenlosen Website-Check schauen wir es uns gemeinsam an. Den Umfang kannst du vorab im Projekt-Konfigurator zusammenstellen.