PHP-Sicherheitslücke Oktober 2026: CVE-2026-109618 und CVE-2026-109619 patchen

Am 21. Oktober 2026 hat das PHP-Team um 14:00 UTC ein außerplanmäßiges Sicherheitsupdate veröffentlicht. Es behebt zwei Lücken im Kern der Sprache. Beide sind mit CVSS v4.0 9,2 bewertet und erlauben unauthentifizierte Remotecodeausführung. Ein Angreifer braucht kein Konto, und in Ihrer Anwendung muss nichts falsch konfiguriert sein.

Die Existenz der Lücken war am Vortag durchgesickert, deshalb lag der Termin früher als geplant. CISA hat am selben Tag eine Warnung veröffentlicht und nennt die Lücken “php2shell”. Arbeiten Sie mit dem offiziellen Advisory von php.net; die Zusammenfassungen seit dem 20. Oktober mischen bestätigte Angaben mit Spekulation.

Zwei Fehler im Request-Zustand

CVE-2026-109618 greift, wenn PHP der Speicher ausgeht. Die Behandlung kann einsetzen, während interne Request-Daten erst teilweise initialisiert sind. Die Aufräumroutine behandelt diese unvollständigen Daten danach als gültig und nutzt sie als Schreibziel.

CVE-2026-109619 betrifft den Zustand zwischen zwei Anfragen. Ein Request hinterlässt internen Zustand, der auf Speicher zeigt, den PHP danach freigibt. Bearbeitet derselbe Worker die nächste Anfrage, kann er diesen veralteten Zustand nutzen, bevor die Initialisierung ihn zurücksetzt.

Beide Fehler sitzen unterhalb der Anwendung. Die Software darüber spielt keine Rolle, und sauberer Anwendungscode hilft nicht.

Wer betroffen ist

Betroffen ist jede Installation, die Webanfragen bedient: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Bei mod_php ist das Risiko am höchsten, weil ein unauthentifizierter Request den Angriff auslösen kann, bevor Anwendungscode läuft.

PHP 8.1 und älter erhalten vom PHP-Projekt keine Updates mehr. Für 7.4, 8.0 und 8.1 gibt es minimale Backports im Quellcode, gedacht für alle, die selbst bauen oder keinen LTS-Anbieter haben. Distributionen und kommerzielle Anbieter liefern eigene Pakete; prüfen Sie deren Hinweise, bevor Sie selbst kompilieren. Wer Pakete von rpms.remirepo.net bezieht: Dieses Repository hat am Releasetag keine Updates. Das PHP-Team rät, auf Distributionspakete zu wechseln oder selbst zu bauen.

PHP 8.2 erreicht am 31. Dezember 2026 das Ende der Unterstützung. Wer nur auf 8.2.35 patcht, hat zehn Wochen Ruhe und danach dasselbe Problem. Der Versionssprung gehört in denselben Arbeitsschritt.

PHP läuft außerdem selten nur dort, wo “PHP” draufsteht. CISA weist darauf hin, dass die Verbreitung oft nicht direkt sichtbar ist, weil PHP Teil anderer Software ist. Ein Inventar über Container-Images, Hosting-Panels und verwaltete Dienste steht deshalb vor dem Patchen.

Was heute zu tun ist

1. Bestandsaufnahme. Prüfen Sie php -v im laufenden Container, nicht im Paketmanager, dazu FPM-Pools, Apache-Module und die Images Ihrer Deployments.

2. Patchen, internetzugewandte Systeme zuerst: 8.5.12, 8.4.27, 8.3.36 oder 8.2.35. Starten Sie danach Worker und Webserver neu. Ohne Neustart laufen die alten Prozesse samt Opcache weiter.

3. Nachsehen, ob der Fix greift. Die Version im laufenden Prozess muss die neue sein. Ein apt upgrade und ein php -v auf dem Host sagen nichts über den Container, der die Anfragen beantwortet.

4. Wenn ein Update heute nicht möglich ist, nennt das Advisory Mitigationen. Sie schließen einzelne Angriffspfade und ersetzen das Update nicht:

   • memory_limit=-1 über php_admin_value in der FPM-Pool- oder Apache-Konfiguration, danach prüfen, ob eine Pool-, Verzeichnis- oder Anwendungseinstellung wieder ein Limit setzt.
   • post_max_size auf 8 MB ohne Uploads, 32 MB mit Uploads, upload_max_filesize darunter. Zusätzlich Limits am Proxy für Request-Größe, Feldanzahl, Multipart-Teile, Header und Verschachtelungstiefe, auch für Anfragen ohne verwertbaren Content-Length.
   • Ein Container- oder cgroup-Limit als Verfügbarkeitsgrenze, mit einer Policy, die nur den betroffenen Worker beendet. Verwenden Sie dafür nicht RLIMIT_AS oder RLIMIT_DATA; sie können genau den Speicherfehler auslösen, der in die Lücke führt.
   • session.upload_progress.enabled=0, gesetzt in php.ini, im FPM-Pool oder in der Serverkonfiguration, danach alle Worker neu starten. ini_set() und .user.ini greifen zu spät.
   • Auf PHP 8.5 zusätzlich fatal_error_backtraces=0 und neu starten. Das schließt den bestätigten Pfad; andere Varianten bleiben offen.
   • Fatal Errors und Timeouts beheben, die ein Angreifer auslösen kann. Diagnoseausgaben zu verstecken hilft nicht.

5. Beobachten. CISA empfiehlt, auf PHP-Worker zu achten, die Shells starten oder Werkzeuge herunterladen.

Gepatcht wird unterhalb des CMS

Diese Lücke entsteht im Zustand zwischen zwei Requests, dort, wo ein Worker Speicher wiederverwendet. Ein CMS-Update und ein Code-Review erreichen diese Ebene nicht. Wer PHP als Abhängigkeit eines CMS behandelt, aktualisiert das CMS und lässt die Laufzeit stehen.

Sicherheitsfirmen rechnen bei einer Lücke dieser Schwere mit Angriffen innerhalb von Stunden nach der Veröffentlichung. Ein Patch im nächsten Wartungsfenster kommt zu spät.

Dazu kommen feste Termine: PHP 8.1 ist ohne Support, PHP 8.2 endet in zehn Wochen. Jede dieser Zäsuren macht aus einer gepflegten Installation eine ungepatchte, ohne dass jemand etwas falsch gemacht hat.

Was wir übernehmen

Wir übernehmen die kontinuierliche Sicherheitsüberwachung Ihrer Server: Update- und Patch-Management für die Laufzeit, Monitoring der Dienste, die Prüfung, ob Backups tatsächlich zurückspielbar sind, und eine feste Reihenfolge, wenn eine Lücke wie diese veröffentlicht wird. Die Stelle, die Ihre Server ohnehin patcht, informiert Sie.

Wenn Sie wissen wollen, ob Ihre Server betroffen sind und wer sie künftig patcht, schreiben Sie uns die PHP-Version und die Anzahl der Server.