CVE-2026-109619 wird in PHPs eigenem Advisory als Remote Code Execution durch veralteten Worker-Zustand beschrieben, und ich lese diese Formulierung immer wieder, weil sie unsere Deployment-Gewohnheiten genauso gut beschreibt wie einen Bug. Am 21. Oktober hat das PHP-Projekt 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht und damit diese Lücke behoben, dazu CVE-2026-109618, einen Pfad zur Speicherkorruption bei Out-of-Memory. Beide haben einen CVSS-v4.0-Score von 9.2, und beide sind ohne Authentifizierung erreichbar. Meine Position ist einfach: Die Versionsliste ist diese Woche der leichte Teil. Was die meisten Teams nicht hinbekommen, und das sollte ihnen peinlich genug sein, um es endlich zu lernen, ist der Nachweis, welcher PHP-Build in genau diesem Moment jede Anfrage auf jedem Host bedient.

Schau dir an, wie der Fix tatsächlich in die Produktion kommt. Deine Distribution backportet ihn vielleicht in ein Paket, das weiterhin 8.5.4 oder 8.3.irgendwas heißt, der Versionsstring verrät dir also herzlich wenig. Dein Container-Image ist in der Registry womöglich gepatcht, während drei Replicas aus dem August fröhlich weiter Traffic ausliefern. Dein PHP-FPM-Master wurde vielleicht um 03:12 auf der Platte aktualisiert, während seine Child-Prozesse den alten Code im Speicher halten, bis jemand den Dienst neu startet. Und das CLI-Binary, das du per SSH mit php -v prüfst, kann ein ganz anderer Build sein als der, den Apache oder FPM für die Website nutzt. Wordfence weist ausdrücklich auf diesen letzten Punkt hin und schickt WordPress-Betreiber zu Tools > Site Health > Info > Server statt in die Shell, und ehrlich gesagt könnte jede Framework-Bude eine vergleichbare Seite gut gebrauchen.

Die Laborergebnisse des Wordfence Threat Intelligence Teams lohnen einen genauen Blick, denn sie sprechen in beide Richtungen. In einem speziell konfigurierten Apache-Labor mit PHP 8.5.11 lief ihr Proof of Concept für CVE-2026-109619 über ganz normales HTTP und schrieb eine temporäre Textdatei, und das ist nach jeder Definition Codeausführung. Gegen einen gewöhnlichen, optimierten 8.5.11-Build brachte dieselbe Anfrage PHP nur zum Absturz. Bei CVE-2026-109618 sahen sie, wie 8.5.11 umkippte, wo 8.5.12 normal antwortete, und auf einem WordPress-7.1.3-Stack mit einem betroffenen Ubuntu-Paket 8.5.4 bekamen sie in manchen Setups Fehler und Neustarts, ohne selbst bis zur Codeausführung zu kommen.

Hier das stärkste Argument für Gelassenheit, und ich will ihm sein volles Gewicht geben. Wenn der öffentliche Exploit einen im Labor getunten Build braucht, um mehr zu tun, als einen Worker abstürzen zu lassen, dann ist das realistische Ergebnis für eine typische Produktionsmaschine heute ein Denial of Service, und vieles von dem Proof-of-Concept-Code, der gerade kursiert, ist nach Wordfences eigener Aussage unvollständig oder schlicht falsch. Panisches Patchen an einem Freitag hat seine eigenen Tücken, und wer schon mal mit einem überhasteten Neustart einen Checkout-Flow zerlegt hat, weiß, dass dieser Preis real ist.

Ich kaufe das trotzdem nicht. CrowdStrike sagt, sein unveröffentlichter Exploit habe zuverlässig auf Intel/AMD und Arm funktioniert, auch gegen frisch neu gestartete Worker, und PHP selbst hat Codeausführung für beide Bugs bestätigt, wobei ein Pfad von 109618 auslöst, bevor WordPress überhaupt bootet. Dieses letzte Detail betrifft alle, mit oder ohne Framework: Keine Application Firewall, keine Middleware, kein cleverer Request-Validator in deinem Laravel- oder Symfony-Kernel sieht eine Anfrage, die hochgeht, bevor dein Code überhaupt läuft. Exploits, die diese Woche nur Dinge abstürzen lassen, sind eine vernünftige Prognose dafür, was sie nächste Woche können, und ein FPM-Pool, der unter Beschuss abstürzt, ist bereits ein Ausfall, den du irgendwem erklären musst.

Was ich mir von diesem Vorfall wünsche, ist also eine Gewohnheit. Behandle „welches PHP läuft hier, seit wann, aus welcher Paketrevision“ als beobachtbare Tatsache, die du abfragen kannst, genauso wie du abfragen kannst, welcher Commit deployt ist. Stell die Info auf einem Health-Endpoint hinter Authentifizierung bereit, logge sie beim Worker-Start, pack den Image-Digest in deine Metrik-Labels. Die Go-Leute dürfen gern damit angeben, dass ein statisches Binary das trivial macht, und gut, in diesem einen Punkt haben sie recht, aber wir haben opcache_get_status, php_uname, PHP_VERSION und den Paketmanager, und das zusammenzukleben kostet einen Nachmittag. Erledige das vor dem nächsten Advisory, geh danach die Staging-Sites und Origin-IPs durch, die Wordfence zu Recht anspricht, und bewahre deine Web-, PHP- und Firewall-Logs ab 48 Stunden vor dem Release auf, falls du zu spät dran warst.

Noch eine unbequeme Anmerkung für alle, die noch auf 8.1 oder älter sitzen: Das PHP-Projekt liefert für diese Branches keine Releases mehr, deine Sicherheit hängt also komplett davon ab, dass dein Anbieter dir schriftlich bestätigt, beide Fixes übernommen zu haben. Wenn du diesen Satz nicht von ihm bekommst, ist das deine Antwort, und das Upgrade, das du schon ewig vor dir herschiebst, hat gerade eine Deadline bekommen.

Mich interessiert, wie dein Team das in der Praxis handhabt. Wenn ein Security-Release erscheint, wie stellst du konkret sicher, dass jeder laufende PHP-Prozess, über FPM-Pools, Queue-Worker, Cron-Container und diese eine Legacy-VM hinweg, auf dem gefixten Code läuft, und wie lange hat das diesmal gedauert?