PHP2Shell: Was Betreiber von PHP-Anwendungen jetzt tun müssen

Zwei kritische Sicherheitslücken in PHP können Angreifern ermöglichen, ohne Anmeldung Schadcode auszuführen. Prüfen Sie deshalb den Patchstatus der tatsächlich verwendeten PHP-Laufzeit und lassen Sie erforderliche Updates umgehend einspielen. Ein Update der Anwendung oder ihrer Composer-Abhängigkeiten allein reicht nicht.

Informationsstand: 21. Oktober 2026. Versionsangaben und Herstellerhinweise beziehen sich auf diesen Prüfstand.

Was ist PHP2Shell?

PHP2Shell bezeichnet CVE-2026-109618 und CVE-2026-109619. PHP ist die serverseitige Programmiersprache und Laufzeit vieler Webanwendungen. Die Lücken betreffen diese Laufzeit, nicht nur ein bestimmtes Framework. Das PHP-Projekt veröffentlichte am 21. Oktober 2026 Sicherheitsreleases; seine Vorankündigung bewertete beide Lücken mit 9,2 nach dem Common Vulnerability Scoring System (CVSS v4.0). Das beschreibt die Schwere, nicht den Nachweis eines Angriffs auf Ihre Website.

Welche Anwendungen und Laufzeitumgebungen müssen geprüft werden?

Erfassen Sie alle PHP-Webanwendungen: individuelle Unternehmenssoftware, HTTP-APIs, Kundenportale, Shops sowie Symfony-, Laravel- und CMS-Projekte. Entscheidend ist die Laufzeit hinter der Anwendung. Das PHP-Projekt nennt ausdrücklich PHP-FPM, Apache mod_php, php-cgi, FrankenPHP und LiteSpeed. Kein Hostingmodell ist damit pauschal ausgenommen; eine identische Ausnutzbarkeit folgt daraus nicht.

Inventarisieren Sie pro Domain das Ausführungsmodell, den PHP-Zweig, Paket beziehungsweise Image und zuständigen Betreiber. Berücksichtigen Sie parallele PHP-Versionen, mehrere FPM-Pools, Hosts und lang laufende PHP-Webworker. Auch Staging, interne Anwendungen und selten genutzte Adminoberflächen gehören dazu; priorisieren Sie nach tatsächlicher Erreichbarkeit.

Bei einem Symfony- oder Laravel-Deployment aktualisiert Composer die Anwendungsabhängigkeiten. Der PHP-Interpreter stammt dagegen beispielsweise aus einem Systempaket oder Containerimage. Ein neues Release mit aktualisiertem vendor/-Verzeichnis kann deshalb weiterhin auf einer ungepatchten Laufzeit arbeiten. Diese Trennung gehört auch bei individuellen Backends und Schnittstellen zur Wartung.

Reine CLI-Jobs, Cronjobs und Queue-Worker sind von HTTP-Diensten zu unterscheiden. Aus den HTTP-Advisories lässt sich für sie keine identische entfernte Angreifbarkeit ableiten. Anmeldung, Web Application Firewall (WAF) und Reverse Proxy sind ebenfalls kein allgemeiner Ersatz für einen Herstellerpatch.

Wer muss PHP aktualisieren?

Ein Anbietername genügt nicht: Dasselbe Unternehmen kann betreutes Hosting und selbst verwaltete Server anbieten. Fragen Sie konkret: „Sind beide CVEs für die tatsächlich verwendete PHP-Umgebung meiner Domain behoben? Bitte bestätigen Sie Paket- oder Image-Stand und den wirksamen Rollout.“ Klare Verantwortlichkeiten sind Bestandteil eines nachvollziehbaren Betriebs- und Deploymentprozesses.

Welche PHP-Versionen enthalten die Korrekturen?

Die folgenden ersten korrigierten Upstream-Releases nennt das PHP-Projekt zum 21. Oktober 2026. Verwenden Sie bei späteren Updates den dann gepflegten, korrigierten Stand Ihres Zweigs.

Distributionspakete separat beurteilen: Linux-Anbieter können Korrekturen in ältere Basisversionen zurückportieren. Ubuntu nennt für 24.04 LTS das korrigierte Paket 8.3.6-0ubuntu0.24.04.13. Die kleinere Basisnummer beweist daher keine Verwundbarkeit; maßgeblich sind vollständige Paketversion, Distribution und Hersteller-Advisory.

PHP 8.1 und ältere Zweige haben keinen regulären Upstream-Support mehr. Das PHP-Team stellt hier dennoch minimale Quellcode-Backports für 7.4, 8.0 und 8.1 bereit. Das ist weder eine Wiederaufnahme des Supports noch der Nachweis eines fertigen Anbieterpakets. Prüfen Sie die konkrete Distribution beziehungsweise den LTS-Anbieter und planen Sie den Wechsel auf einen unterstützten Zweig.

Wie prüfe ich, ob das Update wirklich angekommen ist?

php -v zeigt zunächst die CLI-Installation. Der Webserver kann einen anderen Interpreter oder FPM-Pool verwenden. Eine belastbare Prüfung beantwortet vier Fragen:

1. Welche PHP-Umgebung verarbeitet diese Domain tatsächlich?
2. Welches vollständige Paket oder Image liefert diese Laufzeit?
3. Bestätigt der Hersteller die Korrektur beider CVEs?
4. Verwenden sämtliche laufenden Worker bereits diesen Stand?

Nutzen Sie vorhandene administrative Oberflächen oder geschützte lokale Diagnose, keine öffentlich erreichbare phpinfo()-Datei. Stellen Sie einen Prozessneustart beziehungsweise kontrollierten Ersatz gemäß Plattform sicher. Wiederholen Sie den Nachweis für jeden Pool und Host; ein aktualisierter Knoten genügt nicht für einen ganzen Cluster.

Für Container: vom korrigierten Image zum laufenden Replikat

1. Korrigierte Basis beziehungsweise Pakete anhand des Herstellers feststellen.
2. Image neu bauen oder ein nachweislich korrigiertes Image beziehen.
3. Den unveränderlichen Image-Digest als Rollout-Nachweis dokumentieren.
4. Sämtliche Replikate durch diesen Stand ersetzen.
5. Laufende Images, PHP-Laufzeit und Funktion kontrollieren.

Ein geänderter Tag oder der Neustart eines alten Containers ist kein Patchnachweis. Danach folgen Healthchecks, API-Aufrufe, Anmeldung, Formulare und geschäftskritische Abläufe. Ein Wiederherstellungsplan darf die verwundbare Laufzeit nicht ungeschützt wieder öffentlich erreichbar machen.

Was steckt technisch hinter den beiden Lücken?

CVE-2026-109618 betrifft Speicherknappheit (Out of Memory, OOM): Ein abgebrochener Ablauf hinterlässt unvollständig initialisierten Request-Zustand, den PHP beim Aufräumen fehlerhaft verarbeitet. Für Apache mod_php bestätigt das Advisory Schadcodeausführung über HTTP bereits vor Anwendungscode. Remote Code Execution (RCE) bedeutet hier Codeausführung mit den Rechten des Web-Workers, nicht automatisch als root.

Bei FPM beendet ein fehlgeschlagener Request-Start den Kindprozess. Das verhindert diesen speziellen Ablauf, ist aber keine Entwarnung: Das Advisory beschreibt weiterhin mögliche fehlerhafte OOM-Pfade nach normalem Start, ohne einen vollständigen FPM-Exploit als nachgewiesen auszugeben.

CVE-2026-109619 betrifft verbliebenen Worker-Zustand: Verweise überleben den Speicher ihres Requests. Ein späterer Request desselben Workers kann auf freigegebenen Speicher zugreifen – ein Use-after-free. Unter passenden Bedingungen ermöglicht das ebenfalls RCE. Das Advisory bestätigt für den Session-Lebenszyklus RCE bei mod_php und FPM; der FPM-Pfad setzt eine geeignete Anwendungsoperation voraus. Anwendungspfad und Konfiguration beeinflussen die konkrete Ausnutzbarkeit.

Was tun, wenn ein Update nicht sofort möglich ist?

Die Herstellerhinweise zu Übergangsmaßnahmen begrenzen einzelne Angriffspfade, ersetzen das Update aber nicht. Lassen Sie Änderungen an Speicherlimits und Request-Verarbeitung durch die Administration bewerten; falsche Einstellungen können Ausfälle verursachen. Ist das Risiko bis zum Patch nicht vertretbar, Zugriff wirksam begrenzen oder den Dienst vorübergehend aus dem öffentlichen Betrieb nehmen.

Auch der BSI-Sicherheitshinweis, Version 1.1 vom 21. Oktober 2026 (PDF) betont, dass Workarounds keinen vollständigen Schutz bieten. Eine vorhandene Anwendungsauthentifizierung schützt nicht vor Verarbeitungsschritten, die bereits vor dem Anwendungscode stattfinden.

Häufige Fragen zu PHP2Shell

Reicht ein Update von Symfony, Laravel oder Composer-Abhängigkeiten?

Nein. Diese Updates betreffen Anwendungscode und Bibliotheken. Die PHP-Laufzeit muss separat korrigiert und der neue Stand im Webbetrieb aktiviert werden. Ein gemeinsames Deployment kann beides erledigen, muss aber beide Ebenen nachweisen.

Wer aktualisiert PHP bei Webhosting, VPS und Containerbetrieb?

Beim Webhosting normalerweise der Anbieter, beim selbst verwalteten VPS die Administration und bei Containern das für Images und Deployment zuständige Team. Bei Managed-Angeboten entscheidet der vereinbarte Leistungsumfang. Als Betreiber sollten Sie die Bestätigung für Ihre konkrete Umgebung einholen.

Beweist eine ältere PHP-Versionsnummer, dass ich betroffen bin?

Nein. Gepflegte Distributionspakete können Sicherheitskorrekturen trotz älterer Basisnummer enthalten. Vergleichen Sie die vollständige Paketversion mit dem Advisory des zuständigen Anbieters. Die Upstream-Tabelle allein bewertet solche Backports nicht zuverlässig.

Ist eine Website ohne Uploadformular automatisch sicher?

Nein. Ein sichtbares Formular ist keine Voraussetzung dafür, dass ein Server entsprechende HTTP-Anfragen empfängt. Das OOM-Advisory beschreibt automatische Request-Verarbeitung und anwendungsspezifische Speicherpfade. Entscheidend sind die tatsächlich erreichbare Verarbeitung und Konfiguration, nicht die sichtbare Oberfläche.

Reicht php -v als Nachweis?

Nein. Die Ausgabe identifiziert die aufgerufene CLI-Version, nicht zwingend die Laufzeit Ihrer Website. Ergänzen Sie die Zuordnung von Domain, Pool oder Container, den Hersteller-Patchstand und den Nachweis, dass alle aktiven Worker diesen verwenden.

Bin ich nach dem Update automatisch frei von Schadsoftware?

Nein. Ein Patch schließt die Schwachstelle, beseitigt aber keine bereits erfolgte Kompromittierung. Bei Verdachtsmomenten sind zusätzlich eine Untersuchung, die Sicherung relevanter Protokolle und die Prüfung betroffener Zugangsdaten erforderlich.

Meine Empfehlung für den laufenden Betrieb

Dokumentieren Sie für jede produktive PHP-Anwendung Laufzeit, Deploymentmodell, technischen Ansprechpartner und Wartungszuständigkeit. Halten Sie fest, wann und wie der korrigierte Stand im Betrieb nachgewiesen wurde. Das macht aus einer Update-Meldung einen überprüfbaren Betriebszustand.

Wenn Sie Ihre PHP-Umgebung einordnen oder die nächsten Schritte mit Ihrem Hostinganbieter abstimmen möchten, sprechen Sie mich an.

Quellen und Prüfstand

Primärquellen geprüft am 21. Oktober 2026. Dieser Beitrag ordnet den damaligen Stand ein; spätere Herstellerhinweise können ihn ergänzen.

• PHP: Sicherheitsankündigung und Releases vom 20./21. Oktober 2026
• PHP-Advisory zu CVE-2026-109618
• PHP-Advisory zu CVE-2026-109619
• Ubuntu: USN-8948-1 vom 21. Oktober 2026
• BSI: PHP-Sicherheitshinweis, Version 1.1 vom 21. Oktober 2026 (PDF)