Am 21. Oktober 2026 hat das PHP-Projekt Sicherheitsupdates für zwei kritische Lücken veröffentlicht, die Sicherheitsforscher «php2shell» nennen (CVE-2026-109618 und CVE-2026-109619). Beide erlauben es, ohne Anmeldung Schadcode auf einem Server auszuführen. Das Bundesamt für Cybersicherheit (BACS) rät noch am selben Tag, die Updates sofort einzuspielen. Das Update selbst ist schnell gemacht. Schwieriger ist die Frage, wo im Betrieb überall PHP läuft.
Was die Lücken bewirken
Die Lücke CVE-2026-109618 betrifft den Umgang mit vollem Arbeitsspeicher. Bricht PHP mitten in einer Anfrage ab, können halb aufgebaute interne Daten beim Aufräumen als gültig behandelt werden. Die Lücke CVE-2026-109619 betrifft Zustände, die eine Anfrage überleben, obwohl ihr Speicher schon freigegeben ist. Eine spätere Anfrage an denselben Prozess kann sie dann verwenden.
Am grössten ist das Risiko laut PHP-Projekt bei mod_php, also bei PHP als Modul im Apache-Webserver. Dort genügt eine Anfrage ohne Anmeldung, und der Angriff läuft, bevor die eigentliche Anwendung überhaupt startet. Betroffen sind aber auch andere Betriebsarten wie PHP-FPM.
Behoben sind die Lücken in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Die Linux-Distributionen haben die Korrekturen vorab erhalten und können sie in ihre bestehenden Paketversionen eingebaut haben. Massgebend ist deshalb die Sicherheitsmeldung des jeweiligen Anbieters und nicht allein die Versionsnummer. Für PHP 8.1 und älter gibt es vom Projekt keine regulären Updates mehr. Manche Distributionen und Anbieter mit Langzeitunterstützung liefern dafür eigene Korrekturen.
Wo PHP sich versteckt
Den Webserver mit der Firmen-Website hat jede IT-Abteilung auf dem Radar. Das BACS weist aber darauf hin, dass PHP in Systemen stecken kann, von denen der Betreiber es nicht immer weiss.
- Manche Geräte haben eine Verwaltungsoberfläche mit PHP.
- Interne Fachanwendungen hat oft jemand vor Jahren eingerichtet und seither vergessen.
- Hosting-Plattformen und Webdienste betreibt häufig ein Dritter.
- Container und Appliances bringen ihr PHP gleich mit.
Container verdienen besondere Aufmerksamkeit. Ein Container bringt sein eigenes PHP mit. Wenn der Server darunter aktuell ist, bleibt das PHP im Container trotzdem alt, bis der Hersteller ein neues Abbild liefert und es jemand einspielt.
Warum Workarounds nicht genügen
Das PHP-Projekt nennt für beide Lücken Massnahmen, die den Angriff erschweren, etwa das Abschalten von session.upload_progress oder strengere Grenzen für die Grösse von Anfragen. Es sagt aber ausdrücklich, dass keine davon vollständig ist und nur das Update die Lücken schliesst. Die Einstellung zum Upload-Fortschritt wirkt zum Beispiel nur gegen bekannte Wege von CVE-2026-109619 und gehört bei CVE-2026-109618 nicht zu den genannten Massnahmen. Auch eine Web Application Firewall allein genügt laut BACS nicht.
Was jetzt zu tun ist
- Erfasse alle Systeme mit PHP. Dazu gehören auch Geräte, Container und Dienste, die Dritte für Dich betreiben. Halte für jedes System Version, Erreichbarkeit und Verantwortliche fest.
- Spiel die Updates ein und starte die Dienste neu. Laufende PHP-Prozesse arbeiten sonst mit der alten Bibliothek weiter. Container müssen mit dem neuen Abbild neu erstellt werden.
- Lass Dir die Behebung bestätigen, wenn ein Hoster oder ein Hersteller das System betreibt.
- Prüf, ob die laufende Anwendung wirklich die korrigierte Version nutzt. Ein installiertes Paket heisst noch nicht, dass der Prozess es verwendet.
- Schau in die Protokolle. Ungewöhnliche Anfragen, Abstürze, veränderte Dateien oder fremde Prozesse sind Warnzeichen. Ein Update entfernt keinen Angreifer, der schon drin ist.
- Beschränke den Zugriff, wo ein Update noch nicht möglich ist. Ein System, das nur aus einem internen Netz erreichbar ist, ist aus dem Internet nicht direkt angreifbar.
Wir haben nach der Warnung unsere Server und die Container darauf geprüft. Bei Geräten stützen wir uns auf die Angaben der Hersteller. PHP fanden wir dabei auch in einem Container und auf einem Kleinrechner der Gebäudetechnik, an die beim Wort PHP niemand zuerst denkt. Für den Container gibt es noch kein korrigiertes Abbild, deshalb ist er vorerst nur aus einem internen Netz erreichbar und gehärtet. Wenn Du nicht sicher bist, wo PHP in Deinem Betrieb läuft, erreichst Du uns über das Kontaktformular.
Quellen: BACS – Warnung «Kritische Schwachstellen in PHP: Sicherheitsupdates sofort einspielen» vom 21. Oktober 2026; PHP-Projekt – Sicherheitsmeldung vom 21. Oktober 2026 (php.net).
