PHP2Shell: Ist eure Website betroffen, und was solltet ihr jetzt tun?

Was ist bei PHP2Shell passiert?

Am 21. Oktober 2026 hat PHP Notfall-Patches für zwei kritische Sicherheitslücken veröffentlicht, mit denen Angreifer ohne Passwort eigenen Code auf dem Server einer Website ausführen konnten. Die Lücken heißen PHP2Shell und wurden beide mit 9,2 von 10 bewertet.

PHP ist die Sprache hinter rund 69 % der Websites, deren Servertechnologie bekannt ist, darunter WordPress, TYPO3, Drupal und Joomla. Details sickerten einen Tag vor dem Patch durch, und Amazon hatte bereits am 17. Oktober den ersten Angriffsversuch beobachtet. Gefunden wurden die Lücken mithilfe von KI-Modellen.

In Deutschland gab das Bundesamt für Sicherheit in der Informationstechnik (BSI) eine Warnung der Stufe 3 „orange“ heraus und riet Betreibern, Server vom Netz zu nehmen, wenn sie nicht sofort patchen konnten. Die Stadt Mainz schaltete mainz.de ab, Behörden, Universitäten und Krankenhäuser folgten. In den Niederlanden gingen der Login-Dienst DigiD und die Website des Parlaments offline. Meist waren das Vorsichtsmaßnahmen, keine Hacks.

Ist eure Website betroffen?

Wenn eure Website oder ein Tool dahinter auf PHP läuft, war sie angreifbar, bis der Patch installiert war. Das betrifft WordPress, TYPO3, Drupal, Joomla, Shopware und Magento.

Hört nicht bei der Hauptwebsite auf. Prüft alles, was euer Marketing-Team unter eurer Domain betreibt:

• Ein Blog oder Ressourcen-Hub auf einer separaten WordPress-Installation
• Ein Karriereportal oder Landing Pages auf euren eigenen Servern
• Selbst gehostete Analytics- oder Marketing-Automation-Tools wie Matomo oder Mautic
• Ein Onlineshop auf Shopware oder Magento

Nicht sicher, worauf eine Website läuft? Eine kostenlose Browser-Erweiterung wie Wappalyzer zeigt mit einem Klick das CMS und oft auch die Serversprache. Wenn PHP auftaucht oder das CMS eines der oben genannten ist, fragt euren Hoster oder eure IT nach der genauen PHP-Version.

Warum hat ein WordPress-Update nicht geholfen?

Weil die Lücke in PHP selbst lag, eine Ebene unter dem CMS. Updates von WordPress, TYPO3 oder allen Plugins haben nichts geändert. Wer den Server betreibt, musste eine gepatchte PHP-Version installieren.

Deshalb steckten so viele Teams fest. Jede Ebene einer selbst gehosteten Website hat einen anderen Verantwortlichen, und im Notfall hängen alle von der untersten ab.

Ältere Websites hatten eine schwerere Woche. PHP hat offiziell nur die Versionen 8.2 bis 8.5 gepatcht. Für die Versionen 7.4 bis 8.1 gab es Korrekturen im Quellcode, die Hoster selbst einbauen mussten, und für alles Ältere gar keinen Patch. Laut Daten von W3Techs lief am Patch-Tag noch rund ein Drittel der PHP-Websites auf PHP 7 oder älter.

Was bedeutete das für Marketing-Teams?

Eine Website im Wartungsmodus bringt dem Marketing nichts. Formulare sammeln keine Leads, bezahlte Kampagnen schicken Traffic auf eine Fehlerseite, und niemand kann veröffentlichen. Das Marketing-Team kann nichts davon beheben, weil das Problem auf einem Server liegt, den es nicht kontrolliert.

Das größere Problem war die Zuständigkeit. Viele Unternehmen merkten an diesem Morgen, dass niemand wusste, welche PHP-Version auf ihrer Website lief oder wer sie aktualisiert. Die Antwort lag in einem Hosting-Vertrag, bei einem ehemaligen Freelancer oder in einer IT-Ticket-Warteschlange.

Unser Tipp: Stellt eurem Hoster oder eurer Agentur heute eine Frage: Welche PHP-Version läuft auf unserer Website, und wer aktualisiert sie, wenn die nächste Warnung kommt? Wenn niemand innerhalb eines Tages antworten kann, ist das das eigentliche Risiko, nicht die Lücke selbst.

Was bedeutet das für Sicherheit und Compliance?

Eine Lücke wie diese kann alles auf dem Server offenlegen, auch Formulareinsendungen und Kundendaten. Damit ist sie eine Datenschutzfrage, nicht nur eine IT-Frage.

• DSGVO, Artikel 32. Ihr müsst personenbezogene Daten mit geeigneten Maßnahmen schützen. Patches für bekannte kritische Lücken einzuspielen gehört dazu.
• DSGVO, Artikel 33. Wenn auf personenbezogene Daten zugegriffen wurde, müsst ihr das der Datenschutzbehörde innerhalb von 72 Stunden melden, nachdem ihr davon erfahren habt.
• NIS2. Seit dem 6. Dezember 2025 haben deutsche Unternehmen, die unter NIS2 fallen, eigene Meldepflichten bei Sicherheitsvorfällen.

Das ist keine Rechtsberatung. Euer Datenschutzbeauftragter entscheidet, was gemeldet werden muss. Unser Leitfaden zu Webflow und DSGVO erklärt die Datenschutz-Grundlagen für Unternehmenswebsites.

Hätte eine Managed Plattform das verhindert?

Bei dieser Lücke ja. Auf einer Managed Plattform wie Webflow betreibt und patcht der Anbieter die Server, euer Team hat also keine PHP-Version zu aktualisieren und kein Ticket, auf das es warten muss. Webflows Kerndienste basieren nicht auf PHP, und Kunden mussten nichts unternehmen.

Risikofrei ist eine Managed Plattform dadurch nicht. Accounts ohne Zwei-Faktor-Login, Custom Code und Drittanbieter-Skripte brauchen trotzdem jemanden, der dafür zuständig ist.

Wenn ihr diese Woche an eurer Plattform gezweifelt habt, wechselt nicht in Panik. Erst patchen, dann in Ruhe entscheiden. Unser Leitfaden dazu, wann sich der Abschied von einem Legacy-CMS lohnt, hilft bei der Entscheidung.

Was sollte euer Team jetzt tun?

Prüft zuerst, ob der Patch installiert ist, nicht nur geplant. Sorgt dann dafür, dass euch der nächste Notfall nicht ohne Verantwortlichen trifft.

1. PHP-Version prüfen. Fragt euren Hoster oder eure IT nach der genauen Version. Gepatcht sind die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35.
2. Alte Versionen isolieren. Websites auf PHP 8.1 oder älter brauchen einen Patch vom Anbieter oder ein Upgrade. Bis dahin bleiben sie offline oder hinter einer Firewall-Regel.
3. Logs prüfen. Sucht ab dem 17. Oktober nach ungewöhnlichen Aktivitäten und bezieht euren Datenschutzbeauftragten ein, wenn euch etwas auffällt.
4. Für jede Ebene einen Verantwortlichen benennen. Server, PHP, CMS, Plugins und Custom Code, jeweils mit einer zuständigen Person oder einem Anbieter.
5. Festlegen, wer die Website offline nehmen darf. Entscheidet vorab, wer das entscheidet und wer das Marketing informiert, damit die nächste Warnung nicht mit der Suche nach Namen beginnt.

Wenn ein Team dafür bei eurer Webflow-Website zuständig sein soll, deckt unser Growth Retainer laufende Entwicklung und Monitoring ab. Bevor ihr eine Plattform wählt, hilft unser Vergleich Webflow vs. WordPress bei der größeren Entscheidung.