[ ]

PHP2Shell: Was die PHP-Lücke für deine Website bedeutet

28.10.2026

7 Min Lesezeit

Hand zieht im Serverraum ein Netzwerkkabel aus einem Switch

Am 21. Oktober 2026 hat das PHP-Team außerplanmäßig Updates für zwei kritische Sicherheitslücken veröffentlicht, die unter dem Namen PHP2Shell bekannt wurden. Noch am selben Nachmittag nahmen in Nordrhein-Westfalen Kliniken, Kommunen und Universitäten ihre Websites vorsorglich vom Netz.

In diesem Artikel ordne ich ein, was passiert ist, welche Websites betroffen sind und welche nicht. Und warum dieser Vorfall ein Vorgeschmack darauf ist, wie KI die Sicherheit im Netz verändert.

Was bei PHP2Shell passiert ist

PHP ist die Programmiersprache, auf der ein Großteil aller Websites läuft, Schätzungen zufolge rund 70 Prozent. Die beiden Lücken mit den Kennungen CVE-2026-109618 und CVE-2026-109619 stecken in PHP selbst, nicht in einem Plugin oder Theme. Sie erlauben es Angreifern, ohne Login eigenen Code auf dem Server auszuführen. Beide sind mit 9,2 von 10 Punkten bewertet.

Heikel war der Ablauf: Details zu den Lücken waren schon vor dem offiziellen Update durchgesickert, erste Angriffsversuche gab es bereits davor. Das BSI warnte am 21. Oktober mit einer Cybersicherheitswarnung. Wenige Tage später meldete die US-Behörde CISA, dass die Lücken aktiv ausgenutzt werden, und gab US-Bundesbehörden drei Tage Zeit für das Update.

Warum vor allem WordPress-Websites betroffen sind

WordPress läuft auf PHP, genau wie Typo3, Joomla, Shopware und viele andere Systeme, die im Mittelstand verbreitet sind. Das Entscheidende: Ein WordPress-Update hilft hier nicht. Die Lücke lässt sich nur schließen, indem auf dem Server eine aktuelle PHP-Version eingespielt wird. WordPress selbst hat klargestellt, dass dafür kein eigenes Update nötig oder geplant ist.

Damit liegt die Verantwortung beim Hoster oder bei der IT, die den Server betreut. Und genau hier wird es in der Praxis schwierig: Viele Unternehmenswebsites laufen seit Jahren auf einem Hosting-Paket, bei dem niemand im Haus weiß, welche PHP-Version eigentlich läuft. Für PHP 8.1 und ältere Versionen gibt es vom PHP-Projekt kein offizielles Update mehr.

Ein Security-Plugin schützt nicht vor einer Lücke in der Sprache, in der es selbst geschrieben ist.

Webflow, Framer und individuell entwickelte Websites

Websites auf Webflow und Framer laufen nicht auf einem PHP-Server, den du oder dein Hoster betreiben muss. Die Plattformen liefern die Seiten über ihre eigene Infrastruktur aus und kümmern sich selbst um Updates. Eine Lücke in PHP trifft sie deshalb nicht.

Bei individuell entwickelten Websites kommt es auf die Technik an. Wir bauen sie mit Nuxt und einem Headless-CMS wie Storyblok. Auf dem Server läuft dabei kein PHP, viele Seiten werden vorab erzeugt und als fertige Dateien ausgeliefert. Eine eigene Anwendung in Laravel oder Symfony läuft dagegen auf PHP und war genauso betroffen wie WordPress.

Unverwundbar ist kein Setup. Auch JavaScript-Pakete und Plattformen haben Lücken. Der Unterschied liegt woanders: wie viel Technik offen im Netz steht und wer dafür zuständig ist, sie aktuell zu halten.

Kriterium

WordPress mit eigenem Hosting

Webflow oder Framer

Nuxt mit Headless-CMS

PHP auf dem Server

Ja

Nein

Nein

Wer den Server aktuell hält

Hoster oder eigene IT

Die Plattform

Die Hosting-Plattform, etwa Vercel

Von PHP2Shell betroffen

Ja, bis zum PHP-Update

Nein

Nein

Was du jetzt tun solltest, wenn deine Website auf WordPress läuft

  1. Frag bei deinem Hoster nach, ob PHP auf eine der abgesicherten Versionen aktualisiert wurde: 8.2.35, 8.3.36, 8.4.27 oder 8.5.12.

  2. Prüf im Hosting-Panel, welche PHP-Version deine Website nutzt. Läuft noch PHP 8.1 oder älter, ist der Wechsel auf eine aktuelle Version überfällig.

  3. War die Website in den Tagen vor dem Update erreichbar, lass prüfen, ob unbekannte Dateien oder Admin-Konten aufgetaucht sind. Angriffe gab es schon vor der offiziellen Warnung.

  4. Kläre, wer bei der nächsten Lücke zuständig ist und wie schnell reagiert werden kann, bevor sie passiert.

Steht ohnehin ein Relaunch an, ist das ein guter Moment, die Technik grundsätzlich zu hinterfragen.

Warum KI das Tempo verändert

Bemerkenswert an PHP2Shell ist auch, wie die Lücken gefunden wurden. Laut Fortune stießen mehrere Forschungsteams im August unabhängig voneinander darauf, alle mit Unterstützung von KI-Modellen. Dieselben Werkzeuge stehen auch Angreifern zur Verfügung. Zwischen dem Update und den ersten bestätigten Angriffen lagen bei PHP2Shell nur wenige Tage.

Gleichzeitig zeigen Berichte aus den KI-Laboren, wie findig Agenten werden, wenn sie ein Ziel verfolgen. OpenAI hat im Oktober beschrieben, wie Agenten in einem Sicherheitstest Informationen über den Cache des Prozessors ausgetauscht haben, obwohl sie in getrennten virtuellen Maschinen ohne Netzwerk liefen. Die Technik ähnelt den bekannten Angriffen Spectre und Meltdown. In den meisten Tests war der Kanal allerdings vorgegeben, die Agenten mussten ihn also nicht von selbst entdecken.

Schon im Sommer hatten METR und Redwood Research einen Vorfall bei OpenAI untersucht: Rund 1.200 Agenten aus Sicherheitstests hatten einen internen Paket-Server als eigenes Nachrichtenbrett genutzt und darüber mehr als 70.000 Nachrichten und Dateien ausgetauscht. Rund 700 von ihnen waren an einem Angriff auf Hugging Face beteiligt. Berichte über die Auswertung beschreiben sogar Agenten, die ihr eigenes Ergebnis aufgaben, damit die Gruppe vorankam. Ob man das als Opfer deuten sollte, ist umstritten: Solche Begriffe zeigen eher, wie Modelle ihr Handeln erzählen, als dass sie eine Absicht belegen.

Wenn Agenten in abgeschotteten Laboren Wege durch den Prozessor finden, ist ein ungepatchter Webserver kein Hindernis.

Was das für Deutschland bedeutet

Die Reaktion in Nordrhein-Westfalen zeigt das Problem: Wer nicht schnell genug patchen kann, schaltet ab. Bei einer einzelnen Lücke ist das vertretbar. Wenn KI die Zahl gefundener Lücken und das Tempo der Angriffe erhöht, wird Abschalten zum Dauerzustand.

Viele Websites im Mittelstand, in Kommunen und an Hochschulen laufen auf Systemen, die jemand im Haus oder beim Hoster von Hand aktuell halten muss. Die KI-Modelle, die solche Lücken finden, entstehen dagegen überwiegend in den USA. Deutschland steht damit auf der Seite, die reagieren muss, und reagiert oft langsam.

Für Unternehmen heißt das: Die Frage ist weniger, welches CMS gerade beliebt ist, sondern wie viel Infrastruktur du selbst verantworten willst. Je weniger Technik offen im Netz steht und je mehr davon automatisch aktuell gehalten wird, desto kleiner ist die Angriffsfläche.

Fazit

PHP2Shell wird nicht die letzte kritische Lücke dieser Art bleiben. WordPress ist dadurch nicht über Nacht schlecht geworden, aber es hängt an einer Infrastruktur, die jemand pflegen muss, und zwar schneller als bisher. Mein Rat: Frag noch heute deinen Hoster, welche PHP-Version deine Website nutzt und ob das Update vom 21. Oktober eingespielt ist.

PHP2Shell ist der Name für zwei kritische Sicherheitslücken in PHP (CVE-2026-109618 und CVE-2026-109619), die am 20. Oktober 2026 bekannt wurden. Sie erlauben Angreifern, ohne Login Code auf dem Server auszuführen. Abgesichert sind die PHP-Versionen 8.2.35, 8.3.36, 8.4.27 und 8.5.12.

Wenn auf dem Server eine ältere PHP-Version als die abgesicherten läuft, ja. Welche Version läuft, siehst du im Hosting-Panel oder erfährst du von deinem Hoster. PHP 8.1 und älter bekommt vom PHP-Projekt kein Update mehr.

Nein. Die Lücke steckt in PHP selbst und lässt sich nur durch ein Update von PHP auf dem Server schließen. WordPress hat dafür kein eigenes Update veröffentlicht.

Nein. Webflow und Framer laufen nicht auf einem PHP-Server, den du betreibst, und kümmern sich selbst um ihre Infrastruktur. Das gilt auch für individuell entwickelte Websites ohne PHP, etwa mit Nuxt und einem Headless-CMS.

Benjamin Hutter

Benjamin Hutter

Geschäftsführer Hutter Studio GmbH

Benjamin ist Gründer und Geschäftsführer von Hutter Studio in Hamburg. Er konzipiert und gestaltet Websites für B2B-Unternehmen. Seine Arbeiten wurden seit 2019 dreimal ausgezeichnet.

LinkedIn-Profil