PHP2Shell: zwei kritische PHP-Lücken und nötige Schritte

Was veröffentlicht wurde und warum Eile nötig ist

Stand 22.Oktober 2026. PHP veröffentlichte am 21.Oktober Sicherheitsupdates für CVE-2026-109618 und CVE-2026-109619, gemeinsam PHP2Shell genannt. Betroffen ist die PHP-Engine für Webanfragen, nicht lediglich ein CMS-Plugin. Eine Ausnutzung kann nicht authentifizierte Codeausführung auf verwundbaren Servern ermöglichen. Das verlangt dringendes Handeln, beweist jedoch keinen bereits erfolgten Angriff auf eine bestimmte Website.

Die offizielle Warnung umfasst PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. PHP bewertet mod_php als höchstes Risiko und beschreibt eine nachgewiesene Ausnutzung vor Anwendungscode. Kleine Websites, fehlende Anmeldeformulare oder aktuelle Plugins beruhigen daher nicht ausreichend. Ermittle das tatsächlich Webanfragen bedienende PHP und den passenden Fix. Die Exposition hängt von Version, Anbieter und Konfiguration ab; dieser Beitrag beurteilt keinen einzelnen Server.

Die beiden Fehler und korrigierte Versionen

CVE-2026-109618 betrifft Speicherbeschädigung bei Speicherknappheit. Bei CVE-2026-109619 kann interner Zustand seinen zugehörigen Speicher überleben und von einer späteren Anfrage desselben Workers wiederverwendet werden. Die PHP Foundation erläutert Ursachen und Korrektur. Die Unterscheidung verhindert eine vermeintliche Universallösung durch Konfiguration. Ein Angriff muss für die Updateentscheidung nicht reproduziert werden; dieser Text enthält keine Exploittests öffentlicher Dienste oder Befehle zum absichtlichen Auslösen eines Absturzes.

Am 21.Oktober erschienen 8.5.12,8.4.27,8.3.36 und 8.2.35 als korrigierte Releases. Prüfe vor Eingriffen die aktuelle Meldung auf spätere Revisionen. Distributionen können Fixes ohne dieselben Basisnummern rückportieren; Ubuntu nennt konkrete Pakete in USN-8948-1. Vergleiche nicht nur die Interpreterzeichenfolge: Prüfe Anbieterhinweis und Paket. PHP 8.1 und älter sind außerhalb des Projektsupports. Eine Distributorkorrektur stellt diesen Support nicht wieder her.

CVE-2026-109618 / CVE-2026-109619
PHP 8.2.35 | 8.3.36 | 8.4.27 | 8.5.12

Was Hosting und Administration bestätigen sollten

Bitte bei verwaltetem Hosting um Bestätigung beider CVEs: installiertes Paket, betroffener Dienst und korrigierte aktive Prozesse. Erfasse Domains, Pools, Container und Produkte mit eingebettetem PHP, nicht nur die Hauptkonsole. Die Kommandozeilenversion beweist nicht zwingend die Websiteversion. Nutze als Administrator den dokumentierten Anbieter- oder Distributionskanal, mit Wiederherstellungszugang und geeigneter Sicherung. Vermeide angebliche Patches aus ungeprüften Nachrichten oder Repositories.

Erneuere Prozesse nach Anbietervorgabe und prüfe laufende Version beziehungsweise Paket. Teste wesentliche Funktionen und protokolliere den Zeitpunkt. CMS-Update oder Cacheleeren ersetzen keinen Runtimefix. Bei Einbruchsindikatoren sichere Beweise und aktiviere Incident Response: Patchen macht Angreiferänderungen nicht rückgängig. Dies sind betriebliche Abschlussprüfungen, keine Ferndiagnose. Eine wieder sichtbare Startseite benötigt weiterhin technische Patchbestätigung und funktionale Validierung.

Wenn sofortiges Patchen nicht geht und WikiURL-Grenzen

Laut PHP ist nur das Update eine vollständige Lösung. Vorläufige Maßnahmen reduzieren einzelne Angriffswege, machen die Installation aber nicht sicher. Kopiere keine Speicher- oder Sitzungseinstellungen ohne Verständnis ihrer Auswirkungen. ENISA priorisiert exponierte Systeme und empfiehlt gegebenenfalls Isolation von öffentlichen Netzen. Stimme sicheren Verwaltungszugang und Unterbrechungskommunikation ab. Eine WAF-Regel oder funktionierende Anwendung ersetzt den Patch nicht und garantiert keinen vollständigen Schutz.

WikiURLs Prüfer hilft nach Wartung bei HTTP-Antwort und erkanntem öffentlichen Ziel, nicht bei PHP-Versionsnachweis oder CVE-Freigabe.200 und HTTPS-Schloss sind keine Schwachstellenanalyse. Sende keine Geheimnisse und veröffentliche kein phpinfo als Nachweis. Bewahre Anbieterbestätigung, Prozessprüfung und Funktionstests getrennt auf. Dringend aktualisieren und kontrollieren ist erforderlich, statt unbelegt eine Kompromittierung zu behaupten oder einer lediglich geöffneten Seite zu vertrauen. Dieser Artikel bescheinigt auch WikiURL selbst keinen bestimmten Patchstand.