PHP2Shell: Angriffe liefen, bevor die Lücke öffentlich wurde

Die Fakten: Zwei kritische Lücken in PHP selbst

Am 21. Oktober 2026 wurden zwei kritische Schwachstellen in PHP veröffentlicht: CVE-2026-109618 und CVE-2026-109619. Beide erlauben Angreifern, ohne Authentifizierung beliebigen Code auf dem Server auszuführen – Remote Code Execution, kurz RCE. Der CVSS-Score liegt mit 9,2 von 10 Punkten im kritischen Bereich.

Der entscheidende Unterschied zu den meisten Sicherheitsmeldungen: Betroffen ist nicht ein einzelnes Plugin oder eine schlecht programmierte Webanwendung, sondern PHP selbst – und zwar in allen gängigen Betriebsmodi, also mod_php, PHP-FPM und php-cgi. Damit ist grundsätzlich jeder Webserver im Risiko, der PHP-Anfragen ausliefert. Das ist der Grossteil des dynamischen Webs.

Geschlossen sind die Lücken in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Gefunden wurden sie durch KI-gestützte Sicherheitsforschung unter Beteiligung von Calif, Wiz und OpenAI – worauf wir gleich zurückkommen, denn dieser Punkt ist mindestens so wichtig wie die Lücken selbst.

Der Zeitstrahl: Vier Tage Vorlauf für Angreifer

Was diese Woche gezeigt hat, ist weniger die Schwachstelle als ihr Tempo:

• 17. Oktober: Das Threat-Intelligence-Team von AWS beobachtet erste Ausnutzungsversuche – vier Tage, bevor die Schwachstellen überhaupt öffentlich bekannt sind. Der Exploit ist hier vor der offiziellen Information da.
• 21. Oktober: Die Schwachstellen werden veröffentlicht, pünktlich liegen die gefixten PHP-Versionen bereit.
• 10 Stunden vor der Bekanntgabe: Cloudflare registriert in seinem Netzwerk allein bereits tausende Ausnutzungsversuche.
• 45 Minuten nach der Bekanntgabe: Zehntausende Versuche.
• Innerhalb von zwei Stunden: Hunderttausende.
• Nach rund einem Tag: Millionen – wiederum nur in Cloudflares Netzwerk (Angaben von Cloudflare-CEO Matthew Prince).

Diese Zahlen sind kein Alarmismus, sondern Messwerte. Sie zeigen: Die Zeitspanne zwischen Veröffentlichung und Massenausnutzung ist auf Stunden geschrumpft. Früher blieben Administratoren Tage oder Wochen Zeit, um in Ruhe zu patchen. Heute beginnen die automatisierten Scan- und Angriffswellen, bevor die meisten Organisationen die Meldung überhaupt gelesen haben.

KI beschleunigt beide Seiten

Der zweite Punkt dieser Woche: Die Lücken wurden durch KI-gestützte Sicherheitsforschung gefunden. Das ist grundsätzlich erfreulich – Schwachstellen, die entdeckt und geschlossen werden, bevor jemand seriös darüber stolpert, sind der sinnvollste Zweck der Technologie.

Dieselbe Beschleunigung arbeitet aber auch auf der Angreiferseite. Ausnutzungscode für bekanntgewordene Schwachstellen entsteht heute in Stunden statt Monaten, und Scans über das gesamte Internet laufen automatisch. Die Folge ist eine neue Normalität: KI erhöht das Tempo, in dem Schwachstellen gefunden werden – und das Tempo, in dem sie ausgenutzt werden. Beides gleichzeitig.

Für Unternehmen heisst das konkret: Es reicht nicht mehr, quartalsweise ein Wartungsfenster zu planen und Sicherheitsupdates «irgendwann danach» einzuspielen. Wer Wochen braucht, verliert diese Rennen fast immer.

Was heute entscheidet: Patchgeschwindigkeit und Monitoring

Wenn das Fenster von der Bekanntgabe bis zur Massenausnutzung auf Stunden schrumpft, verschiebt sich die gesamte Verteidigung auf zwei Faktoren:

1. Patchgeschwindigkeit. Sicherheitsupdates der Hersteller müssen so schnell wie möglich auf den Systemen ankommen – nicht beim nächsten Wartungszyklus, sondern in Tagen oder Stunden. Dazu gehört auch, die Update-Lage jederzeit zu kennen: Welche Versionen laufen wo? Wer trägt die Verantwortung, eine Meldung innerhalb von Stunden zu bewerten und umzusetzen?
2. Kontinuierliches Monitoring. Weil nicht jede Schwachstelle vor der Ausnutzung bekannt wird (siehe 17. Oktober), braucht es Systeme, die auffälliges Verhalten auf Servern und im Netzwerk erkennen und melden. Patches sind die erste Verteidigungslinie, Monitoring die zweite.

Ein oft übersehener Punkt bei diesem Vorfall: PHP steckt heute häufig in Containern. Containerisierte Anwendungen aktualisieren sich nicht selbst – sie brauchen neue Basis-Images, die nachgebaut und neu ausgerollt werden müssen. Ein Container-Host, auf dem der Host gepatcht ist, schützt die Anwendung im veralteten Container nicht.

Wie wir bei Solity reagiert haben

Für uns war das kein theoretisches Szenario, sondern ein ganz normaler Arbeitstag im Betrieb:

• Wir haben am Tag der Veröffentlichung alle von uns betreuten Server, Dienste und Netzwerke umgehend geprüft.
• Die betroffene Komponente wurde identifiziert und noch am selben Tag geschlossen – auch bei containerisierten Anwendungen, wo das einen Rebuild des Images bedeutet.
• Das laufende Monitoring zeigt seither durchgehend unauffällige Systeme.
• Sicherheitsupdates der Hersteller werden bei uns automatisch getrackt und zeitnah eingespielt – dieser Prozess ist genau für solche Tage gebaut.

Geprüft und geschlossen heisst dabei bewusst nicht «unangreifbar» – solche Zusicherungen sind in der IT nicht ehrlich. Es heisst: Die bekannte Schwachstelle ist behoben, die Systeme werden weiter beobachtet, und der Prozess für die nächste Meldung läuft genauso ab.

Die offene Flanke: Alles, was niemand betreut

Das ehrliche Fazit dieser Woche lautet nicht «alle waren verwundbar», sondern: Die Zeitspanne, in der man reagieren kann, ist klein geworden. Und die entscheidende Frage ist, wer bei Ihnen in dieser Zeitspanne reagiert.

Die grösste Risiken liegen erfahrungsgemäss dort, wo niemand hinschaut:

• Server und Webanwendungen, die einmal aufgesetzt wurden und seitdem «einfach laufen» – ohne Update-Verantwortliche, teils ohne dass noch jemand weiss, wem sie gehören.
• Geräte im Homeoffice und im Firmengebäude, die einen eigenen Webdienst mitbringen: Router, NAS-Systeme, Smart-Home-Komponenten. Sie erhalten Sicherheitsupdates oft gar nicht oder deutlich später – und stehen trotzdem im Netz.
• Anwendungen bei Anbietern oder auf alten Systemen, deren PHP- oder Software-Version niemand regelmässig prüft.

Genau diese nicht betreuten Systeme sind die Flanke, über die Angreifer heute bevorzugt reinkommen – nicht durch ausgefeilte Angriffe, sondern durch automatisierte Scans, die rund um die Uhr das ganze Internet nach veralteten Versionen abgrasen. Wenn Sie nicht sicher wissen, wer auf Ihren Servern, Anwendungen und Netzwerken Update-Verantwortung trägt, ist das die erste Frage, die es zu klären gilt – am besten mit IT-Fachleuten, die solche Lagen täglich bewerten.

Fazit

Diese Woche hat drei Dinge gezeigt, die bleiben:

1. KI beschleunigt das Auffinden von Schwachstellen – und ihre Ausnutzung. Das ist die neue Normalität, kein Ausnahmezustand.
2. Das Zeitfenster zwischen Bekanntgabe und Massenausnutzung liegt bei Stunden, manchmal liegt der Exploit vor der offiziellen Meldung.
3. Entscheidend sind deshalb Patchgeschwindigkeit und kontinuierliches Monitoring – und ein klarer Verantwortlicher, der beides betreibt.

Wer Systeme betreibt, die niemand aktiv pflegt, sollte das zeitnah ändern lassen. Die Rechnung, «bisher ist nichts passiert», geht nur so lange auf, bis sie nicht mehr aufgeht.

---

Sie sind unsicher, ob alle Ihre Server, Anwendungen und Netzwerkgeräte sauber gepatcht und überwacht sind? Wir schauen für Sie genau hin – kontaktieren Sie uns für ein unverbindliches Gespräch. Wie unsere betreute Infrastruktur aussieht, erfahren Sie unter Managed IT und Netzwerk & Security.