Ob eine Firmenwebsite von PHP2Shell betroffen ist, lässt sich in drei Schritten klären: Läuft sie auf PHP, welche PHP-Version ist installiert, und wer hat das Update wann eingespielt. Das PHP-Projekt hat die Lücken CVE-2026-109618 und CVE-2026-109619 am 21. Oktober 2026 geschlossen; das Bundesamt für Sicherheit in der Informationstechnik (BSI) führt die Warnung mit Stufe Orange und hält in der Fassung vom 22. Oktober fest, dass die Updates vollständig sind. heise, tagesschau, Spiegel und ZEIT berichten seit Mittwoch. Dieser Artikel ist die Prüfanleitung zum Hauptartikel PHP2Shell: Was die kritische PHP-Lücke für Unternehmen bedeutet – geschrieben für Geschäftsführung und Büroleitung, nicht für Administratoren.
Mit Zugang zum Kundenmenü des Hosters dauert die Prüfung eine Viertelstunde. Wer den Zugang nicht hat, stellt die drei Fragen seiner Agentur oder seinem IT-Dienstleister und lässt sich die Antworten schriftlich geben – mit Versionsnummer und Datum.
Update 27. Oktober, 8:45 Uhr
Die Lücken werden jetzt nachweislich ausgenutzt. Die US-Cybersicherheitsbehörde CISA hat CVE-2026-109618 und CVE-2026-109619 am 26. Oktober in ihre Liste aktiv ausgenutzter Schwachstellen aufgenommen. Dazu ist ein erster Schadensfall öffentlich: 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, die sich auf echte Buchungen beziehen. Für die Prüfung heißt das: Auf die Liste gehören auch Buchungs-, Termin- und Kundenportale, die ein Dienstleister für das Unternehmen betreibt. Außerdem hat das PHP-Projekt am 23. Oktober vor einer weiteren Lücke gewarnt (CVE-2026-115560), für die es noch kein Update gibt – Einordnung und Übergangslösung im Hauptartikel.
Inhaltsverzeichnis
Läuft unsere Website überhaupt auf PHP?
Wenn die Website mit WordPress, TYPO3, Joomla, Drupal, Contao, Shopware, Magento oder WooCommerce gebaut ist, läuft sie auf PHP – das gilt für den Großteil der klassischen Firmenseiten. Nicht selbst betroffen sind Kunden von Baukästen wie Wix, Jimdo oder Squarespace, von Shopify und von Strato SmartWebsite oder dem IONOS Website Builder: Dort betreibt der Anbieter die Server und hat das Update eingespielt. Wer nicht weiß, womit die eigene Seite gebaut ist, fragt die Agentur, die sie gebaut hat.
Die Website ist aber selten das einzige System mit PHP. Das BSI rät in seiner zweiten Aktualisierung ausdrücklich, auch Firewalls, Router, NAS-Geräte und andere Komponenten mit Weboberfläche zu prüfen, weil dort oft PHP eingebaut ist. Dazu kommen Intranet, Zeiterfassung, Ticketsystem, Kundenportal und das Bewerbungsformular. Alles davon, was aus dem Internet erreichbar ist, gehört auf die Prüfliste. Welche Hoster und Hersteller sich bisher geäußert haben, steht im Blickwinkel-Artikel PHP2Shell bei Strato, IONOS, all-inkl und Co..
Welche PHP-Version ist sicher?
Sicher sind laut PHP-Projekt die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 oder neuer. Für PHP 8.1, 8.0 und 7.4 gibt es vom Projekt nur Quellcode-Korrekturen, die Hoster und Linux-Anbieter selbst einbauen müssen; für PHP 7.3 und älter gibt es nichts mehr. Ob eine alte Version abgesichert ist, kann deshalb nur der Hoster oder der Betreiber des Servers bestätigen.
| PHP-Zweig | Sicher ab | Was das für den Betrieb heißt |
|---|---|---|
| 8.5 | 8.5.12 | Update einspielen, fertig |
| 8.4 | 8.4.27 | Update einspielen, fertig |
| 8.3 | 8.3.36 | Update einspielen; Zweig bekommt nur noch Sicherheitsupdates |
| 8.2 | 8.2.35 | Update einspielen; Support endet laut PHP-Projekt am 31. Dezember 2026, Umstieg einplanen |
| 8.1, 8.0, 7.4 | kein offizielles Release | nur, wenn Hoster oder Linux-Anbieter die Korrektur eingebaut haben – schriftlich bestätigen lassen |
| 7.3 und älter | nichts | Umstieg oder Abschalten, keine dritte Option |
Eine Falle steckt in der Versionsnummer selbst: Linux-Anbieter wie Debian und Ubuntu bauen die Korrektur ein, ohne die Nummer zu ändern. Ein Server mit Ubuntu 24.04 zeigt dann weiter „8.3.6“ an und ist trotzdem geschützt – oder zeigt „8.3.6“ und ist es nicht. Das BSI weist auf genau diesen Abgleich hin. Der Beleg ist deshalb nicht die Zahl aus php -v, sondern der Eintrag der beiden CVE-Nummern im Änderungsprotokoll des Pakets oder die Bestätigung des Hosters.
Wo sehe ich die PHP-Version?
Die PHP-Version steht an drei Stellen: im Kundenmenü des Hosters, in der Verwaltung des Content-Management-Systems und in der Antwort der Agentur. Für die Geschäftsführung reicht eine davon, solange daneben steht, wer das Update wann eingespielt und PHP danach neu gestartet hat – ein Paket-Update ohne Neustart schließt laut hostspezial.de nichts.
Praxis-Tipp
WordPress: Werkzeuge → Website-Zustand → Bericht → Server. TYPO3: Admin Tools → Environment. Joomla: System → Systeminformationen. Beim Hoster steht die Version im Kundenmenü unter „PHP-Einstellungen“ oder „PHP-Version“ – und zwar je Domain. Steht dort eine Version unter 8.2, hilft der Hinweis „unsere Plattform ist gepatcht“ nicht automatisch: Dann beim Hoster nachfragen, ob genau diese alte Version die Korrektur bekommen hat, oder die Domain auf 8.3 oder 8.4 umstellen – vorher Backup, danach Seite und Formulare testen.
Betroffenheit prüfen – fünf Schritte
- Alle Websites, Shops, Portale und Formulare des Unternehmens auflisten – auch alte Kampagnenseiten, das Bewerbungsformular und Buchungs- oder Terminportale, die ein Dienstleister betreibt
- Je Eintrag klären: Baukasten (nicht selbst betroffen) oder CMS auf PHP (betroffen)
- PHP-Version je Domain ablesen oder von Agentur bzw. IT nennen lassen
- Bestätigung einholen: Version nach dem Update, Datum, Neustart – bei Versionen unter 8.2 ausdrücklich die Zusage, dass diese Version korrigiert ist
- Spurensuche ab dem 17. Oktober beauftragen, wenn die Seite zwischen dem 17. und dem Update ungeschützt im Netz war
Woran erkenne ich, ob schon jemand drin war?
Das Update schließt die Lücke, entfernt aber keine Hintertür, die vorher eingebaut wurde. Amazon hat erste Angriffsversuche am 17. Oktober gesehen, vier Tage vor der Veröffentlichung; Sophos rät in seiner Sicherheitsmeldung sogar, Protokolle ab dem 1. August 2026 zu prüfen. Wer in dieser Zeit eine ungeschützte Seite im Netz hatte, lässt nachsehen – auch wenn alles normal aussieht.
4 Tage
lagen zwischen den ersten beobachteten Angriffsversuchen und der Veröffentlichung des Updates. Die Spurensuche beginnt deshalb am 17. Oktober, nicht am Tag des Patches. Quelle: Amazon Threat Intelligence, zitiert von Tenable, 22. Oktober 2026
Ohne Technikkenntnisse erkennbar sind: Administrator-Konten im CMS, die niemand angelegt hat, Weiterleitungen auf fremde Seiten, Warnmeldungen des Browsers beim Aufruf, Spam, der über die eigene Domain verschickt wird, und Formulare, die plötzlich nicht mehr funktionieren. all-inkl bittet seine Kunden genau darum: auf unbekannte Dateien, unerwartete Änderungen und neue Benutzerkonten achten. Für die IT oder den Dienstleister kommen dazu: PHP-Dateien, die seit dem 17. Oktober neu auf dem Server liegen, unbekannte Prozesse unter dem Benutzer des Webservers, und Einträge wie „Allowed memory size“ zusammen mit „Unknown on line 0“ im Fehlerprotokoll.
Ein ruhiges Protokoll ist keine Entwarnung. Ein erfolgreicher Angriff hinterlässt oft keinen Absturz.
Was tun, wenn die Prüfung „betroffen“ ergibt?
Sofort patchen, PHP und Webserver neu starten – und bei Verdacht auf einen Einbruch die Seite isolieren und Zugangsdaten wechseln. Geht das Update nicht heute, nimmt man die Seite bis dahin vom Netz; so rät es das BSI, weil die Übergangseinstellungen laut PHP-Projekt keinen vollständigen Schutz bieten.
Gibt es Hinweise auf einen Einbruch, ist das kein Update-Thema mehr, sondern ein Sicherheitsvorfall: System isolieren, alle Zugangsdaten wechseln, die auf dem Server lagen, und den IT-Notfallplan für die ersten 24 Stunden abarbeiten. Wer keinen hat, holt sich Unterstützung im IT-Krisenmanagement. Sind Kundendaten abgeflossen, läuft die 72-Stunden-Frist nach Art. 33 DSGVO – die Details stehen im Hauptartikel.
Die eigentliche Erkenntnis dieser Woche ist eine andere: Wer die drei Fragen – wo läuft PHP, welche Version, wer hat gepatcht – nicht in einer Viertelstunde beantworten kann, hat kein Prüfproblem, sondern keine Übersicht. HÖLL in Baden-Baden führt diese Liste für Betriebe in Mittelbaden dauerhaft und spielt Updates im Rahmen der IT-Sicherheit von HÖLL ein, als Teil der IT-Lösungen insgesamt. Wer erst einmal wissen will, wo er steht, startet mit dem IT-Check nach DIN SPEC 27076.
Fazit
Betroffen ist jede Website und jedes System auf PHP, dessen Version unter 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 liegt und keine bestätigte Korrektur bekommen hat. Die Prüfung besteht aus drei Fragen und einer Bestätigung mit Datum. Weil die ersten Angriffsversuche vier Tage vor dem Update liefen, gehört zur Prüfung auch die Spurensuche ab dem 17. Oktober – das Update allein beantwortet sie nicht.
Mehr dazu
- PHP2Shell: Was die kritische PHP-Lücke für Unternehmen bedeutet – der Hauptartikel: was passiert ist, wen es trifft, was die Geschäftsführung veranlasst
- PHP2Shell bei Strato, IONOS, all-inkl und Co.: Was Hoster erledigt haben und was Kunden selbst tun müssen – Hoster-Stand, NAS, Firewalls
Quellen
- PHP-Projekt (Primärquelle): Security advisory – Critical remote code execution vulnerabilities, update now (21. Oktober 2026): php.net
- 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)
- CISA: Known Exploited Vulnerabilities Catalog, Einträge CVE-2026-109618 und CVE-2026-109619 (aufgenommen 26. Oktober 2026): cisa.gov
- SRF Kassensturz Espresso: PHP-Sicherheitslücke – Betrugsversuche nach Datenleck im Buchungssystem von TCS-Camping (26. Oktober 2026, 14:47 Uhr): srf.ch
- Sophos: Advisory PHP2Shell Vulnerabilities, Version 4 (22. Oktober 2026): sophos.com
- Tenable: php2shell – Frequently Asked Questions, Zeitlinie und Amazon-Hinweise (aktualisiert 22. Oktober 2026): tenable.com
- hostspezial.de: PHP2Shell (CVE-2026-109618) – prüfen, patchen, erkennen (aktualisiert 22. Oktober 2026): hostspezial.de
- ALL-INKL.COM: Wichtige Sicherheitsinformation zu CVE-2026-109618 und CVE-2026-109619 (22. Oktober 2026): all-inkl.com
Stand: 27. Oktober 2026, 8:45 Uhr (Erstfassung 23. Oktober, Update 27. Oktober). Die Lage entwickelt sich; maßgeblich sind die Hinweise des PHP-Projekts, des BSI und des eigenen Hosters.
Häufige Fragen
Werden die Lücken schon ausgenutzt?
Ja. Die US-Behörde CISA führt beide Lücken seit dem 26. Oktober 2026 als aktiv ausgenutzt, und mit dem Buchungssystem von TCS Camping in der Schweiz ist ein erster Datenabfluss öffentlich bekannt. Wer die Version seiner Systeme noch nicht schriftlich bestätigt hat, holt das heute nach und lässt zusätzlich nach Spuren suchen.
Reicht es, wenn das Hoster-Menü „PHP 8.3“ anzeigt?
Nein. Entscheidend ist die vollständige Nummer: Sicher ist 8.3.36 oder neuer. Zeigt das Menü nur den Zweig, beim Hoster nachfragen, ob das Update vom 21. Oktober 2026 auf dieser Plattform eingespielt ist, und sich Datum und Version bestätigen lassen.
Ist eine reine Informationsseite ohne Formular auch betroffen?
Ja, wenn sie auf PHP läuft. Der Angriff braucht kein Formular und keine Anmeldung; eine präparierte Anfrage an die Seite reicht. Was auf dem Server liegt oder von dort erreichbar ist, bestimmt den Schaden.
Unser Server läuft auf PHP 7.4 mit „Extended Support“ – ist das sicher?
Nur, wenn der Hoster oder der Linux-Anbieter die Korrektur in diese Version eingebaut hat. all-inkl, Hetzner und DomainFactory bestätigen das für ihre alten Versionen, Strato und IONOS haben sich dazu nicht geäußert. Ohne schriftliche Bestätigung gilt die Version als ungeschützt.
Was zeigt ein kostenloser Online-Check der eigenen Website?
Nur die Version, die der Server nach außen meldet – und die ist oft ausgeblendet oder bei Linux-Korrekturen unverändert. Ein Online-Check ersetzt die Prüfung auf dem Server oder die Bestätigung des Hosters nicht.
