php2shell: Zwei kritische PHP-Lücken zur Codeausführung gestopft, doch jede Laufzeitumgebung zu finden ist schwierig

Zwei Speichersicherheitslücken im Request-Lebenszyklus

Laut Sourcegraph hat PHP die Korrekturen am 21. Oktober 2026 um 14:00 UTC veröffentlicht, zusammen mit einem Sicherheitshinweis und zwei GitHub-Advisories, GHSA-w8hw-w9fx-j79w und GHSA-6wmf-4rv5-p3rp. Forscher bezeichnen das Schwachstellenpaar als php2shell.

Bei beiden Lücken handelt es sich um Speichersicherheitsfehler im Request-Lebenszyklus. Unter mod_php lassen sie sich erreichen, bevor Anwendungscode läuft, und ein präparierter Multipart-POST genügt, um die Angriffskette zu starten. Sourcegraph zieht daraus den Schluss, dass die Sauberkeit einer Anwendung keine Rolle spielt. Entscheidend ist, welche PHP-Binärdatei die Anfrage beantwortet.

PHP 8.1 und älter werden vom PHP-Projekt nicht mehr unterstützt und erhalten daher keine Korrektur. Die Empfehlung von PHP selbst ist knapp: "There are no complete mitigations, updating is the only safe choice." (Es gibt keine vollständigen Gegenmaßnahmen, ein Update ist die einzig sichere Wahl.)

Warum das Finden von PHP schwerer ist als das Patchen

Der verwundbare Code steckt im Interpreter, nicht in einer einzelnen Anwendung. Deshalb zählt jede Stelle, an der ein Interpreter eingebunden wurde, unabhängig davon, ob ein PHP-Entwickler sie je angefasst hat. Sourcegraph nennt typische Fundorte:

• offizielle php:*-Basisimages
• apt-install-php8.x-fpm-Zeilen, die tief in Dockerfiles vergraben sind
• Helm-Charts für Standardanwendungen wie WordPress oder Matomo
• CI-Images, die Composer ausführen
• vergessene interne Admin-Tools

Jede dieser Stellen legt ihre Version an einem anderen Ort fest. Ein Scanner zeigt, was gerade im Einsatz ist, aber nicht, welches Repository es baut, wer dafür zuständig ist oder wo der nächste Build die alte Version wieder hereinholen könnte. Sourcegraph zufolge dauert das Patchen in einfachen Umgebungen vielleicht nur Minuten, in den komplexesten Codebasen mit herkömmlichen Werkzeugen aber Stunden, Tage, Wochen oder sogar Monate.

Betroffen sind Sie, wenn irgendetwas in Ihrer Umgebung HTTP über eine PHP-Version vor 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 ausliefert. Der Beitrag enthält Sourcegraph-Suchanfragen für Dockerfile-Basisimages, Paketinstallationen auf Betriebssystemebene, Kubernetes- und Helm-Manifeste, GitHub-Actions-Workflows und composer.json-Pins. Da reguläre Ausdrücke nur bekannte Zeichenfolgen finden, bringt Sourcegraph sein Tool Deep Search für breitere Fragen in einfachem Englisch ins Spiel, etwa welche Dienste tatsächlich Traffic über mod_php ausliefern. Nach Angaben des Unternehmens führt es die Codesuchen und die Navigation selbst durch und antwortet mit Links zu den verwendeten Dateien.

Empfohlene Maßnahmen

Sourcegraph rät, jeden aus dem Internet erreichbaren Host mit einem verwundbaren Build als möglicherweise kompromittiert zu behandeln. Die vorgeschlagene Reihenfolge:

• Zuerst mod_php mit Internetzugang patchen, da es der bestätigte Pfad vor der Anwendung ist, danach FPM, FrankenPHP und LSAPI.
• Alle Worker neu starten, denn ein neues Paket hilft nicht, wenn ein Worker noch die alte Binärdatei im Speicher hält.
• Alles rotieren, was der Webnutzer lesen kann, darunter Datenbank-Zugangsdaten, API-Schlüssel in .env-Dateien und Cloud-Zugangsdaten, die vom Host oder dessen Metadaten-Endpunkt erreichbar sind.
• Für jeden verwundbaren, exponierten Dienst eine vollständige forensische Analyse durchführen, Logs sichern und einen Snapshot des Hosts anlegen, bevor er neu aufgebaut wird. Spuren eines Zugriffs sind als Sicherheitsvorfall zu behandeln.
• Images neu bauen, statt sie nur erneut auszurollen, dabei gepinnte Tags anheben und frische Basisimages ziehen.
• Hosts mit PHP 8.1 oder älter, die das Supportende erreicht haben, isolieren oder migrieren und bis zum Wechsel auf einen unterstützten Zweig vom öffentlichen Internet nehmen.
• Auf exponierten Hosts nach Spuren suchen, mindestens bis zum 20. Oktober zurück, als die ersten Informationen zu den Lücken durchsickerten.

Für das Massen-Update bewirbt Sourcegraph Agentic Batch Changes. Ein Nutzer beschreibt die Änderung in einfacher Sprache, und das Tool grenzt die betroffenen Repositories mit Deep Search und Code Search ein. Für mechanische Tag-Anhebungen nutzt es ein Skript, wo Urteilsvermögen gefragt ist, Claude Code oder Codex. Es beginnt mit einem Canary, reagiert auf CI-Fehler und macht weiter, bis die Pull Requests mergefähig sind.

Was das für Teams bedeutet

Sourcegraph rechnet damit, dass die meisten Teams die unterstützten Zweige bis zum Ende der Woche abschließen, während sich der lange Schwanz der Hosts am Supportende über Monate ziehen wird. Der größere Punkt: Die nächste CVE in einer Laufzeitumgebung wird anders aussehen, die entscheidende Frage bleibt aber dieselbe: Wo läuft das, und wer ist dafür zuständig? Ein Team, das das aus seinem Code beantworten kann, steht laut Unternehmen vor einem Nachmittag voller Pull Requests, eines, das es nicht kann, vor einer Woche voller Slack-Threads.

Der Beitrag ist zugleich Produktwerbung, die Geschwindigkeitsversprechen für Deep Search und Agentic Batch Changes stammen also vom Anbieter. Der Patch-Rat selbst ist eindeutig: jede PHP-Laufzeit aktualisieren und die Worker neu starten.