PHP2Shell ist der Name für zwei kritische Sicherheitslücken im Kern der Programmiersprache PHP, über die Angreifer ohne Anmeldung fremde Befehle auf einem Webserver ausführen können. Betroffen ist praktisch jede Website, die auf PHP läuft – also auch die meisten Firmenseiten mit WordPress, TYPO3, Shopware oder Joomla. Die Lücken sind seit dem 21. Oktober 2026 geschlossen, aber nur auf Servern, auf denen das Update tatsächlich eingespielt ist.
Für die Geschäftsführung heißt das: Heute sind drei Fragen zu klären. Läuft bei uns irgendwo PHP? Wer spielt das Update ein, und ist es schon drin? Und gibt es Hinweise, dass jemand vorher da war?
Update 27. Oktober, 13:45 Uhr
Die Angriffe sind jetzt auch behördlich bestätigt. Die US-Cybersicherheitsbehörde CISA hat beide PHP2Shell-Lücken am 26. Oktober in ihre Liste aktiv ausgenutzter Schwachstellen aufgenommen; US-Bundesbehörden müssen sie bis zum 29. Oktober schließen. Für Unternehmen in Deutschland gilt diese Frist nicht, die Einordnung aber schon: Ein ungepatchter PHP-Server ist kein theoretisches Risiko mehr.
Öffentlich ist auch ein erster Schaden. Laut SRF wurden über das Buchungssystem Camping.Care, das TCS Camping in der Schweiz nutzt, Namen, Telefonnummern und Reservierungsnummern abgegriffen; rund 15.000 Kunden wurden vor gefälschten WhatsApp-Nachrichten gewarnt. Der Fall zeigt, dass nicht nur die eigene Website zählt, sondern auch Buchungs-, Termin- und Kundenportale, die ein Dienstleister für das Unternehmen betreibt.
Und zu ist die Lücke längst nicht überall: Der Scandienst Censys zählt laut heise in Deutschland noch immer mehr als vier Millionen Dienste, die sich mit einer anfälligen PHP-Version melden – weil Linux-Anbieter Updates in ältere Versionen zurückportieren, ist das ein Indiz, kein genauer Wert. Wie man die eigenen Systeme prüft, steht in So prüfen Unternehmen, ob ihre Website betroffen ist.
Update 26. Oktober, 13:30 Uhr
Erstmals ist ein erfolgreicher Angriff über PHP2Shell belegt. Der Sicherheitsforscher Adel Karimi hat in einer Angriffsfalle (Honeypot) dokumentiert, wie Angreifer auf einem Apache-Server mit PHP 8.4.26 eigene Befehle ausgeführt haben; Marcus Hutchins vom Sicherheitsanbieter Expel hat den Befund bestätigt, berichtet BleepingComputer. Bis dahin hatten Cloudflare, watchTowr und andere nur gescheiterte Versuche gesehen. Das Zeitfenster ist damit zu: Ein Server, der noch nicht auf PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 oder neuer läuft, gehört heute aktualisiert oder vom Netz – und danach ab dem 17. Oktober auf Spuren untersucht.
Dazu hat das PHP-Projekt am 23. Oktober vor einer weiteren Lücke gewarnt (CVE-2026-115560), für die es noch kein Update gibt. Sie trifft nur Anwendungen mit einer seltenen Session-Einstellung. Die Übergangslösung ist dieselbe wie bei PHP2Shell: die Upload-Fortschrittsanzeige in der php.ini abschalten (session.upload_progress.enabled=0) und PHP neu starten. Wer das schon getan hat, lässt es so.
Update 26. Oktober, 9 Uhr
Die meisten Websites, die Behörden, Kommunen und Kliniken vorsorglich abgeschaltet hatten, sind seit Freitag wieder online, berichtet die dpa. Eine Entwarnung ist das nicht: Das BSI hat bislang keine erfolgreichen Angriffe festgestellt, schließt sie aber ausdrücklich nicht aus, und die Warnung gilt weiter. Die automatisierte Suche nach ungepatchten Servern dürfte nach Einschätzung von Fachleuten noch Wochen andauern. Die Cyberagentur des Bundes nennt PHP2Shell ein Beispiel dafür, dass Angreifer eine veröffentlichte Lücke heute in Minuten bis Stunden ausnutzen, während das Schließen deutlich länger dauert. Wer für einen Server auf der Liste unten noch keine bestätigte PHP-Version hat, sollte das jetzt nachholen – das Abschalten war die Notbremse, nicht die Lösung.
Update 23. Oktober
Das BSI hält in der Fassung seiner Warnung vom 22. Oktober fest, dass die Updates vollständig sind – Berichte über umgehbare Patches wurden widerlegt – und dass ihm bislang keine erfolgreich kompromittierten Systeme aus der regulierten Wirtschaft gemeldet wurden. Strato, IONOS, all-inkl, Hetzner und die meisten anderen deutschen Hoster melden ihre Webhosting-Plattformen als gepatcht. Zwei Blickwinkel-Artikel vertiefen: So prüfen Unternehmen, ob ihre Website betroffen ist und Was die Hoster erledigt haben – und was Kunden selbst tun müssen.
Inhaltsverzeichnis
- Was ist PHP2Shell?
- Wie gefährlich ist die PHP-Lücke wirklich?
- Ist unsere Firmenwebsite betroffen?
- Wer muss das Update einspielen?
- Was sollte die Geschäftsführung heute veranlassen?
- Reicht das Update, oder muss man nach Angriffen suchen?
- Was gilt, wenn Daten abgeflossen sind?
- Was PHP2Shell über die eigene IT verrät
- Fazit
- Mehr dazu
- Quellen
- Häufige Fragen
Was ist PHP2Shell?
PHP2Shell fasst zwei Schwachstellen mit den Kennungen CVE-2026-109618 und CVE-2026-109619 zusammen. Das PHP-Sicherheitsteam bewertet beide mit 9,2 von 10 Punkten auf der CVSS-Skala, also als kritisch. Ein Angreifer schickt dafür eine präparierte Anfrage an die Website, ähnlich wie beim Absenden eines Formulars, und kann danach Programme auf dem Server starten.
Technisch stecken die Fehler in der Art, wie PHP Speicher für eingehende Anfragen verwaltet: Einmal räumt PHP nach einem Speicherengpass halb fertige Daten auf, als wären sie gültig, einmal bleibt Zustand aus einer früheren Anfrage zurück, auf den die nächste zugreifen kann. Die zweite Lücke kann laut PHP zusätzlich Speicherinhalte preisgeben. Weil der Angriff unterhalb der eigentlichen Website ansetzt, hilft es nicht, WordPress oder seine Plugins aktuell zu halten – das PHP darunter muss neu.
Sicher sind die Versionen PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 oder neuer. Für PHP 8.1 und ältere Versionen veröffentlicht das PHP-Projekt keine regulären Updates mehr.
Wie gefährlich ist die PHP-Lücke wirklich?
Sehr. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat die Lage mit Warnstufe 3 (orange) bewertet und Betreibern geraten, unverzüglich zu handeln – notfalls den Webserver bis zum Update vom Internet zu trennen. Mehrere Behörden, Hochschulen und Kliniken haben genau das getan: Die Charité nahm ihre gesamte Website vom Netz, Teile von berlin.de waren abgeschaltet.
Der Grund für die Eile: Die Details waren am 20. Oktober vorzeitig durchgesickert, das PHP-Team zog die Veröffentlichung daraufhin um einen Tag vor. Cloudflare meldete Millionen Angriffsversuche, Amazon beobachtete erste Versuche bereits am 17. Oktober, vier Tage vor der Veröffentlichung. Bis zum 25. Oktober waren nur gescheiterte Versuche bekannt. Am 26. Oktober meldete BleepingComputer den ersten belegten erfolgreichen Angriff auf einen ungepatchten Server, am selben Tag nahm die US-Behörde CISA beide Lücken in ihre Liste aktiv ausgenutzter Schwachstellen auf.
7 von 10
Websites mit bekannter Server-Technik laufen auf PHP – genau deshalb trifft eine Lücke im PHP-Kern so viele Betriebe auf einmal. Quelle: W3Techs, zitiert von Tenable (69,3 %), Oktober 2026
Ist unsere Firmenwebsite betroffen?
Wenn die Website auf WordPress, TYPO3, Contao, Joomla, Drupal, Shopware, Magento oder WooCommerce läuft, ja – sofern der Server noch eine alte PHP-Version nutzt. Nicht direkt betroffen sind Seiten aus Baukästen wie Wix, Jimdo oder Squarespace, Shops auf Shopify und rein statische Websites ohne PHP.
Die Website ist aber oft nicht der einzige Ort. PHP steckt auch in Systemen, die niemand als „Website“ wahrnimmt: im Intranet, im Ticketsystem, in der Zeiterfassung, im Kundenportal, im Online-Bewerbungsformular oder auf einem kleinen Server, den vor Jahren jemand für ein Projekt aufgesetzt hat. heise rät ausdrücklich, auch dort nachzusehen, wo PHP unbemerkt läuft, etwa auf Raspberry-Pi-Servern. Alles davon, was aus dem Internet erreichbar ist, gehört auf die Liste.
Praxis-Tipp
Bei WordPress steht die PHP-Version im Dashboard unter Werkzeuge → Website-Zustand → Bericht → Server. Beim Webhoster zeigt sie meist der Kundenbereich unter „PHP-Einstellungen“. Liegt sie unter den oben genannten Versionen oder bei 8.1 und älter, ist Handlungsbedarf.
Wer muss das Update einspielen?
Das hängt davon ab, wo die Website liegt. Bei einem einfachen Webhosting-Paket ist der Hoster für PHP zuständig, bei einem eigenen Server der Betreiber, also das Unternehmen selbst oder sein IT-Dienstleister. Entscheidend ist, dass die Zuständigkeit heute jemand bestätigt und nicht nur vermutet.
| Wo die Website liegt | Wer patcht | Was zu tun ist |
|---|---|---|
| Webhosting-Paket (Shared Hosting) | der Hoster | Statusseite des Hosters prüfen oder nachfragen; prüfen, ob die eigene Seite noch auf PHP 8.1 oder älter eingestellt ist |
| Betreuung durch Agentur (Managed Hosting) | die Agentur | schriftliche Rückmeldung anfordern: Version vorher, Version nachher, Datum |
| Eigener Server oder Cloud-Server | eigene IT oder IT-Dienstleister | Pakete der Linux-Distribution aktualisieren, PHP und Webserver neu starten |
| PHP 8.1 oder älter | niemand automatisch | auf eine unterstützte Version umstellen; vorher Backup und Test, alte Plugins können brechen |
Die letzte Zeile ist die unangenehmste. Wer eine Website seit Jahren nicht angefasst hat, steht oft auf einer alten PHP-Version, für die es kein fertiges Update gibt. Dort ist aus einem Update ein kleines Projekt geworden – mit der Frage, ob die Seite den Umzug übersteht.
Was sollte die Geschäftsführung heute veranlassen?
Die Technik erledigt die IT oder der Hoster. Die Geschäftsführung sorgt dafür, dass es heute passiert und dass jemand es bestätigt. Diese Liste lässt sich in einer Viertelstunde verteilen:
PHP2Shell – heute klären
- Alle Websites, Shops, Portale und Formulare des Unternehmens auflisten, auch Kampagnen- und Bewerberseiten
- Interne Systeme mit Weboberfläche ergänzen, die aus dem Internet erreichbar sind (Intranet, Tickets, Zeiterfassung, Kundenportal)
- Je System klären, wer für PHP zuständig ist: Hoster, Agentur, eigene IT
- Bestätigung einholen: installierte PHP-Version und Datum des Updates
- Systeme mit PHP 8.1 oder älter benennen und über Umstellung oder vorübergehendes Abschalten entscheiden
- Backups der betroffenen Seiten prüfen, bevor umgestellt wird
- Prüfen lassen, ob es seit dem 17. Oktober Auffälligkeiten gab (nächster Abschnitt)
Abschalten klingt drastisch, ist bei einer reinen Informationsseite aber oft das kleinere Übel. Eine Website, die zwei Tage offline ist, kostet ein paar Anfragen. Eine übernommene Website mit Kontaktformular kostet unter Umständen die Daten aller, die darüber geschrieben haben.
Reicht das Update, oder muss man nach Angriffen suchen?
Das Update schließt die Tür, sagt aber nichts darüber, ob vorher jemand durchgegangen ist. Amazon empfiehlt, Untersuchungen ab dem 17. Oktober anzusetzen, nicht erst ab dem Tag des Updates. Wer in diesem Zeitraum eine ungepatchte Seite im Netz hatte, sollte nachsehen lassen.
Typische Warnzeichen sind neue Administrator-Konten, die niemand angelegt hat, unbekannte PHP-Dateien auf dem Server, Weiterleitungen auf fremde Seiten, Warnmeldungen des Browsers beim Aufruf, ungewöhnlich viel Datenverkehr oder Spam, der über den eigenen Server verschickt wird. Bei Verdacht gehören alle Zugänge geändert, die auf dem Server gespeichert waren – Datenbank, Mailkonten, Schnittstellen.
Konfigurationsänderungen wie das Abschalten der Upload-Fortschrittsanzeige senken das Risiko, ersetzen das Update laut PHP-Team aber nicht. Ein vorgeschalteter Filter wie die Regeln von Cloudflare hilft nur, wenn die Website ohnehin über Cloudflare läuft. Gibt es konkrete Hinweise auf einen Einbruch, ist das kein Update-Thema mehr, sondern ein Sicherheitsvorfall – dann zählt, was der IT-Notfallplan für die ersten 24 Stunden vorsieht, und wer ihn nicht hat, braucht schnell Unterstützung im IT-Krisenmanagement.
Was gilt, wenn Daten abgeflossen sind?
Werden personenbezogene Daten abgegriffen – etwa Anfragen aus dem Kontaktformular, Kundenkonten oder Bewerbungen –, muss das Unternehmen den Vorfall nach Art. 33 DSGVO in der Regel innerhalb von 72 Stunden der zuständigen Datenschutzbehörde melden. Die Frist beginnt, sobald der Vorfall bekannt ist, nicht erst, wenn er vollständig aufgeklärt ist.
Unternehmen, die unter NIS2 fallen, haben eine zweite, kürzere Frist: Ein erheblicher Sicherheitsvorfall ist innerhalb von 24 Stunden als Frühwarnung an das BSI zu melden. Ob das eigene Unternehmen dazugehört, steht im Artikel NIS2: Sind Sie betroffen?. Beide Meldungen sind Chefsache, weil die Haftung dort liegt.
Das Update schließt die Tür. Ob vorher jemand durchgegangen ist, sagt es nicht.
Was PHP2Shell über die eigene IT verrät
Zwischen dem Leak und den ersten Angriffen lagen Stunden, nicht Wochen. In dieser Zeit musste jedes Unternehmen eine einfache Frage beantworten können: Wo bei uns läuft PHP, und wer kümmert sich darum? Wer dafür erst Kollegen anrufen und alte Verträge suchen musste, hat jetzt den eigentlichen Befund – nicht die Lücke, sondern die fehlende Übersicht.
Die nächste Lücke dieser Art kommt, die Frage bleibt dieselbe. Eine aktuelle Liste aller Systeme, ein fester Ablauf für Sicherheitsupdates und jemand, der bei einer Warnung des BSI sofort weiß, was zu tun ist, machen aus einem Krisentag einen Arbeitsauftrag. Wo die Lücken im eigenen Netz liegen, zeigt ein interner Schwachstellenscan. Wie HÖLL in Baden-Baden das für Betriebe in Mittelbaden dauerhaft übernimmt, beschreibt die Seite IT-Sicherheit von HÖLL, eingebettet in die IT-Lösungen insgesamt.
Fazit
PHP2Shell ist eine der seltenen Lücken, die fast jede klassische Firmenwebsite betreffen und bereits angegriffen werden. Geschlossen ist sie nur dort, wo PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 oder neuer läuft. Die Geschäftsführung muss nicht selbst patchen, aber heute klären lassen, wo PHP läuft, wer zuständig ist und ob das Update bestätigt eingespielt ist – und bei Systemen auf PHP 8.1 oder älter eine Entscheidung treffen.
Mehr dazu
- PHP2Shell: So prüfen Unternehmen, ob ihre Website betroffen ist – Versionen, Fundorte, Spurensuche ab dem 17. Oktober
- PHP2Shell bei Strato, IONOS, all-inkl und Co.: Was Hoster erledigt haben – und was Kunden selbst tun müssen – Hoster-Stand, NAS, Firewalls
- Mercury Fleet Management Client: Sicherheitsupdate bis 30. Oktober – was HÖLL-Kunden mit Fleet Management jetzt tun müssen, mit beiden Anleitungen als PDF
Quellen
- PHP – Security-Release vom 21. Oktober 2026 (Versionen, betroffene Server-Schnittstellen, Übergangsmaßnahmen): php.net
- PHP – Informational advisory: Session upload progress, CVE-2026-115560 (23. Oktober 2026): php.net
- BleepingComputer – PHP2Shell security flaws now successfully exploited in the wild (26. Oktober 2026, 10:19 Uhr): bleepingcomputer.com
- CISA – Known Exploited Vulnerabilities Catalog, Einträge CVE-2026-109618 und CVE-2026-109619 (aufgenommen 26. Oktober 2026, Frist für US-Bundesbehörden 29. Oktober): cisa.gov
- heise Security – php2shell: Erfolgreiche Angriffe auf PHP-Schwachstelle bestätigt (27. Oktober 2026, 9:02 Uhr): heise.de
- BleepingComputer – CISA confirms PHP2Shell vulnerabilities now exploited in attacks (27. Oktober 2026, 4:20 Uhr): bleepingcomputer.com
- SRF Kassensturz Espresso – PHP-Sicherheitslücke: Betrugsversuche nach Datenleck im Buchungssystem von TCS-Camping (26. Oktober 2026, 14:47 Uhr): srf.ch
- heise (Meinung, Tobias Glemser) – PHP2Shell: Die Schonfrist ist vorbei (26. Oktober 2026, 9:16 Uhr): heise.de
- BSI: IT-Sicherheitshinweis „PHP: Kritische Schwachstellen bedrohen Webanwendungen weltweit“, Nr. 2026-297981, Version 1.2, Kritikalität 3 / Orange (22. Oktober 2026): bsi.bund.de (PDF)
- Tenable – php2shell (CVE-2026-109618, CVE-2026-109619): FAQ mit Zeitlinie, Amazon- und CERT-EU-Hinweisen: tenable.com
- heise – php2shell: Updates rollen aus, Websites gehen offline, Angriffe beginnen: heise.de
- Tagesspiegel (dpa) – Webseiten größtenteils wieder online – aber noch keine Entwarnung (23. Oktober 2026, 11:56 Uhr): tagesspiegel.de
- heise (dpa) – Cyberagentur: Software-Schwachstellen bleiben länger ein Problem (25. Oktober 2026, 11:28 Uhr): heise.de
- IT-Business (dpa) – Kritische PHP-Lücke: BSI warnt: it-business.de
- Deutschland sicher im Netz – PHP2Shell gefährdet Webseiten und Onlineshops: sicher-im-netz.de
- Art. 33 DSGVO – Meldung von Verletzungen des Schutzes personenbezogener Daten: dsgvo-gesetz.de
Stand: 27. Oktober 2026, 13:45 Uhr (Erstfassung 22. Oktober, Updates 23., 26. und 27. Oktober). Die Lage entwickelt sich; maßgeblich sind die Hinweise des PHP-Projekts, des BSI und des eigenen Hosters.
Häufige Fragen
Ist die PHP-Sicherheitslücke behoben?
Die Updates gibt es seit dem 21. Oktober 2026, und das BSI hält sie für vollständig. Behoben ist die Lücke aber nur auf Servern, auf denen das Update eingespielt ist. Eine Entwarnung gibt es nicht: Seit dem 26. Oktober 2026 ist ein erster erfolgreicher Angriff belegt.
Wird PHP2Shell schon erfolgreich ausgenutzt?
Ja. Am 26. Oktober 2026 wurde der erste erfolgreiche Angriff belegt: Ein Sicherheitsforscher hat in einer Angriffsfalle dokumentiert, wie Befehle auf einem Server mit PHP 8.4.26 ausgeführt wurden. Die US-Behörde CISA führt beide Lücken seit demselben Tag als aktiv ausgenutzt, und in der Schweiz wurden über ein Buchungssystem Kundendaten abgegriffen. Ungepatchte Server sollten sofort aktualisiert oder vom Netz genommen werden.
Welche PHP-Versionen schließen PHP2Shell?
PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 sowie neuere Versionen. Für PHP 8.1 und älter gibt es vom PHP-Projekt kein reguläres Update; dort hilft nur der Umstieg auf eine unterstützte Version oder ein Update des Linux-Anbieters.
Reicht es, WordPress und die Plugins zu aktualisieren?
Nein. Die Lücke steckt in PHP selbst, also unterhalb von WordPress. Ein WordPress-Update schließt andere Lücken, aber nicht diese.
Sind Websites auf Shopify, Wix oder Jimdo betroffen?
Nicht direkt. Diese Baukästen betreiben ihre Server selbst, Kunden haben keine eigene PHP-Installation. Rein statische Websites ohne PHP sind ebenfalls nicht betroffen.
Hilft Cloudflare gegen PHP2Shell?
Cloudflare filtert bekannte Angriffsmuster, aber nur für Websites, deren Datenverkehr bereits über Cloudflare läuft. Ein Ersatz für das PHP-Update ist das nicht.
Ab wann sollte man nach Spuren eines Angriffs suchen?
Ab dem 17. Oktober 2026. An diesem Tag hat Amazon die ersten Angriffsversuche beobachtet, vier Tage vor der Veröffentlichung der Lücke.
