PHP2Shell: Was Hoteliers jetzt prüfen müssen

Zwei Schwachstellen im Kern der Programmiersprache PHP, registriert als CVE-2026-109618 und CVE-2026-109619, erlauben Angreifern das Ausführen von Schadcode aus der Ferne. Das PHP-Sicherheitsteam bewertet beide mit 9,2 von 10 Punkten nach CVSS 4.0, dem Standard zur Einstufung der Schwere von IT-Schwachstellen. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) stuft das Risiko mit der Warnstufe Orange ein.

Cloudflare registrierte nach der öffentlichen Bekanntgabe binnen 45 Minuten Zehntausende Angriffsversuche, bis zum 22. Oktober Millionen. Bei der Zahl verwundbarer Dienste liegt Deutschland weltweit auf Platz zwei, knapp hinter den USA.

Warum die Lücke nicht nur das PMS trifft

Unter dem Sammelnamen „PHP2Shell“ fassen Sicherheitsforscher zwei Speicherfehler im PHP-Kern zusammen. Beide ermöglichen Remote Code Execution, kurz RCE, also das Einschleusen und Ausführen von Fremdcode auf einem Server, ohne dass sich der Angreifer zuvor anmelden muss. Betroffen sind laut den Entdeckern beim Sicherheitsanbieter Wiz alle PHP-Versionen ab 5.4. Als sicher gelten erst die gepatchten Fassungen 8.5.12, 8.4.27, 8.3.36 und 8.2.35.

Entscheidend ist, wo die Angriffsfläche liegt. Bisher richtete sich die Aufmerksamkeit in der Hotellerie vor allem auf Ransomware und auf Angriffe gegen Buchungs- und Property-Management-Systeme (PMS). PHP2Shell sitzt tiefer: nicht in der Hotelsoftware selbst, sondern im Webserver darunter. Betroffen ist jeder Betrieb, der eigene webbasierte Systeme betreibt oder hosten lässt. Laut Dehoga Bayern nutzen zahlreiche Webanwendungen im Gastgewerbe PHP: Content-Management-Systeme wie WordPress, Joomla, TYPO3 oder Contao, dazu Online-Shops sowie webbasierte Buchungs- und Reservierungssysteme. Auch PMS können betroffen sein, sofern sie selbst oder bei Hosting-Dienstleistern laufen.

Was ein erfolgreicher Angriff bedeutet, beschreibt Dehoga Bayern laut AHGZ: Kriminelle können Daten stehlen, Websites manipulieren oder Schadsoftware einschleusen. Erste Angriffe auf betroffene Systeme würden bereits beobachtet, die Details der Schwachstellen seien öffentlich einsehbar, entsprechende Angriffswerkzeuge zirkulierten.

Wie viele Systeme betroffen sind

PHP bildet nach Einschätzung von TechTarget geschätzt 70 Prozent des Webs ab. Die Expositionszahlen variieren je nach Messmethode. Palo Alto Networks identifizierte laut TechTarget mehr als 22,6 Millionen exponierte Instanzen, die potenziell verwundbar sind. Der Scanner des Dienstleisters Censys erfasste laut Heise weltweit mehr als 41 Millionen PHP-Dienste mit verwundbaren Versionsnummern; nach knapp acht Millionen Updates sank die Zahl auf 33,5 Millionen. Das PHP2Shell-Dashboard von Censys meldete laut Fortinet in einem Snapshot vom 22. Oktober rund 36,7 Millionen ins Internet exponierte Dienste mit potenziell betroffenen Versionen. Die Werte liegen auseinander, weil Messzeitpunkt und Erhebungsmethode variieren; einen einheitlichen Stand gibt es nicht.

Für Deutschland nennt Heise unter Berufung auf Censys fast elf Millionen gefundene PHP-Dienste, rund 4,2 Millionen davon mit als verwundbar geltenden Versionsnummern. In der Schweiz waren laut einer Bilanz des Schweizer Fernsehens SRF, zitiert über polizeiticker.ch, zeitweise mehr als 100.000 Websites nicht erreichbar.

Die Vorgeschichte: ein Audit, ein Leak und eine KI als Entdeckerin

Die technische Grundlage reicht weiter zurück, als die CVE-Vergabe vermuten lässt. Ein Security-Audit benannte laut Borncity bereits 2024 die Out-of-Memory-Schwachstelle, die nun als CVE-2026-109618 geführt wird. Offiziell entdeckt wurden die Lücken laut Wikipedia am 1. August 2026, als Entdecker sind Calif, OpenAI und Wiz gelistet. Nach Angaben von TechTarget half dabei das KI-Modell GPT-5.6 Sol, die zugrunde liegenden Speicherfehler aufzuspüren.

Die Offenlegung musste vorgezogen werden, weil die Kennungen durchsickerten. Ein Nutzer veröffentlichte laut Infosecurity Magazine am 20. Oktober einen Forenbeitrag, der die geheim gehaltenen CVE-Kennungen enthüllte. Das PHP-Sicherheitsteam reagierte mit einer Vorab-Mitteilung, am 21. Oktober folgten die Fixes. Der erste real beobachtete Angriffsversuch datiert laut Amazon Threat Intelligence allerdings schon auf den 17. Oktober, vier Tage vor der öffentlichen Bekanntgabe.

Was das für den Hotelbetrieb konkret heißt

Wer eigene Websites, Shops oder Buchungsmasken betreibt, muss zwei Dinge klären: welche PHP-Version läuft, und wer dafür verantwortlich ist, der eigene Betrieb oder der Hosting-Dienstleister. Läuft eine Version unterhalb der gepatchten Stände 8.5.12, 8.4.27, 8.3.36 oder 8.2.35, besteht Handlungsbedarf.

Dehoga Berlin formuliert für den Fall, dass ein Update nicht sofort möglich ist, eine klare Linie: die betroffene Anwendung vorübergehend vom Netz nehmen, bis sie gepatcht ist.

„Ein paar Stunden offline sind deutlich günstiger als ein gehackter Server oder ein Datenschutzvorfall.“ – Dehoga Berlin

Für Betriebe, die ihre Systeme extern hosten lassen, verschiebt sich die Aufgabe von der Technik zur Kommunikation. Eine Rückfrage beim Dienstleister, ob die PHP-Version aktualisiert wurde und wann, gehört auf die Tagesordnung, schriftlich und mit Datum. Das deckt sich mit der Stoßrichtung der jüngsten Vorfälle in der DACH-Hotellerie. Nach dem Sicherheitsvorfall beim österreichischen eTourismus-Anbieter Seekda am 11. August und den Fällen bei ibelsa sowie HotelNetSolutions gewinnt die Frage nach Transparenz bei Sicherheitsvorfällen und der konsequenten Einhaltung von Informationspflichten an Gewicht. Buchungssysteme, PMS, Channel Manager und Zahlungsdienstleister tauschen kontinuierlich Daten aus; eine Lücke bei einem Anbieter kann zahlreiche Betriebe treffen.

Der Unterschied zu diesen Lieferkettenvorfällen: PHP2Shell betrifft nicht nur den einen Dienstleister, sondern die Technik unter nahezu jedem webbasierten System. Der Prüfaufwand ist gering, das Zeitfenster aber eng. Die Angriffe laufen bereits, bevor viele Betriebe die Meldung überhaupt zur Kenntnis genommen haben.