PHP-Core: zwei RCE-Lücken mit CVSS 9,2 — und warum mod_php zuerst gepatcht wird

Das PHP-Projekt hat am 21. Oktober Sicherheitsversionen veröffentlicht, die zwei Lücken schließen, beide mit CVSS v4.0 auf 9,2 bewertet — Fernausführung von Code ohne Anmeldung. Die Patches gibt es für alle noch unterstützten Zweige: PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Gefährdet ist jede PHP-Installation, die Webanfragen bedient: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Wer nur auf die eigene Anwendung schaut, sieht diese Lücke nicht — sie sitzt tiefer, im Kern selbst.

Was die beiden Lücken technisch tun

CVE-2026-109618 (RCE durch Speicherkorruption bei Speicherengpässen): PHP bricht die Anfragebearbeitung bei erschöpftem Speicher mit longjmp() ab. In bestimmten Phasen ist die Request-Memory dabei nur teilweise initialisiert — das Aufräumen am Request-Ende hält diese ungültigen Daten für gültig und verzweigt darauf. Mehrere Wege führen reproduzierbar in diesen Zustand, etwa Multipart-Anfragen ohne nutzbare deklarierte Länge oder mit einer nicht begrenzten Zahl an Kopfzeilen in einem Teil.

CVE-2026-109619 (RCE durch veralteten globalen Zustand): Interner Anfrage-Zustand überlebt, obwohl der zugrundeliegende Speicher schon freigegeben ist. Die nächste Anfrage, die derselbe Worker bearbeitet, kann diesen veralteten Zustand verwenden, bevor die normale Initialisierung ihn zurücksetzt.

Die PHP-Meldung vom 21. Oktober in Zahlen — Sicherheitsversionen: 8.5.12 · 8.4.27 · 8.3.36 · 8.2.35

Quelle: php.net-Meldung und GitHub-Advisories des PHP-Projekts vom 21.10.2026

Warum mod_php das größte Risiko trägt

Apache mit mod_php ruft die Request-Abschlussroutine bedingungslos auf — selbst wenn der Request-Start fehlgeschlagen ist. Der veröffentlichte Exploit nutzt genau das: Der Angriffscode läuft komplett bevor irgendein Anwendungscode ausgeführt wurde. Firewall, CMS und Anwendungslogik kommen dem Angreifer nicht zuvor. Für PHP-FPM bestätigt die Quellenanalyse die Grundgefährdung, ein vollständiger Exploit ist dafür aber nicht demonstriert — FPM verwirft das Child beim Fehlstart des Requests. FrankenPHP gilt als ähnlich anfällig wie mod_php, php-cgi und LiteSpeed-Setups müssen individuell betrachtet werden.

Kann das Update heute nicht einspielen? Die Ankündigung nennt Übergangsmaßnahmen, die einzelne Angriffswege abschneiden: memory_limit=-1 unüberschreibbar setzen (z. B. als php_admin_value im FPM-Pool) und post_max_size klein halten (8 M ohne Uploads, sonst 32 M). Das reduziert die Angriffsfläche — sicher ist die Installation dadurch nicht. Und: Wer über rpms.remirepo.net aktualisiert, sollte umstellen; das Repo wird für diese Lücken keine Pakete liefern.

Bestand statt Bauchgefühl: Welche Systeme sind wirklich betroffen?

Bei einer Lücke im PHP-Kern zählt eine Frage: Auf welchen Systemen läuft überhaupt PHP im Web-Kontext — und in welcher Version? Die Antwort ist selten vollständig, weil Cron-Prozesse nebenbei laufen, Staging-Umgebungen vergessen werden und Container ihre eigene PHP-Version mitbringen. PHP 8.1 und älter erhalten keine regulären Updates mehr; für 7.4, 8.0 und 8.1 gibt es minimale Quellcode-Backports, die aber nur beim Selbstbau aus dem Quellcode helfen. Verteilungen und LTS-Anbieter hatten die Patches vorab — dort lohnt der Blick in die eigenen Paketquellen.

In vier Schritten zum geschlossenen Befund

1. Bestand klären: Ehrliche Liste aller Systeme mit PHP im Web-Kontext: Produktion, Staging, Container, Cron-Wrapper.
2. Aktualisieren: Auf die Fix-Version des eigenen Zweigs wechseln; bei Älter-als-8.2: Upgrade planen oder Vendor-Backport prüfen.
3. Neu starten: PHP-Prozesse (FPM, Apache) neu starten — ohne Neustart läuft der alte Stand weiter.
4. Belegen: Versionsstand nach dem Neustart prüfen und dokumentieren, für Audit und Wiederholung.

Wie PRAEMON bei solchen Meldungen hilft

Eine Meldung wie diese ist erst nützlich, wenn sie den eigenen Bestand kennt. PRAEMON erfasst, auf welchen Web-Systemen welche PHP-Version läuft, und ordnet Meldungen den betroffenen Servern und Geräten zu — kritische Befunde mit aktivem Angriffsweg stehen oben. Nach dem Update zeigt das Portal, dass die neue Version tatsächlich aktiv ist, und dokumentiert es als Beleg. Falls der Verdacht im Raum steht, dass bereits jemand im Webroot war, hilft der Blick ins Originalpaket: Eingeschleuste PHP-Dateien erkennen. Wie das Update selbst sauber über die Bühne geht, steht im Beitrag Updates im Wartungsfenster.