Viele Webseiten werden gerade vorsorglich abgeschaltet. Das kann verantwortungsvoll sein. Es ist aber noch kein Sicherheitsnachweis. Mit PHP2Shell wurden am 21. Oktober 2026 zwei kritische Schwachstellen in PHP veröffentlicht: CVE-2026-109618 und CVE-2026-109619. Beide können unter bestimmten Bedingungen unauthentifizierte Codeausführung ermöglichen.
Die Reaktion ist nachvollziehbar: PHP steckt nicht nur in klassischen Webseiten, sondern auch in WordPress, Shops, Portalen, Appliances und Verwaltungsoberflächen. Wer seine Instanzen nicht zeitnah identifizieren und patchen kann, nimmt einen öffentlich erreichbaren Dienst im Zweifel besser aus dem Netz. ENISA empfiehlt ebenfalls, internetexponierte Anwendungen zuerst zu priorisieren und sie zu isolieren, wenn eine sofortige Behebung nicht möglich ist.
Worum geht es bei PHP2Shell?
Die beiden CVEs betreffen die PHP-Laufzeit selbst, nicht ein einzelnes WordPress-Plugin. Laut PHP können beide Fehler eine Remote-Code-Ausführung ohne Anmeldung ermöglichen. CVE-2026-109618 hängt mit Fehlerbehandlung bei Speichermangel zusammen, CVE-2026-109619 mit internem Zustand, der nach einer Anfrage unzulässig weiterverwendet werden kann. Besonders hoch bewertet PHP das Risiko bei Apache mit mod_php; betroffen sein können jedoch auch PHP-FPM, CGI, LiteSpeed und FrankenPHP.
Die festen Versionen sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. PHP 8.1 und ältere Reihen erhalten vom Projekt keine regulären Sicherheitsupdates mehr. Wer dort bleibt, braucht einen belastbaren Backport des Distributors oder einen Upgrade-Plan – nicht nur eine beruhigende Versionsnummer.
Abschalten: sinnvolle Notmaßnahme, aber kein Abschluss
Eine Webseite vorübergehend offline zu nehmen, reduziert die Angriffsfläche. Das ist eine vernünftige Entscheidung, wenn der Patch nicht kontrolliert eingespielt werden kann. Gleichzeitig sendet ein sichtbarer Wartungshinweis ein Signal nach außen: Hier wird der Vorfall ernst genommen. Das ist besser als still weiterzulaufen, obwohl niemand weiß, welche PHP-Version aktiv ist.
Aber: Offline nehmen ersetzt weder Inventarisierung noch Analyse. Sobald ein Server zuvor erreichbar war, bleibt die entscheidende Frage bestehen: Was lief dort tatsächlich, welche Logs gibt es, welche Änderungen sind auffällig und wer ist für Betrieb und Updates verantwortlich?
„Die Lücke existierte doch schon lange“ – was man daraus ableiten kann und was nicht
Ein Fehler entsteht nicht erst am Tag der CVE-Veröffentlichung. Der fehlerhafte Code kann lange zuvor ausgeliefert worden sein. Daraus folgt aber nicht automatisch, dass genau diese Schwachstelle bereits ausgenutzt wurde. Ohne verwertbare Logs, Endpoint-Telemetrie oder belastbare Threat-Intelligence bleibt eine Aussage zur früheren Ausnutzung Spekulation.
Die wichtigere Schlussfolgerung ist praktischer: Ein Patch schließt den bekannten Angriffsweg für die Zukunft. Er beweist nicht, dass ein System vor dem Patch sauber war. Wer ein exponiertes System erst jetzt patcht, sollte deshalb nicht nur die Version prüfen, sondern auch nach Spuren suchen: neue oder veränderte PHP-Dateien, unbekannte Admin-Konten, verdächtige Cronjobs, auffällige Prozesse, ausgehende Verbindungen, Änderungen an Webserver- und Benutzerkonten sowie ungewöhnliche Anfragen in den Zugriffslogs.
Die eigentliche Schwachstelle heißt oft: Niemand kümmert sich
Jetzt wird es besonders spannend bei Systemen ohne klaren Eigentümer. Die kleine Vereinsseite, der alte Shop, das Kundenportal eines früheren Dienstleisters oder die Verwaltungsoberfläche, die „einfach läuft“: Genau dort fehlen häufig Inventar, Wartungsvertrag, getesteter Wiederanlauf und eine Person mit Mandat zum Handeln.
Eine Sicherheitslücke macht diese organisatorische Lücke sichtbar. Nicht jede alte Website wird kompromittiert. Aber jedes nicht zuordenbare, nicht überwachte und nicht patchbare System ist ein unnötiges Risiko – und im Ernstfall ein Problem für Verfügbarkeit, Datenschutz, Kommunikation und Wiederherstellung.
Was jetzt in der richtigen Reihenfolge zu tun ist
- Inventarisieren: Welche Domains, Anwendungen, Container, Appliances und Admin-Oberflächen verwenden PHP? Welche sind von außen erreichbar?
- Patchstand verifizieren: Nicht raten, sondern die tatsächlich laufende Runtime und den Paketstand prüfen. Bei Managed Hosting den Anbieter schriftlich einbeziehen.
- Exponierte Systeme priorisieren: Erst öffentlich erreichbare Anwendungen und privilegierte Oberflächen, dann interne Abhängigkeiten.
- Wenn Patchen nicht sofort geht: kontrolliert isolieren oder abschalten. Die temporären PHP-Maßnahmen reduzieren einzelne Wege, sind laut PHP aber kein vollständiger Ersatz für ein Update.
- Nach dem Patch prüfen: Logs, Dateien, Konten, Aufgaben und ausgehende Verbindungen prüfen; Sicherungen und Wiederanlauf testen.
- Verantwortung festlegen: Für jede Anwendung braucht es Eigentümer, Updateweg, Eskalation und einen nachvollziehbaren Nachweis.
Fazit
Die richtige Reaktion auf PHP2Shell ist weder Panik noch Abhaken nach dem Update. Abschalten kann kurzfristig klug sein. Patchen ist zwingend. Sicherheit entsteht aber erst, wenn klar ist, was betrieben wird, wer zuständig ist und ob das System auch vor dem Patch bereits auffällig war.
Stand: 22. Oktober 2026. Primärquellen: PHP Security Advisory, ENISA und NHS England.
Was siehst du anders?
Widerspruch ist willkommen. Schreib klar, bleib beim Thema und bring ein Argument mit. Deine E-Mail-Adresse wird nicht veröffentlicht.