Wir haben diese Behauptung analysiert: Stimmt es, dass
PHP2Shell gefährdet Internetseiten mit anfälligen PHP-Installationen unabhängig vom eingesetzten Content-Management-System, während die Verantwortung für das Einspielen der Sicherheitskorrekturen davon abhängt, wer die Serverumgebung verwaltet?
Offizielle Sicherheitsmeldungen und unabhängige Analysen belegen, dass PHP2Shell die zugrunde liegende Programmiersprache PHP und nicht einzelne Redaktionswerkzeuge betrifft, womit die Update-Pflicht je nach Systemarchitektur zwischen Webhosting-Anbietern, Plattformbetreibern und Administratoren eigener Server aufgeteilt ist.
Sicherheitslücke PHP2Shell bedroht Millionen Webseiten – Patch-Pflicht spaltet Netzbetreiber
Ein schwerer Speicherfehler gefährdet Server weltweit, doch die Behebung lässt sich nicht über herkömmliche Redaktionssysteme einspielen.
Die Geschichte geht weiter
Sicherheitslücke in Websoftware setzt Unternehmensfirewalls unter Zugzwang
31. Oktober 2026Führende IT-Ausrüster stellen Notfall-Updates bereit, doch Firmennetzwerke bleiben wegen schleppender Nachbesserungen vorerst verwundbar.
Warum Sicherheitsupdates allein Webseiten nicht mehr ausreichend schützen
30. Oktober 2026Selbst nach dem Einspielen aktueller Patches bleiben Online-Dienste verwundbar, wenn Serverkonfiguration und Hosting-Ebenen ungeprüft bleiben.
Sicherheitslücken in Websprache erreichen Firmen-Firewalls
27. Oktober 2026Schwachstellen in einer verbreiteten Softwarekomponente zwingen Netzwerkbetreiber zum Warten auf maßgeschneiderte Hersteller-Updates.QNAP schließt gefährliche Sicherheitslücke auf sechs Speichersystemen
24. Oktober 2026Aktualisierte Firmware schützt weite Teile der Produktpalette, doch vier Spezialserien bleiben vorerst verwundbar.
Dritte Schwachstelle verkompliziert PHP-Sicherheit
24. Oktober 2026Reine Software-Updates schützen Webseiten womöglich nicht, solange bestimmte Einstellungen aktiv bleiben.
Sicherheitslücken in PHP treffen Netzwerk-Hardware mit Verzögerung
23. Oktober 2026Webhoster schließen kritische Einfallstore zügig, während Administratoren von Firmen-Firewalls auf Hersteller-Updates warten müssen.
Das Wesentliche
Zwei unter dem Namen PHP2Shell bekannte Schwachstellen bedrohen Webseiten weltweit, die auf der Programmiersprache PHP aufsetzen – der Basis von fast sieben von zehn identifizierbaren Webservern. Da der Fehler im Kern von PHP und nicht in Anwendungen wie WordPress oder Drupal liegt, bieten gewöhnliche Anwendungsupdates keinen Schutz. Offizielle Patches stehen seit dem 21. Oktober bereit. Ob die Lücke geschlossen wird, hängt jedoch von der Serverkontrolle ab: Hoster müssen Shared-Systeme warten, während Betreiber eigener Server die Software selbst patchen und neu starten müssen. Erste Scans begannen vor Veröffentlichung der Patches; bestätigte Einbrüche auf Produktivsystemen gibt es bislang nicht.
Die Kernpunkte
- PHP bildet bei 69,3 Prozent aller Webseiten mit identifizierbarer serverseitiger Programmierung die technologische Basis.
- Das PHP-Projekt stellte am 21. Oktober die außerplanmäßigen Sicherheitsversionen 8.2.35, 8.3.36, 8.4.27 und 8.5.12 bereit.
- Erste Angriffsversuche auf Honeypot-Systeme wurden bereits ab dem 17. Oktober und damit vor der öffentlichen Bekanntgabe registriert.
- CloudLinux schloss die Bereitstellung korrigierter nativer Pakete für alle betroffenen Betriebssystemversionen am 22. Oktober um 19:50 Uhr UTC ab.
Aus dem Tagebuch des Redakteurs
Sicherheit im Netz verlangt den Blick unter die sichtbare Anwendungsoberfläche. Versagt die zugrunde liegende Programmiersprache, schützen weder Erweiterungen noch Layout-Vorlagen – die Sicherheit hängt dann allein davon ab, wer den ausführenden Server kontrolliert.
Wer beteiligt ist
PHP Security Team und PHP Foundation
Die Kernentwickler und die gemeinnützige Stiftung hinter der Programmiersprache PHP
will → Die grundlegenden Softwarefehler beheben, öffentliche Sicherheitswarnungen koordinieren und sichere Code-Versionen für Distributoren bereitstellen
Hosting-Provider und PHP-Distributoren, darunter cPanel und CloudLinux
Unternehmen, die Betriebssysteme, Verwaltungssoftware und Serverpakete für Webhoster anbieten
will → Korrigierte Softwarepakete schnüren, verteilen und die Server von Shared-Hosting-Kunden aktualisieren
Webseitenbetreiber und Infrastruktur-Administratoren
Unternehmen, Techniker und Medienhäuser, die eigene Webseiten betreiben
will → Die aktive PHP-Version im Produktivbetrieb prüfen, Systemupdates einspielen und den Patch-Status ihrer Hoster kontrollieren
Calif, OpenAI und Wiz Research
Unabhängige IT-Sicherheitsforscher, die die Systemlücken entdeckt und getestet haben
will → Die genauen Schwachstellen im Code aufspüren, Entwickler vertraulich informieren und vorgeschlagene Patches vor der Veröffentlichung prüfen
Automattic
Das Unternehmen hinter verwalteten Plattformen wie WordPress.com, WordPress VIP und Pressable
will → Schutzmaßnahmen auf den unternehmenseigenen Servern installieren, ohne dass Kunden selbst eingreifen müssen
Google Cloud, Amazon Web Services und Cloudflare
Globale Cloud- und Netzwerkanbieter für Hosting, Schutzschilde und Bedrohungserkennung
will → Verwaltete Kundensysteme absichern, bösartigen Datenverkehr blockieren und Kunden beim Absichern privater Serverinstanzen anleiten
Unbekannte Angreifer
Bislang nicht identifizierte Akteure, die manipulierte Netzanfragen an anfällige Server senden
will → Rechner im Internet scannen, um vertrauliche Daten zu entwenden oder fremde Systeme zu kapern
Gewöhnliche Webseitenbesucher
Nutzer, die im Netz surfen, Einkäufe tätigen und persönliche Daten übermitteln
will → Eigene Zugangsdaten und Daten schützen, ohne über Möglichkeiten zur Serverreparatur zu verfügen
Kurz gefasst
Die Aktualisierung einer Webanwendung wie WordPress schützt eine Internetseite nicht, wenn der darunterliegende Programmcode fehlerhaft bleibt. Mehr als zwei Drittel aller Webseiten mit identifizierbarer serverseitiger Programmierung wickeln Anmeldevorgänge, digitale Warenkörbe und Kontaktformulare über PHP ab. Zwei schwere Speicherfehler in dieser Basissoftware ermöglichen es unbefugten Angreifern, Daten abzugreifen oder die vollständige Kontrolle über die betroffenen Server zu übernehmen.
Um die Schwachstellen zu schließen, müssen Betreiber ihre aktiven PHP-Installationen aktualisieren oder speziell angepasste Softwarepakete ihrer Linux-Distributoren einspielen.
Dieser Prozess dürfte sich in den kommenden Wochen sehr uneinheitlich gestalten. Die Zuständigkeiten im Netzbetrieb sind stark zersplittert, und unzählige Webseitenbetreiber besitzen keinen direkten Zugriff auf die Rechner, auf denen ihre Seiten gehostet werden.
Wie es sich entwickelte
Ein Routine-Audit verwandelt eine alte Warnung in einen Notfall
Eine Überprüfung von Softwarecode hat eine branchenweite Sicherheitskrise ausgelöst, nachdem sich ein lange bekannter Speicherfehler als weitaus gefährlicher herausstellte als zunächst angenommen. Ein Entwickler hatte die potenzielle Schwachstelle bereits 2024 während einer Untersuchung durch das französische IT-Sicherheitsunternehmen Quarkslab bemerkt. Die Fehlerbehebung stockte damals jedoch, weil Eingriffe in diesen Code bestehende Webanwendungen zu beschädigen drohten. Die Lage spitzte sich am 30. Juli 2026 zu: Im Rahmen von OpenAIs Sicherheitsinitiative „Patch the Planet“, die kritische Open-Source-Software härten soll, nahm das Sicherheitsunternehmen Calif ein Audit von PHP auf. Bis zum 11. August gelang den Forschern der erste Nachweis, dass Angreifer über diesen Fehler unbefugt eigene Befehle ausführen können. Als am 20. Oktober erste Warnungen in IT-Foren wie Hacker News kursierten, sahen sich die PHP-Betreuer gezwungen, das Problem öffentlich zu bestätigen und Notfall-Patches vorzubereiten.
Die Schwachstelle sitzt tief im Fundament der Webseiten
Die Untersuchungen verlagerten sich rasch von den sichtbaren Internetseiten auf die Softwareumgebung, die den Code auf den Servern ausführt. Am 11. August wies Calif nach, dass zwei kritische Schwachstellen unter Millionen von Webseiten es Angreifern erlauben, Befehle direkt an einen Server zu übermitteln, sobald dessen Arbeitsspeicher an Kapazitätsgrenzen stößt. Das IT-Sicherheitsunternehmen Wiz zeigte kurz darauf, dass sich dieser Fehler über weit verbreitete Redaktionssysteme wie Drupal und WordPress ansteuern lässt, während OpenAI weitere Angriffswege ermittelte. Die Ursache lag nicht in mangelhaftem Programmcode dieser Inhaltsplattformen. Vielmehr bereinigte PHP bei fehlschlagenden Anfragen den Arbeitsspeicher unzureichend und hinterließ Datenreste, die sich über nachfolgende Anfragen missbrauchen ließen. Dadurch konnte ein Server, der mehrere Aufgaben nacheinander abarbeitet, sensible Informationen früherer Prozesse wie Kennwörter oder Transaktionsdaten offenlegen.
Angriffe beginnen vor Verteilung der Sicherheitsupdates
Der koordinierte Veröffentlichungsplan für die Sicherheitskorrekturen brach zusammen, als im Internet erste Angriffsversuche auftauchten, noch bevor wirksame Schutzmechanismen bereitstanden. Am 17. Oktober registrierte Amazon Web Services unerlaubte Zugriffsversuche auf MadPot, ein unternehmenseigenes Täuschungsnetzwerk zur Beobachtung von Hackern. Drei Tage später, am 20. Oktober, verbreiteten sich ungeprüfte Warnungen und die offiziellen Kennungen der Sicherheitslücken auf Hacker News, begleitet von einem kurzzeitig geleakten Demonstrationsvideo von Calif. Angesichts der vorzeitig durchgesickerten Details verwarf die PHP Foundation ihren ursprünglichen Zeitplan, zog die Veröffentlichung der Patches um einen vollen Tag vor und informierte Betreiber kritischer Infrastrukturen vorab, damit diese ihre Netzwerke absichern konnten.
Ein Patch für PHP – nicht für WordPress
Die offiziellen Sicherheitsupdates erschienen am 21. Oktober für mehrere PHP-Versionen und machten deutlich, dass reine Anwendungsupdates keinerlei Schutz bieten. Das PHP-Projekt stellte die bereinigten Versionen 8.2.35, 8.3.36, 8.4.27 und 8.5.12 bereit, um zwei spezifische Fehler zu beheben: eine unzureichende Speicherbereinigung bei Speicherengpässen sowie das Zurückbleiben alter Prozessdaten für nachfolgende Aufgaben. Systeme, die PHP direkt als Modul in Apache-Webserver einbinden, waren besonders gefährdet, da Angriffe dort schon greifen konnten, bevor der eigentliche Webseitencode ausgeführt wurde; aber auch Konfigurationen mit separaten Prozessen wiesen die Schwachstelle auf. Das WordPress-Projekt stellte in einer Mitteilung klar, dass kein WordPress-Update das Problem lösen könne: Selbst ein vollständig aktualisiertes Redaktionssystem bleibe angreifbar, solange die darunterliegende PHP-Software ungepatcht läuft.
Die Schließung der Lücke hängt vom Serverzugriff ab
Die Auslieferung der Fehlerbehebungen auf Produktivsysteme gestaltete sich kompliziert, weil die Zuständigkeiten im Serverbetrieb über mehrere Ebenen und Softwareanbieter verteilt sind. Beim klassischen Shared Hosting verwalten die Hosting-Unternehmen die Systemsoftware über Pakete von Anbietern wie cPanel und CloudLinux, während Webseitenbetreiber in ihren Kundenportalen lediglich vorgegebene Optionen auswählen können. Administratoren eigenständig verwalteter virtueller Server mussten die Updates manuell einspielen und die Webdienste neu starten; Teams mit containerbasierten Architekturen mussten ihre Anwendungsabbilder neu erstellen und ausrollen. CloudLinux benötigte den gesamten 22. Oktober, um Unklarheiten bei den Paketbezeichnungen auszuräumen: Ältere Versionsnummern konnten durchaus sicher sein, sofern die Sicherheitspatches über sogenannte Backports nachträglich integriert worden waren. Erst am späten Abend standen die korrigierten Pakete für alle betroffenen Betriebssystemversionen in den stabilen Softwarequellen bereit.
Wo die Dinge stehen
Die technischen Schwachstellen in PHP sind zweifelsfrei nachgewiesen, offizielle Reparaturen existieren, und die Vertriebskanäle stellen fehlerbereinigte Pakete bereit. Zu den offiziell unterstützten und abgesicherten Versionen zählen PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12; spezialisierte Distributoren haben zudem Rückportierungen für ältere Code-Zweige erstellt. Administratoren müssen jetzt verifizieren, dass ihre aktiven Webserver-Prozesse tatsächlich mit den gepatchten Dateien neu gestartet wurden, anstatt sich auf die bloße Anzeige von Versionsnummern oder installierte Sicherheits-Plugins zu verlassen.
Wie viele Webseiten weltweit tatsächlich angreifbar sind, bleibt unklar. Nach Erhebungen des Analysedienstes W3Techs basierten am 22. Oktober 69,3 Prozent aller Internetseiten mit identifizierbarer serverseitiger Sprache auf PHP. Diese Zahl spiegelt jedoch lediglich die enorme Verbreitung der Technologie wider und ist kein Beleg für tatsächliche Kompromittierungen. Sowohl Amazon als auch Cloudflare fingen im Internet unbefugte Scan- und Angriffsversuche ab. Amazon betonte allerdings, dass das reale Schadensausmaß unklar sei, und auch die PHP Foundation verzeichnete bis zum 22. Oktober keine bestätigten erfolgreichen Einbrüche in Produktivsysteme.
PHP2Shell: die PHP-Sicherheitskrise
PHP-Sicherheitsupdate trotz Falschmeldungen über Umgehung wirksam
21. Oktober 2026Berichte über ein angeblich fehlerhaftes Notfall-Patch für Millionen Webserver entbehren laut technischen Analysen jeder Grundlage.
PHP schließt kritische Sicherheitslücken nach vorzeitiger Veröffentlichung von Angriffscode
21. Oktober 2026Vorzeitig ins Netz gelangte Exploit-Anleitungen bedrohen Millionen Webserver weltweit mit einer feindlichen Übernahme, noch bevor offizielle Updates bereitstanden.