21. Oktober: Die Niederlande im Dunkeln. Was PHP2Shell uns lehrt

Zu diesem Zeitpunkt gab es keinen bestätigten Hack. Diese Organisationen schalteten ihre Dienste vorsorglich ab, weil es noch keinen Patch gab.

Kurz gesagt. PHP2Shell besteht aus zwei kritischen Schwachstellen in PHP selbst, der Programmiersprache hinter unter anderem WordPress, Drupal und Magento. Ein Angreifer kann damit ohne Anmeldung einen Server übernehmen. Den Patch gibt es seit dem 21. Oktober. Doch die Zeit zwischen einer Schwachstelle und ihrem ersten Missbrauch ist fast verschwunden, deshalb ist es mit dem Patchen allein nicht getan. Prüfen Sie auch, ob bereits jemand eingedrungen ist, tauschen Sie sensible Zugangsdaten aus und sorgen Sie dafür, dass Sie beim nächsten Mal Zeit gewinnen können.

Was passiert ist, einfach erklärt

Am 21. Oktober warnte das NCSC vor zwei kritischen Schwachstellen in PHP: CVE-2026-109618 und CVE-2026-109619, zusammen PHP2Shell genannt. Die Lücke steckt nicht in einem Plug-in oder Theme, sondern im Motor selbst. Deshalb kann schon eine einfache „Hello World“-Seite verwundbar sein. Laut NCSC kann eine einzige Anfrage ohne Anmeldung genügen, um Code auf dem Server auszuführen. Betroffen sind alle Versionen ab PHP 5.

Der Patch kam am selben Nachmittag gegen 16:00 Uhr niederländischer Zeit, einen Tag früher als geplant. Die aktualisierten Versionen sind 8.2.35, 8.3.36, 8.4.27 und 8.5.12. PHP 8.1 und älter erhalten kein reguläres Update (dort ist der Umstieg auf eine unterstützte Version die einzige echte Lösung).

Die eigentliche Geschichte: Die Zeit zum Patchen ist weg

Der Schweregrad ist das eine. Die eigentliche Geschichte ist das Tempo.

• Missbrauch vor der Veröffentlichung. Amazon sah bereits am 17. Oktober einen Angriffsversuch auf einen seiner Honeypots. Das war vier Tage, bevor es den Patch gab.
• Tausende, dann Millionen. Cloudflare zählte Tausende Versuche in den zehn Stunden vor der Veröffentlichung, Zehntausende in der Dreiviertelstunde danach und inzwischen Millionen.
• Ein Patch als Schatzkarte. Gepatchte PHP-Versionen standen schon einige Stunden vor dem vereinbarten Zeitpunkt online. Für einen Angreifer ist das eine Schatzkarte: Der Patch zeigt genau, wo die Lücke war.
• 81 Minuten. Forscher von ELLIO beobachteten, wie ein Angreifer in 81 Minuten von der ersten Erkundung bis zu einer installierten Web Shell kam, einer Hintertür auf dem Server. Versuchen Sie mal, in dieser Zeit einen Change genehmigt zu bekommen.

Am 22. Oktober meldete das NCSC erste Hinweise darauf, dass die Lücke auch erfolgreich ausgenutzt wurde.

Und KI beschleunigt beide Seiten. Forscher von Wiz fanden die Schwachstellen mithilfe von KI-Modellen. Die niederländischen Cybersecurity-Experten Inge Bryan und Bert Hubert erwarten, dass KI solche Lücken häufiger und schubweise ans Licht bringt. Dadurch können sie auch Angreifer ausnutzen, die keine Superhacker sind.

Was den Unterschied machte: Zeit gewinnen können

Am 21. Oktober gab es grob drei Situationen.

Viele Organisationen konnten nur abschalten. Das war die vernünftige Entscheidung, auch das NCSC riet dazu. Doch es kostete Stunden an Service und Umsatz. EasyToys war rund acht Stunden offline.

Eine zweite Gruppe hatte eine Schutzschicht, die Zeit verschaffte. Der WordPress-Hoster Heijsen hielt seine rund 1.000 Kunden mit zusätzlichen Firewall-Regeln und einem Upload-Limit online, bis der Patch verfügbar war.

Die dritte Gruppe hatte keine Wahl. Kunden von NotuBiz und Exact waren davon abhängig, was ihr Anbieter tat. Auch ein Teil der Security-Appliances auf dem Markt nutzte selbst PHP. Dort warteten die Kunden auf ein Update für genau das Gerät, das sie schützen sollte.

Zeit gewinnen, bis Sie selbst gepatcht haben

Ein Patch, der existiert, ist noch kein Patch, der läuft. Bei vielen Organisationen liegen dazwischen noch Tests, ein Change und ein Wartungsfenster. Und genau in dieser Phase meldete das NCSC die ersten Hinweise auf erfolgreichen Missbrauch.

In diesem Moment zählt eine Schutzschicht im Netzwerk. Cato entwickelte mit KI-gestützter Bedrohungsforschung neue IPS-Signaturen gegen die bekannten Angriffsszenarien. Am 21. Oktober gingen diese zunächst im Silent Mode live, zur Validierung. Ab dem 22. Oktober folgte der Rollout im Blockiermodus, und am 23. Oktober war dieser laut Cato im gesamten Netzwerk bestätigt.

Ehrlich gesagt: Am 21. Oktober selbst half das noch nicht. Der blockierende Schutz kam einen Tag nach dem Patch. Doch obwohl der Patch da war, war er oft noch nicht installiert.

Für Kunden mit aktiviertem IPS greifen die Signaturen automatisch. Es muss nichts eingestellt und pro Server oder Gerät nichts aktualisiert werden. Die Cato-Plattform selbst war nicht betroffen; laut Cato nutzen ihre Kernkomponenten, darunter die Sockets, kein PHP.

Das ist eine Brücke, keine Lösung. Sie verschafft Zeit, bis Sie selbst gepatcht haben, für den Datenverkehr, der über Cato läuft.

Diese Einschränkung ist wichtig. Der IPS-Schutz wirkt nur für Datenverkehr, den Cato inspiziert, und nur, wenn IPS aktiviert ist. Eingehender Datenverkehr ist ebenfalls abgedeckt, aber Cato führt keine TLS-Inspektion eingehender Verbindungen durch. Eine öffentliche Website, die per HTTPS erreichbar ist, fällt daher nicht unter diese Signaturen. Dafür braucht es eine Web Application Firewall (WAF). Und Patchen bleibt in jedem Fall nötig.

Mit dem Patch ist es nicht getan

Auch wer inzwischen gepatcht hat, ist noch nicht fertig:

• Schauen Sie zurück. Untersuchen Sie, ob Angreifer schon vor dem Patch eingedrungen waren, mindestens zurück bis zum 17. Oktober.
• Tauschen Sie Geheimnisse aus. Eine der Schwachstellen kann Speicher anderer Anfragen offenlegen. Ersetzen Sie deshalb Passwörter, Tokens und API-Schlüssel auf Servern, die verwundbar waren.
• Achten Sie auf ungewöhnliches Verhalten. Ein Webserver, der plötzlich eine Shell oder ein Netzwerk-Tool startet oder unerwartet nach außen verbindet, ist ein starkes Signal. Blockieren Sie ausgehenden Datenverkehr von Servern standardmäßig und erlauben Sie nur, was nötig ist.
• Behalten Sie Limits bei. Grenzen für die Größe von Anfragen und Uploads bleiben sinnvoll, auch nach dem Patch.

Die vielen Nachzügler

Laut einer Untersuchung des niederländischen öffentlich-rechtlichen Senders NOS sind rund 145.000 niederländische Websites möglicherweise noch verwundbar, auch wenn sich das aus der Ferne nicht mit Sicherheit feststellen lässt. Bert Hubert schätzt, dass 47 Prozent der Websites mit PHP eine Version nutzen, die keinen Support mehr erhält.

Und PHP 8.2 erhält nach dem 31. Dezember 2026 keine Sicherheitsupdates mehr. In gut zwei Monaten kommt also eine weitere Version ohne Patches hinzu.

Das nächste PHP2Shell ist nur eine Frage der Zeit. Die Frage ist, wie viel Zeit Sie sich dann verschaffen können.

Fünf Fragen für Ihre Organisation

Das NIST Cybersecurity Framework ist dabei ein guter Spiegel. Fünf seiner sechs Funktionen, angewendet auf den 21. Oktober:

1. Identify. Wissen Sie, wo PHP läuft, auch bei Ihren SaaS-Anbietern und in Appliances?
2. Protect. Was schützt Sie zwischen dem Moment, in dem eine Lücke bekannt wird, und dem Moment, in dem Sie patchen?
3. Detect. Würden Sie merken, wenn ein Server plötzlich eine Verbindung nach außen aufbaut?
4. Respond. Wer entscheidet über das Abschalten, und auf welcher Grundlage?
5. Recover. Woher wissen Sie, dass es sicher ist, wieder einzuschalten?

Wo Momentum steht

Momentum ist spezialisierter Implementierungspartner von Cato Networks in EMEA. Nutzen Sie Cato über Momentum, prüfen wir gern mit Ihnen, ob IPS aktiviert ist, welchen Datenverkehr Cato inspiziert und wo Ihre öffentlichen Anwendungen zusätzlich eine WAF brauchen. Stehen Sie noch am Anfang, ermitteln wir gemeinsam, wo PHP in Ihrer Umgebung läuft und wo eine Brücke Ihnen beim nächsten Mal Zeit verschafft.

Ein Gespräch ist unverbindlich. Lieber jetzt in aller Ruhe als beim nächsten Mal.

Quellen: NCSC, NOS, Binnenlands Bestuur, DutchBrief, Quote, The Register, The Next Web, CSO Online, ELLIO, Wiz, Qualys, EenVandaag, Help Net Security, PHP, Cato Networks.