- Stand: 21. Oktober 2026, 17 Uhr. Zwei kritische Lücken in PHP (CVE-2026-109618 und CVE-2026-109619, Schweregrad 9,2 von 10) erlauben Angreifern, ohne Anmeldung Schadcode auf Webservern auszuführen.
- Seit dem 21. Oktober 2026, 16 Uhr, gibt es Updates: PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Für PHP 8.1 und älter gibt es vom PHP-Projekt selbst keinen Fix mehr.
- Ein aktuelles WordPress oder aktuelle Plugins schützen nicht. Entscheidend ist die PHP-Version auf dem Server.
- Websites, bei denen der Server nur fertige HTML-, CSS- und Bilddateien ausliefert, bieten dieser Lücke keine Angriffsfläche.
Was ist passiert? PHP2Shell in Kürze
Am 20. Oktober 2026 tauchte im Forum Hacker News ein Beitrag auf, der zwei kritische Lücken in PHP ankündigte. Der Beitrag verschwand schnell wieder, doch Screenshots machten bereits die Runde. Das Sicherheitsunternehmen watchTowr bestätigte, dass die Lücken echt sind, und konnte eine davon nachstellen. Eigentlich sollten die Details erst später veröffentlicht werden, gemeinsam mit den Updates.
Das PHP-Team reagierte noch am selben Abend und zog seine Sicherheitsupdates vor: auf Mittwoch, den 21. Oktober 2026, 16 Uhr deutscher Zeit. Die beiden Lücken tragen die Kennungen CVE-2026-109618 und CVE-2026-109619 und haben jeweils einen Schweregrad von 9,2 auf einer Skala bis 10. Sicherheitsforscher nennen sie „PHP2Shell“, in Anlehnung an die berüchtigte Lücke Log4Shell aus dem Jahr 2021.
Das Bundesamt für Sicherheit in der Informationstechnik (BSI) warnte mit der Warnstufe 3 (Orange) und rechnet damit, dass Angreifer die Lücken innerhalb weniger Stunden nach Erscheinen der Updates in großem Stil ausnutzen. BSI-Vizepräsident Thomas Caspers bringt es auf den Punkt: „Es besteht also unverzüglicher Handlungsbedarf!“ Die Stadt Mainz nahm laut dpa ihr Portal mainz.de und weitere Online-Dienste vorsorglich vom Netz.
Einfach erklärt: Was hat PHP mit Ihrer Website zu tun?
Wer nicht täglich mit Technik zu tun hat, fragt sich zu Recht: Was ist PHP eigentlich, und warum betrifft mich das? Ein Bild aus dem Alltag hilft.
Stellen Sie sich Ihre Website wie ein Restaurant vor. Ihre Besucher sitzen im Gastraum und sehen nur, was auf dem Teller landet: Texte, Bilder, Ihr Kontaktformular. Bei den meisten Websites wird jede Seite aber erst in dem Moment zubereitet, in dem jemand sie aufruft. Das passiert in der Küche, und der Koch in dieser Küche heißt bei sehr vielen Websites PHP. Wer WordPress, Shopware oder ein ähnliches System nutzt, hat diesen Koch im Haus, oft ohne es zu wissen.
PHP2Shell ist ein Fehler in der Ausbildung dieses Kochs. Mit einer gezielt präparierten Bestellung kann ein Fremder ihn dazu bringen, die Kontrolle über die Küche abzugeben, ganz ohne Schlüssel und ohne dass jemand im Gastraum etwas bemerkt. Wer die Küche kontrolliert, kann sich an allem bedienen, was dort lagert, oder den Gästen etwas anderes servieren als geplant.
Für Sie heißt das ganz praktisch: Nicht Sie oder Ihre Inhalte haben etwas falsch gemacht. Das Problem steckt in der Technik, auf der Ihre Website läuft. Deshalb hilft auch kein neues Passwort, sondern nur ein Update dieser Technik, und das erledigt in den meisten Fällen Ihr Hoster oder Ihre Agentur.
Genau deshalb baue ich Websites grundsätzlich als statische HTML- und CSS-Seiten. Um im Bild zu bleiben: Jede Seite wird vorab fertig zubereitet und steht bereit wie ein angerichtetes Buffet. Hinter den Seiten arbeitet kein PHP-System, kein CMS und keine Datenbank, also auch kein Koch, den jemand austricksen könnte. Das ist nicht nur sicherer, sondern auch zeitgemäß und deutlich schneller, weil beim Aufruf nichts mehr zubereitet werden muss. Wie ich das umsetze, sehen Sie unter Webdesign & Betreuung.
Warum diese Lücke so ernst ist
Sicherheitslücken in Websites gibt es ständig. Die meisten stecken in einem einzelnen Plugin oder Theme und betreffen nur die Seiten, die genau diese Erweiterung nutzen. PHP2Shell ist anders: Die Fehler liegen im Kern von PHP selbst, also in der Technik, auf der die Website läuft.
Laut dem offiziellen Sicherheitshinweis des PHP-Projekts sind alle PHP-Installationen betroffen, die Anfragen aus dem Web verarbeiten, egal ob über PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP oder LiteSpeed. Am gefährlichsten ist die Variante mod_php: Hier wurde gezeigt, dass eine einzige Anfrage ohne Anmeldung den Angriff auslösen kann, noch bevor überhaupt der Code der Website läuft.
Remote Code Execution, kurz RCE, bedeutet, dass ein Angreifer aus der Ferne eigene Befehle auf einem fremden Server ausführen kann. Er braucht dafür weder ein Passwort noch Zugang zum Admin-Bereich. Im schlimmsten Fall übernimmt er damit die volle Kontrolle über die Website und alles, was auf dem Server liegt.
Was Angreifer mit einer übernommenen Website anstellen können, ist bekannt: Kundendaten abgreifen, Schadsoftware an Besucher verteilen oder unbemerkt Hunderte Spam-Seiten anlegen, die auf fremde Angebote verlinken. Gerade Letzteres trifft die Sichtbarkeit hart. Google kennzeichnet gehackte Websites in den Suchergebnissen und meldet Sicherheitsprobleme in der Search Console. Bis Vertrauen und Rankings zurück sind, kann es dauern.
Dazu kommt das Tempo. Das BSI geht davon aus, dass Angreifer die veröffentlichten Updates mit KI-gestützten Werkzeugen auswerten und daraus sehr schnell funktionierende Angriffe bauen. Zwischen Update und Angriffswelle liegen damit nicht mehr Wochen, sondern Stunden.
Ist Ihre Website betroffen?
Die kurze Antwort: Wenn Ihre Website mit WordPress, Joomla, Drupal, TYPO3, Shopware, Magento oder einem anderen System auf PHP-Basis läuft, ist sie grundsätzlich betroffen, solange auf dem Server keine aktualisierte PHP-Version läuft. Das gilt auch für Kontaktformulare, Buchungstools oder Kundenbereiche, die mit PHP arbeiten.
Ein wichtiger Punkt, der oft missverstanden wird: Ein aktuelles WordPress, aktuelle Plugins oder ein Sicherheits-Plugin schützen Sie hier nicht. Die Lücke sitzt eine Ebene tiefer. Entscheidend ist allein, welche PHP-Version auf Ihrem Server läuft.
Abgesichert sind diese Versionen: PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Wer noch PHP 8.1 oder älter nutzt, bekommt vom PHP-Projekt selbst kein offizielles Update mehr. Für PHP 7.4, 8.0 und 8.1 gibt es lediglich Code-Korrekturen für Fachleute, die PHP selbst kompilieren, dazu Updates mancher Linux-Distributionen und kommerzieller Anbieter. Für alles darunter bleibt nur der Umstieg auf eine aktuelle Version.
Wenn Ihre Website bei einem Hoster liegt, spielt in der Regel der Hoster die Updates ein. Sie sollten sich aber nicht darauf verlassen, dass das bereits passiert ist, sondern es prüfen.
Was Sie jetzt sofort tun sollten
Die gute Nachricht: Für die meisten Unternehmen ist die Lösung kein Großprojekt. Diese Schritte haben heute Vorrang:
1. PHP-Version prüfen und aktualisieren. Schauen Sie im Kundenbereich Ihres Hosters nach, welche PHP-Version Ihre Website nutzt, und stellen Sie auf eine aktuelle Version um. Ist dort nichts zu erkennen, fragen Sie Ihren Hoster direkt, ob die Updates vom 21. Oktober eingespielt sind. Das PHP-Projekt sagt klar: Nur das Update löst das Problem vollständig.
2. Veraltete Versionen nicht laufen lassen. Läuft Ihre Seite noch mit PHP 7 oder älter, ist jetzt der Zeitpunkt für den Umstieg. Bedenken Sie dabei: Auch PHP 8.2 erhält nur noch bis zum 31. Dezember 2026 Sicherheitsupdates.
3. Eine Sicherung anlegen. Eine aktuelle Sicherung von Dateien und Datenbank, getrennt vom Server gespeichert, ist im Ernstfall Ihre Lebensversicherung.
4. Auf Auffälligkeiten achten. Unbekannte Dateien, neue Benutzerkonten, plötzlich auftauchende fremdsprachige Seiten bei Google oder Warnungen in der Search Console unter „Sicherheitsprobleme“ sind Alarmzeichen. Ziehen Sie dann sofort Fachleute hinzu.
5. Notfalls vorübergehend offline gehen. Lässt sich das Update nicht kurzfristig einspielen, empfehlen BSI und CERT-EU, betroffene Systeme vom Netz zu nehmen, bis der Schutz steht. Eine zusätzliche Schutzschicht wie eine Web Application Firewall, etwa die Regeln, die Cloudflare dafür bereitgestellt hat, kann helfen, ersetzt das Update aber nicht.
Das eigentliche Problem: Jede Technik will gepflegt werden
Die Updates sind da, und viele Hoster spielen sie gerade ein. Die eigentliche Frage bleibt aber: Wie viel Technik braucht Ihre Website überhaupt?
Eine klassische Website mit Content-Management-System setzt jede Seite erst in dem Moment zusammen, in dem jemand sie aufruft. Dafür arbeiten im Hintergrund PHP, eine Datenbank, das System selbst, ein Theme und meist eine ganze Reihe Plugins. Jede dieser Schichten ist Software, und jede Software kann Lücken haben. Diesmal war es nicht ein Plugin, sondern das Fundament. Beim nächsten Mal ist es wieder eine Erweiterung, ein Formular oder das System selbst.
Für viele Unternehmen heißt das: Updates, Sicherheitswarnungen und Notfall-Termine gehören zum Alltag, obwohl sich die Inhalte der eigenen Website nur ein paar Mal im Monat ändern. Meiner Erfahrung nach ist genau das bei vielen Unternehmensseiten ein Missverhältnis: viel bewegliche Technik für eine Website, die im Kern Informationen zeigt und Anfragen gewinnen soll.
Eine Website mit CMS ist wie ein Ladenlokal mit Haupteingang, Lieferantentür, Kellerfenster und Hintertür. Jede Tür ist praktisch, aber jede muss abgeschlossen und regelmäßig geprüft werden. Eine statische Website ist eher ein gut beleuchtetes Schaufenster: Jeder sieht alles, was er sehen soll, aber es gibt keine Tür, durch die jemand hineinkommt.
Statische Websites: Wo nichts ausgeführt wird, kann nichts angegriffen werden
Bei einer statischen Website wird jede Seite einmal sorgfältig gebaut und dann als fertige Datei auf den Server gelegt: HTML für die Inhalte, CSS für die Gestaltung, dazu Bilder und Schriften. Ruft jemand die Seite auf, liefert der Server einfach diese Dateien aus. Es läuft kein PHP, es gibt keine Datenbank und keinen Login-Bereich, den jemand angreifen könnte.
Für eine Lücke wie PHP2Shell bedeutet das: Wird keine Anfrage an PHP weitergereicht, gibt es auch nichts, was ein Angreifer auslösen könnte. Dasselbe gilt für die typischen Lücken in Plugins, Themes und Datenbanken. Sie existieren auf einer rein statischen Website schlicht nicht. Braucht ein statischer Auftritt doch einmal eine Funktion auf dem Server, etwa für ein Kontaktformular, setze ich auf ein einzelnes, schlankes Skript statt auf ein ganzes System. Dann muss die PHP-Version beim Hoster natürlich ebenfalls aktuell sein, aber die Angriffsfläche und der Pflegeaufwand sind um ein Vielfaches kleiner.
Der Sicherheitsgewinn ist dabei nur ein Teil der Rechnung. Statische Seiten sind auch spürbar schneller, weil der Server nichts mehr berechnen muss. Das zahlt direkt auf die Core Web Vitals ein, also die Werte, mit denen Google Ladezeit und Bedienbarkeit bewertet. Wie schnell eine statische Website sein kann, sehen Sie an meiner eigenen Seite:
ctseo.de erreicht 100 % bei Google
Tempo ist kein Nice-to-have. Google wertet Ladezeit und Core Web Vitals als Ranking-Faktor, und schnelle Seiten halten Besucher und gewinnen mehr Anfragen. Was ich für meine Kunden umsetze, sehen Sie direkt an dieser Seite, gemessen ganz offiziell mit Google PageSpeed Insights. Sogar KI-Agenten lesen und bedienen die Seite einwandfrei, ein direkter Vorteil für Ihre Sichtbarkeit in KI-Systemen.
Bestwerte bei Google PageSpeed Insights. Die Werte können je nach Messung leicht variieren, prüfen Sie es gern selbst.
Dazu kommt: Statische Seiten lassen sich besonders sauber für Suchmaschinen und KI-Systeme aufbauen. Klare Struktur, strukturierte Daten und schnelle Antwortzeiten machen es Google, ChatGPT und Co. leicht, Ihre Inhalte zu lesen und zu verstehen. Genau so baue ich jede Website für meine Kunden: als statische HTML- und CSS-Seite ohne PHP-System dahinter. Für Unternehmensseiten ist das heute der zeitgemäße Weg: kürzere Ladezeiten, deutlich weniger Angriffsfläche, kaum Wartungsaufwand und von Anfang an für Suche und KI gedacht.
Für wen sich der Wechsel lohnt und für wen nicht
Eine statische Website ist kein Allheilmittel, und ich empfehle sie nicht pauschal. Sie passt hervorragend, wenn Ihre Website vor allem informiert und Anfragen gewinnen soll. Das trifft auf die meisten Unternehmensseiten zu: Kanzleien, Praxen, Handwerksbetriebe, Dienstleister und Berater.
Weniger geeignet ist sie, wenn Ihre Website im Kern eine Anwendung ist: ein großer Onlineshop mit Warenkorb und Kundenkonto, ein Mitgliederbereich oder ein Portal, in dem viele Personen täglich Inhalte einstellen. Dort braucht es serverseitige Technik, und dann ist konsequente Pflege der richtige Weg.
Wichtig beim Umstieg ist, dass Ihre bisherige Sichtbarkeit erhalten bleibt. Adressen, Inhalte und Weiterleitungen müssen sauber geplant sein, sonst verlieren Sie Rankings, die Sie über Jahre aufgebaut haben. Worauf es dabei ankommt, beschreibe ich ausführlich im Beitrag zum Website-Relaunch. Ein angenehmer Nebeneffekt: Wer ohnehin neu baut, kann auch gleich auf Plugins für Statistik und Cookie-Banner verzichten. Wie das geht, zeige ich im Beitrag über Cookieless Tracking.
Fazit: Heute patchen, morgen die Grundsatzfrage stellen
PHP2Shell ist eine der schwersten Lücken der letzten Jahre, weil sie das Fundament von Millionen Websites betrifft. Wenn Ihre Website mit PHP läuft, hat heute nur eines Vorrang: Prüfen Sie die PHP-Version, lassen Sie das Update einspielen und behalten Sie Ihre Seite in den nächsten Tagen im Blick.
Danach lohnt sich ein ehrlicher Blick auf die Grundsatzfrage: Braucht Ihre Website wirklich so viel Technik? Für viele Unternehmen ist eine schlanke, statische Website die sicherere, schnellere und pflegeleichtere Lösung. Wenn Sie wissen möchten, auf welcher Technik Ihre Seite heute läuft und ob sich ein Wechsel für Sie lohnt, schaue ich mir das gern kostenlos mit Ihnen an.
Häufige Fragen
Am einfachsten im Kundenbereich Ihres Hosters, dort ist die PHP-Version meist pro Website einstellbar. Bei WordPress zeigt außerdem der Bereich „Website-Zustand“ unter „Werkzeuge“ die verwendete Version an. Wenn Sie unsicher sind, fragen Sie Ihren Hoster oder Ihre Agentur direkt.
Bei klassischem Webhosting spielt in der Regel der Hoster die PHP-Updates ein. Häufig wählen Sie aber selbst, welche PHP-Version Ihre Website nutzt. Ist dort noch eine alte Version eingestellt, bleibt Ihre Seite angreifbar, auch wenn der Hoster neuere Versionen längst anbietet.
Nein. Laut PHP-Projekt kann der Angriff ausgelöst werden, bevor der Code der Website überhaupt läuft. Ein Plugin, das Teil dieses Codes ist, kommt dann zu spät. Schutz bietet nur eine aktualisierte PHP-Version.
Der Wert stammt aus dem Common Vulnerability Scoring System, kurz CVSS, einem internationalen Standard zur Bewertung von Sicherheitslücken. Die Skala reicht bis 10. Werte ab 9 gelten als kritisch, also als Lücken, die sofort geschlossen werden sollten.
Typische Hinweise sind unbekannte Dateien oder Benutzerkonten, fremde Seiten, die bei Google unter Ihrer Domain auftauchen, plötzliche Weiterleitungen und Warnungen im Browser oder in der Google Search Console. Im Verdachtsfall sollten Sie Protokolle sichern und Fachleute hinzuziehen, statt selbst Dateien zu löschen.
Das kann passieren. Google kann gehackte Websites in den Suchergebnissen kennzeichnen, und eingeschleuste Spam-Seiten verwässern das Bild Ihrer Website. Nach der Bereinigung lässt sich in der Search Console eine Überprüfung beantragen. Bis Vertrauen und Rankings vollständig zurück sind, braucht es aber oft Zeit.
Absolute Sicherheit gibt es nie. Auch bei einer statischen Website müssen Zugänge zum Hosting, zur Domain und zu E-Mail-Konten gut geschützt sein. Die typischen Angriffe auf Systeme, Plugins und Datenbanken laufen bei einer rein statischen Seite aber ins Leere, weil diese Technik dort gar nicht existiert.
Das hängt von der Lösung ab. Bei den meisten Unternehmensseiten ändern sich Inhalte nur gelegentlich. Bei den statischen Websites, die ich baue, übernehme ich Änderungen auf Wunsch im Rahmen der Betreuung. So sparen Sie sich die Pflege eines eigenen Systems. Was zu Ihrem Alltag passt, klären wir vorab gemeinsam.
Ja, wenn sie auf PHP basieren, etwa mit WooCommerce, Shopware oder Magento. Shops verarbeiten zudem Kundendaten und Zahlungen, deshalb ist hier besondere Eile geboten. Ein großer Shop lässt sich in der Regel nicht statisch umsetzen, hier sind schnelle Updates und eine konsequente Wartung der richtige Weg.
Das PHP-Projekt pflegt jede Version nur für einen begrenzten Zeitraum. Danach gibt es keine Sicherheitsupdates mehr, auch nicht bei schweren Lücken wie PHP2Shell. Betroffen sind derzeit PHP 8.1 und alle älteren Versionen. PHP 8.2 erhält noch bis zum 31. Dezember 2026 Sicherheitsupdates.