Am 21. Oktober 2026 hat das PHP-Projekt ein dringendes Sicherheitsupdate veröffentlicht. Es schließt zwei kritische Schwachstellen, die unter dem Namen PHP2Shell bekannt wurden (CVE-2026-109618 und CVE-2026-109619) und mit 9,2 von 10 Punkten auf der Gefahrenskala fast den Höchstwert erreichen. Das Tückische daran: Angreifer benötigen weder ein Passwort noch andere Zugangsdaten. Eine einzige manipulierte Anfrage an den Webserver genügt, um eigenen Code auf dem Server auszuführen.

Laut den Sicherheitsforschern von Rapid7 betrifft das nahezu alle PHP-Installationen, die Webanfragen entgegennehmen – ganz gleich, ob sie über PHP-FPM, Apache (mod_php) oder LiteSpeed laufen. Und die Lücke wird bereits aktiv ausgenutzt: Amazon registrierte erste Angriffsversuche schon am 17. Oktober, also vier Tage bevor die Schwachstelle überhaupt öffentlich wurde. Seit dem 21. Oktober beobachtet zudem das Sicherheitsunternehmen watchTowr Angriffe auf seine Testsysteme.

Warum es WordPress-Websites besonders hart trifft

WordPress basiert auf der Programmiersprache PHP. Bei jedem Seitenaufruf startet der Webserver im Hintergrund PHP, um die angefragte Seite für den Besucher zusammenzubauen. Das Problem bei PHP2Shell: Die Sicherheitslücken stecken nicht in WordPress selbst, sondern eine Etage tiefer – direkt im PHP-Interpreter des Servers. Laut Rapid7 lässt sich eine der beiden Schwachstellen sogar ausnutzen, bevor überhaupt die erste Zeile WordPress-Code ausgeführt wird.

Für Website-Betreiber hat das eine bittere Konsequenz: Eine vorbildlich gepflegte WordPress-Seite mit aktuellem Systemkern, frischen Plugins und einem Sicherheits-Plugin war genauso angreifbar wie eine seit Jahren vernachlässigte Installation. Die gewohnte Routine, im WordPress-Backend auf „Aktualisieren“ zu klicken, läuft hier ins Leere. Das Update muss direkt auf dem Server eingespielt werden – und genau darauf haben viele Betreiber keinen Zugriff.

Wer kümmert sich eigentlich um Ihr PHP?

Die meisten Websites kleinerer und mittlerer Unternehmen liegen auf sogenanntem Shared Hosting. Dort entscheidet allein der Hosting-Anbieter, welche PHP-Versionen zur Verfügung stehen und wann Sicherheitsupdates eingespielt werden. Ein guter Hoster hat die Lücke noch am 21. Oktober geschlossen. Ob das auch bei Ihrem Anbieter passiert ist, erfahren Sie im Zweifel nur, wenn Sie aktiv nachfragen.

Richtig kompliziert wird es bei älteren PHP-Versionen:

  • PHP 8.2 bis 8.5: Nur für diese aktuellen Versionen gibt es fertige Sicherheitsupdates.
  • PHP 7.4, 8.0 und 8.1: Hierfür hat das PHP-Projekt lediglich den rohen Programmcode für die Korrektur veröffentlicht, aber keine fertigen Update-Pakete.
  • PHP 5.4 bis 7.3: Diese veralteten Versionen sind ebenfalls verwundbar, gehen bei den Updates aber komplett leer aus.

Ein Blick in die aktuelle Statistik von WordPress.org zeigt, wie groß das Problem ist: Mehr als jede dritte WordPress-Website läuft auf einer veralteten PHP-Version (rund 30 % nutzen PHP 7.4 bis 8.1, weitere 5 % noch ältere Versionen). All diese Websites sind jetzt darauf angewiesen, dass ihr Hoster den fehlenden Schutz eigenhändig nachrüstet – oder sie müssen kurzfristig auf eine neue PHP-Version umziehen. Ob das eigene Design-Theme und ältere Plugins einen solchen Versionssprung ohne Fehler überstehen, steht auf einem anderen Blatt.

Was Sie jetzt tun sollten

  1. PHP-Version prüfen: Schauen Sie im WordPress-Backend unter Werkzeuge › Website-Zustand › Bericht im Abschnitt Server nach, welche PHP-Version Ihre Website aktuell nutzt.
  2. Beim Hoster nachhaken: Fragen Sie Ihren Anbieter schriftlich, ob die Sicherheitsupdates vom 21. Oktober bereits eingespielt sind. Gut zu wissen: Verlassen Sie sich nicht blind auf die Versionsnummer im Backend. Viele Linux-Server zeigen weiterhin ältere Versionsnummern an, obwohl der Hoster die Sicherheitskorrekturen im Hintergrund längst eingepflegt hat (sogenanntes Backporting).
  3. Wechsel auf PHP 8.2+ planen: Läuft Ihre Website noch auf einer Version ohne Update und Ihr Hoster bessert nicht selbst nach, führt kein Weg an einem Wechsel auf mindestens PHP 8.2 vorbei. Testen Sie diesen Schritt unbedingt vorab an einer Kopie Ihrer Website, um böse Überraschungen im Live-Betrieb zu vermeiden.
  4. Im Zweifel kurzzeitig abschalten: Lässt sich Ihre Website nicht zeitnah absichern, ist es durchaus vertretbar, sie vorübergehend vom Netz zu nehmen. Genau diesen Schritt empfehlen im aktuellen Fall sowohl die britische Cybersicherheitsbehörde NCSC als auch die US-amerikanische NSA.
  5. Auf Einbruchsspuren prüfen: Da erste Angriffe schon vor dem 21. Oktober liefen, reicht ein bloßes Update möglicherweise nicht aus. Achten Sie auf verdächtige Veränderungen der letzten Tage: Gibt es unbekannte Administratoren-Konten, neue Dateien im Webverzeichnis oder seltsame Weiterleitungen? Falls ja, lassen Sie die Website gründlich prüfen, bevor Sie zur Tagesordnung übergehen.

Was der Vorfall über den Website-Betrieb verrät

PHP2Shell ist ein Ausnahmefall. Doch er führt uns vor Augen, aus wie vielen Schichten eine typische WordPress-Website eigentlich besteht: Systemkern, Theme, Plugins, PHP und darunter der Webserver. Jede dieser Schichten erhält Updates von einem anderen Anbieter – und für jede braucht es jemanden, der sich verantwortlich fühlt. Im Alltag gerät das leicht in Vergessenheit, weil WordPress die sichtbaren oberen Ebenen bequem per Klick aktualisiert. PHP und Webserver darunter bleiben dem Hoster überlassen, oft ohne dass Betreiber wissen, wie zuverlässig dort gearbeitet wird.

Hinzu kommt eine grundsätzliche Frage der Bauweise: Bei den meisten Websites rechnet der Server bei jedem einzelnen Seitenaufruf im Hintergrund mit, obwohl sich die Inhalte monatelang kaum ändern. Eine klassische Unternehmensseite mit Leistungsübersicht, Teamvorstellung und Kontaktformular muss ihre Startseite aber nicht tausendmal am Tag neu zusammenbauen.

Es geht auch anders: Wird die Website vorab als statisches HTML erzeugt, liefert der Server an Besucher nur noch fertige Dateien aus. Es läuft kein PHP-Interpreter mehr im Hintergrund, den eine manipulierte Anfrage erreichen könnte – Lücken wie PHP2Shell laufen schlicht ins Leere. (Genauso ist übrigens auch diese Website gebaut; für das Kontaktformular genügt ein kleiner, eigenständiger Dienst, der getrennt von den Seiten läuft und sich gezielt warten lässt.)

Natürlich ist das nicht für jedes Projekt der richtige Weg. Ein Online-Shop oder ein interaktives Kundenportal braucht zwingend Programmcode, der live auf dem Server arbeitet – unabhängig von der verwendeten Programmiersprache. Entscheidend ist am Ende nur eines: Es muss von vornherein feststehen, wer welche Schicht Ihrer Website im Blick behält und am Tag eines kritischen Sicherheitsupdates sofort handelt.

Quellen