Wenn eine kritische Sicherheitslücke auftaucht: Wer kümmert sich eigentlich um Ihre Website?

Aktualisiert am 28.10.2026: Lage in Deutschland, Anzeichen eines Einbruchs, Notlösungen und ein Erklärvideo.

Am Mittwoch, dem 21. Oktober, kam gegen 16 Uhr die Meldung: Das PHP-Projekt hat zwei kritische Sicherheitslücken geschlossen. Für die meisten Vereine und Betriebe war das ein ganz normaler Mittwochnachmittag. Mitbekommen hat es kaum jemand.

Solche Meldungen erscheinen in Fachforen und auf Entwicklerseiten. Im Postfach eines Vereinsvorstands oder Handwerksbetriebs landen sie selten.

Deshalb eine Frage an Sie: Wer hätte es gemerkt, wenn Ihre Website betroffen gewesen wäre? Und hätte jemand nachgesehen?

Lieber schauen als lesen? Das Wichtigste zu PHP2Shell gibt es auch als Video, in gut fünf Minuten: PHP2Shell erklärt – auf YouTube ansehen

1. Was am 21. Oktober passiert ist

PHP ist die Programmiersprache, auf der WordPress läuft. Sie ist auf dem Server Ihres Hosters installiert, nicht in WordPress selbst. Ohne PHP zeigt eine WordPress-Seite gar nichts an.

Entdeckt wurden die Lücken schon im August 2026, mit Hilfe von KI. Am 20. Oktober wurde ihre Existenz öffentlich angekündigt, noch bevor es eine Korrektur gab. Die kam am 21. Oktober um 16 Uhr deutscher Zeit. Cloudflare meldete die ersten Angriffsversuche aber bereits um 9:43 Uhr am selben Morgen. Gut sechs Stunden, bevor es überhaupt einen Patch gab.

Die beiden Lücken laufen unter dem Namen „PHP2Shell“, offiziell CVE-2026-109618 und CVE-2026-109619. Beide sind mit 9,2 von 10 Punkten auf der CVSS-Skala bewertet. CVSS ist ein internationales Bewertungssystem für Sicherheitslücken. Ab 9 Punkten gilt eine Lücke als kritisch.

Praktisch heißt das: Ein Angreifer kann unter bestimmten Bedingungen eigenen Programmcode auf dem Server ausführen. Er braucht dafür kein Passwort. Der Fachbegriff lautet „Remote Code Execution“. Im schlimmsten Fall kommt er so an die Datenbank hinter der Website. Bei Vereinen liegen dort oft Mitgliederdaten oder Anmeldungen aus Formularen.

Betroffen sind alle PHP-Versionen von 5.4 bis 8.5, egal mit welchem Webserver PHP zusammenarbeitet. Theoretisch anfällig sind damit nicht nur WordPress-Seiten, sondern auch Shops und Systeme wie WooCommerce, Shopware, Magento, TYPO3, Drupal und Joomla. Laut Palo Alto Networks waren zum Zeitpunkt der Veröffentlichung weltweit 22,6 Millionen solcher Systeme offen aus dem Internet erreichbar.

Geschlossen ist die Lücke erst mit den neuen PHP-Versionen 8.2.35, 8.3.36, 8.4.27 und 8.5.12 oder einer höheren Nummer derselben Reihe.

2. Abschaltungen in ganz Deutschland, aber kein bestätigter Einbruch

Am 21. Oktober gingen in Deutschland reihenweise Websites vom Netz. Darunter die Charité, das Bundeskriminalamt, die Berliner Feuerwehr, das Klinikum Nürnberg, die Unikliniken in Freiburg, Heidelberg und Mannheim, die Landesregierungen von Hessen und Bayern, die Städte München, Dresden, Mainz, Düsseldorf und Bochum sowie die Universität Potsdam. An der Uni Freiburg waren auch die Lernplattform ILIAS und der Mailzugang der Studierenden betroffen.

Das klingt nach einem großen Angriff. Es war keiner.

Die Betreiber haben ihre Server selbst vom Netz genommen, aus Vorsicht. Ein erfolgreicher Einbruch über diese beiden Lücken ist bisher nicht bestätigt. Das BSI meldete am 22. Oktober keine bestätigten erfolgreichen Angriffe in der Bundesverwaltung. Die Sicherheitsforscher von Palo Alto Networks hatten zunächst einen Vorfall bei einer europäischen Behörde gemeldet. Am 25. Oktober haben sie das zurückgezogen: Der Vorfall lässt sich nicht eindeutig diesen Lücken zuordnen.

Entwarnung ist das trotzdem nicht. Das BSI, das Bundesamt für Sicherheit in der Informationstechnik, stuft die Lage auf Orange ein. Das heißt: unverzüglich Maßnahmen ergreifen. Die US-Behörde CISA hat beide Lücken am 26. Oktober in ihre Liste aktiv ausgenutzter Schwachstellen aufgenommen. Gezählt werden Millionen automatisierter Angriffsversuche, die ersten davon mit echter Schadsoftware.

Ganz so einfach wie damals bei Log4Shell ist ein Angriff allerdings nicht. Nach Einschätzung der Sicherheitsfirma Sansec braucht er genaues Wissen über den Zielserver und bestimmte Bedingungen dort. Einen Angriff mit einer einzigen Anfrage, der überall funktioniert, gibt es nach heutigem Stand nicht.

Bemerkenswert finde ich vor allem eins: Kliniken und Landesregierungen sind freiwillig offline gegangen, bevor überhaupt ein erfolgreicher Angriff nachgewiesen war. So ernst wurde diese Lücke genommen.

3. Ein WordPress-Update hilft hier nicht

Im WordPress-Dashboard erscheint eine kleine Zahl, sobald Updates bereitstehen. Wer die regelmäßig abarbeitet, macht vieles richtig. Bei dieser Lücke reicht das allerdings nicht.

Die Lücke steckt eine Ebene tiefer. Sie können WordPress, Theme und Plugins komplett auf den neuesten Stand bringen. Die PHP-Version auf dem Server bleibt davon unberührt. Austauschen kann sie nur, wer den Server betreibt. In den allermeisten Fällen ist das Ihr Hoster.

Auch eine Web Application Firewall, kurz WAF, schützt hier nicht zuverlässig. Das ist ein Filter, der verdächtige Anfragen abfangen soll, bevor sie die Website erreichen. Der Angriff läuft aber innerhalb von PHP ab, bevor WordPress überhaupt etwas davon mitbekommt.

Sie sind also darauf angewiesen, dass Ihr Hoster schnell reagiert und dass jemand prüft, ob er es getan hat.

4. Wie der Abend bei mir ablief

Der Patch war am 21. Oktober um 16 Uhr verfügbar. Noch am selben Abend habe ich meine Kunden informiert: was passiert ist, ob ihre Seite betroffen sein kann und wie es weitergeht. Danach habe ich jede Seite, die ich betreue, einzeln geprüft. Welche PHP-Version läuft? Hat der Hoster schon nachgezogen?

Ein Hoster hat für das Update über 28 Stunden gebraucht. In dieser Zeit war die Lücke öffentlich bekannt und auf dem Server noch offen.

Meine Kunden wussten davon, und ich habe weiter geprüft, bis das Update tatsächlich installiert war.

5. Der Sonderfall: eine Website, für die es keinen Patch gibt

Auf einer Kundenseite lief PHP 7.0.33. Diese Version bekommt seit Anfang 2019 keine Sicherheitsupdates mehr. Für sie wird es auch keinen Patch mehr geben.

Solche Seiten sind keine Seltenheit. Sie wurden irgendwann gebaut und laufen seitdem ohne Probleme, bis eine Lücke wie diese auftaucht.

Dann bleibt nur ein Weg: die Website auf eine aktuelle PHP-Version umstellen. Das ist oft mehr als ein Klick beim Hoster. Ältere Themes und Plugins vertragen sich nicht immer mit neuem PHP, und manches muss vorher angepasst werden.

Eine Website auf einer PHP-Version ohne Sicherheitsupdates bleibt deshalb ein dauerhaftes Risiko. Mit jeder neuen Lücke kommt ein Problem dazu, das sich auf dieser Version nicht mehr beheben lässt.

6. Woran Sie erkennen, ob Ihre Website betreut ist

Ein paar Fragen helfen bei der Einordnung. Beantworten Sie sie für Ihre eigene Seite:

• Hat Ihnen im Oktober jemand Bescheid gegeben, dass es eine kritische PHP-Lücke gibt?
• Wissen Sie, welche PHP-Version auf Ihrem Server läuft?
• Wissen Sie, wie Sie Ihren Hoster erreichen und wer dort für Updates zuständig ist?
• Gibt es eine Person, die Ihre Website technisch im Blick hat? Also nicht nur die Inhalte, sondern auch Server und Software dahinter.
• Bei Vereinen: Weiß der aktuelle Vorstand das alles, oder lag das Wissen beim Vorgänger?

Wenn Sie bei mehr als einer Frage zögern, ist für Ihre Website bisher niemand klar zuständig. Das lässt sich mit überschaubarem Aufwand klären.

7. Was Sie jetzt konkret tun können

Prüfen Sie zuerst die PHP-Version. In WordPress finden Sie sie unter „Werkzeuge“ > „Website-Zustand“ > „Bericht“, im Abschnitt „Server“. Bei anderen Systemen steht sie im Kundenbereich Ihres Hosters, meist unter „PHP-Version“ oder „PHP-Einstellungen“.

Steht dort 8.2.35, 8.3.36, 8.4.27, 8.5.12 oder eine höhere Nummer derselben Reihe, ist die Lücke geschlossen. Steht dort eine niedrigere Nummer, fragen Sie bei Ihrem Hoster nach. Manche Hoster spielen die Korrektur ein, ohne dass sich die angezeigte Nummer ändert. Dann lässt sich das nur über eine Bestätigung des Hosters klären.

Beginnt die Versionsnummer mit einer 7 oder einer 5, gibt es keinen Patch. Dann steht eine Umstellung an. Die sollte jemand begleiten, der Website und Server kennt.

Wenn das Update noch nicht möglich ist: Sansec nennt zwei Notlösungen auf dem Server. Anfragen vom Typ multipart/form-data lassen sich auf Webserver-Ebene blockieren, und in PHP lässt sich die Einstellung session.upload_progress.enabled = 0 setzen. Das überbrückt die Zeit bis zum Update, ersetzt es aber nicht. Umsetzen muss das Ihr Hoster oder wer Ihren Server betreut.

Nach dem Update: auf Anzeichen eines Einbruchs prüfen. Diese Spuren deuten darauf hin, dass schon jemand eingedrungen ist:

• neue oder veränderte PHP-Dateien, besonders im Upload-Ordner
• neue Administratoren in WordPress, neue Benutzer auf dem Server, neue Cronjobs (zeitgesteuerte Aufgaben)
• ein PHP-Prozess, der plötzlich eine Kommandozeile oder Download-Werkzeuge wie curl oder wget startet
• auffällige Multipart-Anfragen in den Zugriffsprotokollen des Servers
• fremde Weiterleitungen auf Ihrer Website

Neue Administratoren sehen Sie selbst in WordPress unter „Benutzer“. Für die übrigen Punkte braucht es Zugriff auf den Server. Das ist ein Fall für Ihren Hoster oder Ihren Dienstleister.

Und unabhängig von dieser Lücke: Klären Sie, wer beim nächsten Mal hinschaut. Kritische Lücken wie diese tauchen immer wieder auf, und niemand kann vorhersagen, wann die nächste kommt.

Ich betreue Websites für Vereine und Betriebe im Saarland und bin dabei Ihr direkter Ansprechpartner, auch nach dem Launch. Wenn Sie nach diesem Beitrag unsicher sind, wie es um Ihre Seite steht, schreiben Sie mir. Ich schaue mir das mit Ihnen an.

Quellen: BSI, Cybersicherheitswarnung 2026-297981-1032 · Palo Alto Unit 42 · Sansec · Rapid7 · watchTowr · Huntress · Borns IT-Blog

Stand der Informationen: 27.10.2026. Dieser Beitrag gibt allgemeine Hinweise und ersetzt keine individuelle Beratung.