PHP2Shell: Die PHP-Sicherheitslücke, die Behörden vom Netz zwang, und was sie für deine Website bedeutet

Am Mittwoch, dem 21. Oktober 2026, gingen in Deutschland reihenweise Websites vom Netz. Nicht wegen eines Angriffs, sondern aus Vorsicht. Die Charité, Landesministerien, Polizei-Webseiten, Städte wie Mainz und Dresden: Sie alle zogen den Stecker, weil eine Sicherheitslücke in PHP bekannt wurde. PHP ist die Programmiersprache, die laut W3Techs 69,3 Prozent aller Websites einsetzen, deren serverseitige Sprache bekannt ist (Stand 22.10.2026). Auch fast jede WordPress-Seite läuft darauf.

In diesem Artikel erfährst du, was hinter „PHP2Shell“ steckt, wer betroffen ist, warum sogar Behörden offline gegangen sind, und was du jetzt für deine eigene Website tun solltest.

Was ist PHP2Shell?

PHP2Shell ist der Spitzname für zwei Schwachstellen direkt im Kern von PHP. Der Name spielt bewusst auf „Log4Shell“ an, so ordnet es auch das BSI ein. Weil die Fehler in der Sprache selbst stecken und nicht in einem bestimmten Plugin oder CMS, trifft es praktisch jede PHP-Anwendung: WordPress, Drupal, Joomla, Shopsysteme, selbst geschriebene Kundenportale.

Technisch funktioniert der Angriff, vereinfacht gesagt, so:

• CVE-2026-109618 betrifft die Art, wie PHP reagiert, wenn einer Anfrage der Arbeitsspeicher ausgeht. Mit einer speziell präparierten Anfrage kann ein Angreifer diesen Zustand gezielt herbeiführen. PHP bricht dann ab und hinterlässt Speicher in einem undefinierten Zustand.
• CVE-2026-109619 sorgt dafür, dass Reste dieser abgebrochenen Anfrage im Arbeitsprozess hängen bleiben. Die nächste Anfrage greift auf bereits freigegebenen Speicher zu, ein klassischer „Use-after-free“.

Kombiniert lässt sich daraus Code ausführen. Besonders unangenehm: Einer der gezeigten Wege führt über den Upload-Fortschritt von Sessions, und diese Funktion ist in PHP standardmäßig aktiv. Die Website muss also nichts Besonderes tun, um angreifbar zu sein.

Wichtig für die Einordnung: Eine Anmeldung in deiner Anwendung schützt nicht. PHP verarbeitet die schädliche Anfrage, bevor überhaupt Anwendungscode läuft. Ein Update von WordPress oder von Plugins hilft ebenfalls nicht, weil der Fehler eine Ebene tiefer sitzt.

Entdeckt mit Hilfe von KI

Bemerkenswert ist, wie die Lücken gefunden wurden. Das Sicherheitsunternehmen Wiz entdeckte den ersten Fehler am 19. August 2026, unterstützt von KI-Modellen von Google und OpenAI. Einen Tag später konnte das Team Drupal ohne Anmeldung übernehmen, am 21. August auch WordPress. Joomla folgte. Nach Angaben des BSI waren Wiz.io und Calif.io gemeinsam mit OpenAI an der Entdeckung beteiligt.

Nach Angaben der Entdecker steckt der Fehler seit über einem Jahrzehnt im Code. Dass ihn jetzt ausgerechnet KI-gestützte Analysen gefunden haben, dürfte nicht das letzte Mal gewesen sein. Die gleichen Werkzeuge stehen schließlich auch Angreifern zur Verfügung.

Eine Veröffentlichung, die aus dem Ruder lief

Geplant war ein geordneter Ablauf: Das PHP-Team kündigte für Mittwoch, 21. Oktober, 16 Uhr deutscher Zeit, ein Notfall-Update an. Doch schon am 20. Oktober sickerten Details durch, Sicherheitsforscher konnten den Fehler nachbauen.

Cloudflare-Chef Matthew Prince berichtete, sein Netzwerk habe in den rund zehn Stunden vor der Veröffentlichung bereits tausende Ausnutzungsversuche gesehen. Erst danach stieg die Zahl rasch an: binnen 45 Minuten auf Zehntausende, binnen zwei Stunden auf Hunderttausende, später in die Millionen. Amazon will in seinem Honeypot-Netzwerk sogar schon am 17. Oktober einen ersten Versuch beobachtet haben.

Das Ergebnis: Viele Betreiber hatten zum Zeitpunkt der ersten Angriffe noch gar keine Möglichkeit zu patchen. Linux-Distributionen wie Debian, Ubuntu oder Red Hat lieferten ihre Pakete erst im Laufe des Mittwochabends aus.

Wer ist betroffen? Behörden, Kliniken, Universitäten

Wie ernst die Lage eingeschätzt wurde, zeigt die Liste der Einrichtungen, die ihre Websites vorsorglich abgeschaltet oder eingeschränkt haben. Die folgende Übersicht stützt sich auf die Berichterstattung von heise online und teltarif.de vom 21. Oktober 2026:

Deutschland

• Berlin: Die Charité nahm alle Webseiten vom Netz, Teile von berlin.de wurden abgeschaltet, die Internetwache der Berliner Polizei war nicht erreichbar, die Freie Universität schränkte ihre IT-Dienste ein.
• Bayern: Homepages mehrerer Ministerien und der Polizei, das Klinikum Nürnberg und das Landratsamt Rhön-Grabfeld waren offline.
• Baden-Württemberg: Webseiten der Ministerien und Regierungspräsidien sowie teilweise von Universitäten.
• Hessen: hessen.de und die Seiten der Ministerien im Hessen-Web.
• Thüringen: Staatskanzlei, mehrere Ministerien, Behörden und die Landespolizei. Die Seite des Landtags blieb dagegen erreichbar.
• Städte: Mainz nahm mainz.de und weitere städtische Dienste vom Netz, Dresden schaltete alle städtischen Seiten ab.
• Niedersachsen: Auch hier waren Behörden- und Polizeiseiten zeitweise nicht erreichbar.
• Außerdem die Ruhr-Universität Bochum und zahlreiche weitere Hochschulen und Krankenhäuser.

International

• Niederlande: Das Parlament und das nationale Cybersicherheitszentrum nahmen Websites offline.
• Finnland: Das staatliche IT-Zentrum Valtori schaltete öffentliche Webdienste der Zentralregierung ab, ebenso das Landesvermessungsamt.
• Dänemark und Frankreich: Regierungsseiten gingen offline oder in den Wartungsmodus.
• Japan: Einem Bericht zufolge war zeitweise sogar die Website des Premierministers abgeschaltet.

Und was ist mit kleinen Unternehmen?

Behörden haben eigene IT-Abteilungen, die über Nacht reagieren können. Die meisten kleinen und mittleren Unternehmen nicht. Ihre Website liegt bei einem Hoster, und ob dort schon aktualisiert wurde, ist von außen kaum zu erkennen.

IONOS hat sich als einziger der großen deutschen Anbieter öffentlich und nachvollziehbar geäußert: Laut Statusseite und Newsroom sind die offiziellen Updates auf allen selbst betriebenen Plattformen eingespielt, Kunden müssen nichts weiter tun. Schon vor der Veröffentlichung der Patches hatte IONOS nach eigenen Angaben angepasste PHP-Konfigurationen und Firewall-Regeln aktiviert.

Für andere Anbieter lag mir zum Zeitpunkt der Aktualisierung keine offizielle, verlinkbare Stellungnahme vor. Das heißt nicht, dass dort nichts passiert ist. Frag im Zweifel direkt beim Support nach, ob das Update für deine PHP-Version eingespielt wurde, und lass dir die genaue Versionsnummer nennen.

Das größere Problem sind veraltete PHP-Versionen. Läuft deine Website noch auf PHP 8.1, 8.0 oder gar 7.4, gibt es dafür keine fertigen Update-Releases, sondern nur Quellcode-Backports, die dein Hoster selbst einbauen muss. Manche Anbieter leisten das über einen kostenpflichtigen „Extended Support“, andere gar nicht. In diesen Fällen hilft nur der Umstieg auf PHP 8.2 oder neuer.

Was passiert, wenn du nichts tust?

Ein erfolgreicher Angriff gibt dem Angreifer die volle Kontrolle über den Webspace. Typische Folgen:

• Schadcode wird eingeschleust, der deine Besucher infiziert oder auf betrügerische Seiten umleitet
• Spam- und Phishing-Seiten erscheinen unter deiner Domain
• Formular- und Kundendaten werden abgegriffen, mit Meldepflichten nach der DSGVO
• Dein Server verschickt Spam, deine E-Mails landen danach selbst im Spam-Ordner
• Google warnt vor deiner Seite oder wirft sie aus den Suchergebnissen, der Hoster sperrt den Account

So prüfst du deine Website

1. PHP-Version nachsehen: Im Kundenmenü deines Hosters findest du sie meist unter „PHP-Einstellungen“ oder „PHP-Version“ der jeweiligen Domain.
2. Version vergleichen: Sicher sind 8.2.35, 8.3.36, 8.4.27 und 8.5.12 oder neuer. Steht dort nur „8.2“ ohne Unterversion, frag beim Hoster nach, ob das Update eingespielt ist.
   
   Diese Versionsnummern gelten für offizielle PHP-Builds, wie sie Hoster meist nutzen. Auf einem eigenen Server mit Debian, Ubuntu oder Red Hat entscheidet nicht die Versionsnummer, sondern ob das Sicherheitsupdate der Distribution installiert ist. Prüfe das über den Paketmanager oder das Security-Advisory deiner Distribution.
3. Alte Versionen umstellen: Bei PHP 8.1 und älter auf eine aktuelle Version wechseln. Vorher prüfen, ob Theme und Plugins kompatibel sind, und ein Backup anlegen.
4. Alle Domains im Paket bedenken: Die PHP-Version wird oft pro Domain eingestellt. Eine vergessene Zweitseite im selben Hosting-Paket reicht als Einfallstor.

Eigener Server oder VPS: Sofortmaßnahme

Auf einem eigenen Server oder VPS bist du selbst für das Update zuständig, nicht der Hoster. Die Reihenfolge:

1. Distributions-Updates sofort einspielen und danach PHP-FPM beziehungsweise den Webserver neu starten.
2. Bis das Update läuft: In der php.ini oder in der FPM-Pool-Konfiguration den Upload-Fortschritt der Sessions abschalten und anschließend jeden PHP-Worker neu starten. Das PHP-Team nennt diesen Schritt ausdrücklich als Zwischenmaßnahme.

; php.ini oder FPM-Pool
session.upload_progress.enabled = 0

Betreibst du PHP 8.5 und kannst nicht sofort updaten, empfiehlt das PHP-Team zusätzlich fatal_error_backtraces = 0, ebenfalls mit Neustart aller Worker.

Könnte meine Website schon angegriffen worden sein?

Das lässt sich nicht ausschließen. Laut Cloudflare liefen schon rund zehn Stunden vor dem offiziellen Patch Ausnutzungsversuche, also in einem Zeitraum, in dem auch schnelle Hoster noch nichts einspielen konnten. Ein Patch schließt die Lücke, entfernt aber keinen Schadcode, der vorher eingeschleust wurde.

Achte auf diese Warnzeichen:

• unbekannte Benutzer im WordPress-Backend
• unbekannte PHP-Dateien in /wp-content/uploads/, dort gehören normalerweise nur Bilder und Dokumente hin
• neue oder geänderte Cronjobs im Hosting-Panel
• Weiterleitungen auf fremde Seiten, besonders auf dem Smartphone oder beim Klick aus Google
• der Hinweis „Diese Website wurde möglicherweise gehackt“ in den Suchergebnissen
• fremde oder kürzlich geänderte Dateien auf dem Webspace
• eine Nachricht deines Hosters über Spam-Versand oder auffällige Aktivitäten

Fällt dir so etwas auf: Website nicht einfach weiterlaufen lassen, sondern prüfen lassen. Im Zweifel vorübergehend offline nehmen, so wie es auch die Behörden getan haben.

Bei einem konkreten Verdacht reicht Aufräumen allein nicht. Ändere alle Passwörter, die mit der Website zu tun haben: Hosting-Account, FTP beziehungsweise SFTP, Datenbank und sämtliche WordPress-Administratoren. Erzeuge außerdem die WordPress-Salts neu, damit bestehende Sitzungen eines Angreifers ungültig werden.

Fazit

PHP2Shell ist eine der schwersten Sicherheitslücken der letzten Jahre im Web. Nicht wegen ihrer technischen Raffinesse, sondern wegen ihrer Reichweite: Sie steckt in der Sprache selbst und trifft damit fast jede PHP-Website. Wenn Ministerien, Polizei und Unikliniken ihre Seiten vom Netz nehmen, sollte das jedem Website-Betreiber zu denken geben. Die gute Nachricht: Die Lösung ist bekannt. Ein aktuelles PHP schließt die Lücke. Man muss es nur tun, und zwar jetzt.

Updates

• 22.10.2026: Artikel veröffentlicht und am selben Tag überarbeitet. Alle Zahlen gegen die Primärquellen geprüft, Stand bei IONOS ergänzt (Updates eingespielt), Sofortmaßnahme für eigene Server und Hinweis auf Distributions-Pakete aufgenommen.

Quellen

• BSI: PHP, kritische Schwachstellen bedrohen Webanwendungen weltweit
• PHP-Advisory zu CVE-2026-109618 (GHSA-w8hw-w9fx-j79w, englisch)
• PHP-Advisory zu CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp, englisch)
• Wiz Research: PHP2Shell (englisch)
• W3Techs: Verbreitung von PHP als serverseitige Sprache (englisch)
• IONOS: Statusseite zur Sicherheitswartung
• IONOS Newsroom: Websites bei IONOS sind geschützt
• Ubuntu Security: php2shell, Fixes verfügbar (englisch)
• heise online: php2shell, Updates trudeln ein, viele Webseiten offline, Angriffe laufen
• teltarif.de: Behörden reihenweise offline
• SecurityWeek: PHP2Shell-Ausnutzung begann Tage vor den Patches (englisch)
• Amazon Threat Intelligence: PHP2Shell-Ausnutzung vor der Veröffentlichung (englisch)
• CISA: Critical Vulnerabilities in PHP Require Immediate Patching (englisch)
• Borns IT-Blog: php2shell, PHP-Updates und Nachlese