Sicherheitshinweise.
Am 21. Oktober veröffentlichte das PHP-Projekt eine kritische Sicherheitsmeldung mit einer kurzen Anweisung: jetzt aktualisieren. Zwei Schwachstellen zur Remote-Code-Ausführung, CVE-2026-109618 und CVE-2026-109619, sind beide mit CVSS 9.2 bewertet. Die erste wird ausgelöst, wenn PHP mitten in der Vorbereitung einer Anfrage der Speicher ausgeht und später Daten aufgeräumt werden, die nie vollständig initialisiert wurden. Die zweite lässt internen Zustand einer Anfrage länger leben als ihren Speicher, sodass die nächste Anfrage desselben Workers ihn übernehmen kann. Betroffen ist jedes PHP-Setup, das Webtraffic ausliefert — PHP-FPM, mod_php, php-cgi, FrankenPHP und LiteSpeed —, wobei mod_php das höchste Risiko trägt.
Die korrigierten Versionen sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Die Meldung stellt klar, dass es keinen vollständigen Workaround gibt: Patchen ist die einzige sichere Option.
Was wir getan haben, bevor es den Fix gab. Die Schwachstellen wurden vor dem Release angekündigt, daher haben wir in den Stunden dazwischen das Risiko auf den von uns betreuten Servern gesenkt. Wir haben Session Upload Progress deaktiviert, das in der Meldung als teilweise Abhilfe für die zweite Lücke genannt wird, und zusätzlich den Strict Session Mode erzwungen. Beide Einstellungen haben wir in jede PHP-Laufzeit auf jedem Host und in den Anwendungscontainern übernommen und an den PHP-Workern überprüft, die tatsächlich Anfragen beantworten, statt den Konfigurationsdateien zu vertrauen.
Patchen am selben Tag. Als die Releases erschienen, hinkten die üblichen Distributionspakete und offiziellen Container-Images noch hinterher. Statt zu warten, haben wir die korrigierten Versionen aus den offiziellen, per Prüfsumme verifizierten PHP-Quellen gebaut, die vorhandenen Erweiterungen und Einstellungen jedes Servers beibehalten und OPcache passend neu gebaut. Anwendungen, die noch auf PHP 8.0 oder 8.1 laufen und keine öffentlichen Releases mehr erhalten, bekamen statt eines Notfall-Versionssprungs die offiziellen Security-Backports des PHP-Projekts. Containerbasierte Anwendungen wurden auf das gepatchte 8.4.27-Image umgestellt, mit fixiertem Basis-Image, damit ein künftiger Build nicht unbemerkt auf eine verwundbare Version zurückfällt.
Prüfen statt annehmen. Eine Versionsnummer allein beweist nichts, wenn ein gepatchter und ein ungepatchter Build dieselbe Zeichenkette melden können. Deshalb wurde jeder aktive Web-Pool auf die Engine und den OPcache-Build geprüft, die er tatsächlich ausführt, und anschließend wurden die öffentlichen Shops, Login-Seiten und Demo-Seiten kontrolliert. Alle dreiundzwanzig aktiven PHP-Pools in unseren eigenen und den Umgebungen unserer Kunden haben die Prüfung bestanden.
Was das für Ihren Shop bedeutet. Wenn Sie Magento oder eine andere PHP-Anwendung betreiben und seit dem 21. Oktober nicht aktualisiert haben, behandeln Sie es als dringend. Prüfen Sie die PHP-Version, die Ihre Web-Worker tatsächlich ausführen, nicht nur die auf der Kommandozeile, und planen Sie den Umstieg von PHP 8.0 und 8.1, falls Sie noch darauf angewiesen sind. Security-Backports verschaffen Zeit, sind aber keine Dauerlösung.
Wenn Sie ein zweites Paar Augen auf Ihren Stack wünschen oder möchten, dass wir solche Updates für Sie übernehmen, nehmen Sie Kontakt auf — Shops sicher und am Laufen zu halten ist ein großer Teil unserer täglichen Arbeit.