Ein Sicherheitspatch ist verfügbar. Warum bleibt eine Website trotzdem offline? Bei PHP2Shell kann zwischen dem verfügbaren Fix und einem wieder freigegebenen Dienst mehr liegen als ein Paketupdate: eine alte Anwendung, ein ausstehendes Herstellerpaket oder ein Geschäftsprozess, den bislang niemand unter der neuen Laufzeit getestet hat.

PHP2Shell ist eine ernste Sicherheitslücke. Eine längere Unterbrechung kann trotzdem eine bewusste Schutzentscheidung sein. Aus einer nicht erreichbaren Website allein lässt sich weder ein erfolgreicher Angriff noch schlechte Arbeit des Betriebsteams ableiten.

Ursprünglicher Stand: 22. Oktober 2026; Sicherheitshinweis ergänzt am 24. Oktober. Nachricht mit betrieblicher Einordnung. Die beschriebenen Verzögerungsgründe sind mögliche Szenarien, keine Diagnose konkreter ausgefallener Websites.

Was bestätigt ist

Das PHP-Projekt veröffentlichte am 21. Oktober 2026 Sicherheitsupdates für zwei Schwachstellen: CVE-2026-109618 und CVE-2026-109619. Sie können Angreifern ohne Anmeldung ermöglichen, Code auf betroffenen Systemen auszuführen. Die Fehler liegen in der PHP-Laufzeit. Auch aktuelle Versionszweige sind betroffen; PHP2Shell ist keine reine Altsoftware-Lücke. Das Projekt nennt PHP-Installationen, die Webanfragen verarbeiten, als gefährdet. PHP-Sicherheitshinweis

Die veröffentlichten korrigierten Upstream-Versionen sind 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Bei Distributionspaketen zählt zusätzlich der Reparaturstatus des jeweiligen Anbieters. Ein Update des CMS oder eines Plugins allein behebt die darunterliegende PHP-Lücke nicht. PHP, Cloudflare

Cloudflare berichtet über beobachteten Angriffsverkehr und bereitgestellte WAF-Schutzmaßnahmen. Das Unternehmen fordert seine Kunden ausdrücklich weiter zum Patchen auf. Ein vorgeschalteter Filter ersetzt die reparierte Laufzeit also nicht. Beobachtete Angriffsversuche belegen zudem nicht, dass jede angegriffene Website kompromittiert wurde. Cloudflare-Bericht

Ergänzung vom 24. Oktober: CERT-EU nennt in seiner Aktualisierung vom 23. Oktober einen zusätzlichen PHP-RCE-Angriffsweg bei einer ungewöhnlichen Kombination aus Konfiguration und Anwendungscode. PHP empfiehlt dafür im gesonderten Hinweis, session.upload_progress.enabled=0 bis zum nächsten regulären Bugfix-Release zu setzen. Wer diese bereits am 21. Oktober genannte Mitigation umgesetzt hat, soll sie beibehalten; Anwendungen ohne den beschriebenen Wechsel des Session-Serializers zur Laufzeit können die Funktion laut PHP aktiviert lassen. Prüft den Hinweis gesondert: Die oben genannten Versionsupdates beantworten nicht pauschal jeden weiteren PHP-Sicherheitshinweis. PHP-Hinweis vom 23. Oktober, CERT-EU

Alte Versionsnummer heißt nicht automatisch ungepatcht

PHP 8.1 und ältere Zweige erhalten vom PHP-Projekt keine regulären Updates mehr. Für PHP2Shell stellt das Projekt allerdings minimale Quellcode-Backports für 7.4, 8.0 und 8.1 bereit. Distributionen und LTS-Anbieter können ebenfalls korrigierte Pakete liefern. Ein solcher Sonderfix bedeutet keine Rückkehr in den regulären Upstream-Support. PHP

Canonical führt beispielsweise korrigierte Ubuntu-Pakete auch für ältere PHP-Zweige auf. Für ältere Ubuntu-Ausgaben erfolgt die Versorgung über Expanded Security Maintenance. Ein Paket kann daher die alte PHP-Basisversion tragen und den Sicherheitsfix trotzdem enthalten. Maßgeblich sind die vollständige Paketversion, die Bezugsquelle und der zugehörige Sicherheitshinweis. Canonical

Das ist für die Einordnung entscheidend: Nicht jede alte Installation muss sofort einen großen Versionssprung machen. Wo ein passender, gepflegter Backport verfügbar ist, kann er den akuten Reparaturweg verkürzen. Fehlt dieser Weg, wird aus der Sicherheitsaktualisierung möglicherweise ein Migrationsprojekt.

Warum aus einem Update mehrere Tage werden können

Um den Aufwand für euer System einzuschätzen, klärt zuerst den Updateweg. Die folgenden Fragen führen von der Zuständigkeit bis zur Prüfung. Sie erklären mögliche Verzögerungen, nicht die Ursache eines bestimmten Ausfalls.

1. Wer liefert den Fix für euer System?

Betreibt ihr PHP selbst? Prüft beim Anbieter eurer Distribution oder Laufzeit, welches korrigierte Paket zu eurer Installation passt. Ein verfügbarer Backport kann einen großen Versionswechsel vermeiden.

Betreibt ein Hoster die Laufzeit oder steckt PHP in einem Herstellerprodukt? Dann braucht ihr dessen Auskunft zum betroffenen Produkt und zum passenden Update. NCSC-NL nennt unter anderem Geräte und Verwaltungsoberflächen mit eingebettetem PHP. Dort lässt sich die Laufzeit nicht unbedingt unabhängig austauschen. NCSC-NL

Fragt konkret: „Ist unsere Produktversion betroffen? Welches Update behebt beide CVEs? Wann können wir es einspielen?“ Haltet die Antwort, eine zuständige Person und den nächsten Prüftermin fest. Ein noch fehlendes Herstellerpaket ist eine andere Aufgabe als ein bereits verfügbares Update, das intern niemand übernimmt.

2. Muss die Anwendung auf eine neue Laufzeit wechseln?

Ist ein Versionswechsel nötig, prüft die Kompatibilität von CMS, Erweiterungen und eigenem Code. Verlangt die neue PHP-Version Anpassungen, müssen diese vor der Freigabe umgesetzt und getestet werden. Nicht jeder Sicherheitsfix erfordert eine Migration. Klärt deshalb zuerst den Paketweg aus Schritt eins.

Eine erreichbare Startseite ist noch kein erfolgreicher Funktionstest. Wählt mit dem Fachbereich die Abläufe aus, deren Ausfall das Geschäft unterbrechen würde:

Bei euch wichtig	Was ihr nach dem Update prüft
Kundenkonto	Anmelden und auf die vorgesehenen Daten zugreifen
Onlineshop	Testbestellung bis zur Bestätigung durchführen
Dokumentenportal	Datei hochladen und mit der vorgesehenen Rolle abrufen
Datenexport	Export erzeugen und das Ergebnis auf Vollständigkeit prüfen

Das sind Beispiele für euren Testplan. Fehlt eine wichtige Funktion, dokumentiert die Abweichung und die zuständige Rolle. So wird aus „Die Anwendung läuft noch nicht“ eine konkrete Aufgabe.

3. Ist der Fix tatsächlich aktiv?

Ein installiertes Paket und eine aktualisierte laufende Anwendung sind unterschiedliche Zustände. Canonical weist darauf hin, dass betroffene Anwendungen nach dem Update gegebenenfalls neu gestartet werden müssen. Lasst den Betrieb prüfen, welcher Stand die Webanfragen tatsächlich verarbeitet. Canonical

Gibt es zusätzlich Hinweise auf eine Kompromittierung? Dann muss das Team auch mögliche unbefugte Änderungen oder Zugriffe untersuchen. Ein Patch schließt eine Lücke; er macht frühere Eingriffe nicht rückgängig. Diese Untersuchung kommt im Verdachtsfall hinzu – sie ist keine Behauptung über sämtliche betroffenen Systeme.

Offline bleiben kann die richtige Zwischenentscheidung sein

CERT-EU empfiehlt, betroffene Systeme unverzüglich zu aktualisieren. Ist das nicht möglich, sollen Organisationen erwägen, öffentlich erreichbare Anwendungen zu isolieren, bis der Fix angewendet und verifiziert ist. CERT-EU

Unsere Einordnung: Eine solche Unterbrechung braucht eine verantwortliche Person, einen nächsten Prüftermin und klare Kriterien für die Rückkehr. „Wir warten auf das Herstellerpaket“ ist eine konkrete Abhängigkeit. „Wir lassen es erst einmal aus“ ist noch kein Wiederanlaufplan.

Für die Freigabe sollten Betrieb und Fachbereich gemeinsam beantworten:

Ist für die tatsächlich eingesetzte Laufzeit ein passender Fix installiert und aktiv?
Funktionieren die geschäftskritischen Abläufe unter diesem Stand?
Sind offene Verdachtsmomente bewertet und notwendige Folgemaßnahmen geklärt?
Wer entscheidet über die Wiederinbetriebnahme und informiert die Betroffenen?

Die Dauer lässt sich daraus nicht pauschal ableiten. Eine Installation mit gepflegten Paketen und brauchbaren Tests kann einen anderen Weg haben als eine jahrelang unveränderte Individualanwendung.

Warum regelmäßige Updates den Unterschied machen

Sicherheitsupdates schließen bekannte Lücken. Wer sie aufschiebt, lässt den betroffenen Fehler länger im System. NIST ordnet Patchmanagement deshalb als vorbeugende Wartung ein: Updates identifizieren, priorisieren, installieren und ihre wirksame Installation überprüfen. NIST SP 800-40 Rev. 4

Für Legacy-Anwendungen kommt ein zweiter Punkt hinzu: Wer Kompatibilität und Supportende regelmäßig prüft, kann notwendige Anpassungen planen. Werden sie erst im Sicherheitsnotfall sichtbar, konkurrieren Migration, Fehlersuche und Wiederanlauf um dieselbe Zeit. Regelmäßige Pflege kann diesen Rückstand verringern. Sie verhindert weder jede neue Lücke noch garantiert sie ein störungsfreies Update.

Plant deshalb einen wiederholbaren Ablauf: Wer beobachtet Sicherheitshinweise? Wer bewertet betroffene Systeme? Wer spielt Updates ein, testet die wichtigen Funktionen und gibt den Betrieb frei? Für kritische Lücken braucht dieser Ablauf einen dringlichen Weg; das nächste reguläre Wartungsfenster ist nicht automatisch ein vertretbarer Termin.

Aus offenen Updates einen nachvollziehbaren Prozess machen

Für jedes betroffene System sollten Verantwortung, Maßnahme, Termin und Prüfergebnis zusammenstehen. Verknüpft die technische Arbeit mit dem Geschäftsprozess: Wer braucht den Dienst? Was muss wieder funktionieren? Welche offene Abhängigkeit verhindert die Freigabe?

In Kopexa könnt ihr betroffene Assets, Risiken und Maßnahmen zusammenführen und eure Prozesse mit BPMN abbilden. Nachweise liegen an den Maßnahmen. So lässt sich festhalten, welche Prüfung erledigt ist und welche Arbeit noch offen bleibt. Updates und technische Tests führt weiterhin euer Betrieb durch.

PHP2Shell: Warum manche Websites länger offline bleiben