Kritische PHP-Lücken: Updates auf 8.5.12, 8.4.27, 8.3.36 und 8.2.35 jetzt einspielen

Das PHP-Projekt hat am 21. Oktober 2026 die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht. Sie schließen zwei kritische Sicherheitslücken, über die Angreifer ohne Anmeldung eigenen Code auf dem Server ausführen können. Das PHP-Team fordert in seinem Sicherheitshinweis auf php.net alle Nutzer auf, sofort zu aktualisieren.

Betroffen ist praktisch jeder Server, der Webseiten mit PHP ausliefert. Dazu gehören Shopware-Shops, WordPress-Seiten und die meisten anderen PHP-Anwendungen. Der Stand in diesem Beitrag ist der Nachmittag des 21. Oktober 2026.

Beide Lücken sind mit CVSS 9,2 bewertet

Schon am 20. Oktober hatte das PHP-Team das Update angekündigt. Laut dieser Vorankündigung haben beide Schwachstellen einen Wert von 9,2 nach CVSS 4.0, also kritisch. Veröffentlicht wurden die Versionen dann am 21. Oktober.

Die beiden Fehler im Überblick, wie sie das PHP-Team beschreibt:

• CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): Läuft PHP der Speicher aus, kann die Verarbeitung an einer Stelle abbrechen, an der interne Anfragedaten erst halb eingerichtet sind. Beim Aufräumen behandelt PHP diese ungültigen Daten dann als gültig.
• CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): Interne Zustände einer Anfrage bleiben erhalten, obwohl ihr Speicher schon freigegeben ist. Eine spätere Anfrage an denselben Worker kann diesen veralteten Zustand nutzen.

Im Changelog von PHP 8 laufen beide Korrekturen unter dem Eintrag „Avoid state corruption via bailout“.

Gefährdet sind alle Server, die Webanfragen mit PHP beantworten

Das PHP-Team nennt ausdrücklich PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Am höchsten schätzt es das Risiko bei mod_php ein. Dort gibt es einen funktionierenden Exploit, bei dem eine Anfrage ohne Anmeldung den Angriff auslöst, noch bevor der Code der Anwendung läuft.

Für einen Onlineshop heißt das: Es kommt nicht darauf an, wie sicher Shopware selbst oder Ihre Plugins programmiert sind. Die Lücke sitzt eine Ebene darunter.

heise online hält die Lage für ernst. Die Redaktion rechnet mit funktionierenden Exploits innerhalb von Stunden, spätestens nach einem Tag. Laut heise warnt auch CERT-EU seine Abonnenten mit dem Advisory 2026-018.

Das Update ist der einzige vollständige Schutz

Aktualisieren Sie auf die passende Version Ihrer PHP-Reihe:

| Ihre PHP-Reihe | Abgesicherte Version | |---|---| | PHP 8.5 | 8.5.12 | | PHP 8.4 | 8.4.27 | | PHP 8.3 | 8.3.36 | | PHP 8.2 | 8.2.35 |

Nach dem Update müssen alle PHP-Prozesse neu starten, bei PHP-FPM also der FPM-Dienst, bei mod_php der Apache. Erst dann läuft der korrigierte Code.

Die meisten Server bekommen PHP nicht von php.net, sondern über die Pakete ihrer Linux-Distribution. Laut PHP-Team haben die Distributionen und LTS-Anbieter die Patches vorab erhalten. Ob die Pakete schon bereitstehen, unterscheidet sich je nach Anbieter. Bei Ubuntu steht die Lücke am Nachmittag des 21. Oktober mit Priorität „Critical“ für die PHP-Pakete noch auf „Needs evaluation“.

Ein Hinweis betrifft Server, die PHP aus dem ehrenamtlich gepflegten Paketarchiv rpms.remirepo.net beziehen. Laut PHP-Team gibt es dort heute keine Updates. Das PHP-Team rät, auf Pakete der Distribution umzusteigen oder selbst zu kompilieren.

PHP 8.1 und älter bekommen nur noch Notfall-Patches

Für PHP 8.1 und ältere Versionen liefert das PHP-Projekt keine regulären Updates mehr. Wegen der Schwere der Lücken hat das Team aber minimale Quell-Patches für PHP 7.4, 8.0 und 8.1 bereitgestellt. Die richten sich an alle, die PHP selbst kompilieren oder keinen LTS-Anbieter haben. Einige Distributionen spielen laut PHP-Team eigene Korrekturen ein, fragen Sie dort nach.

Wer noch auf PHP 8.1 oder älter läuft, sollte den Vorfall zum Anlass nehmen, auf eine unterstützte Version zu wechseln. PHP 8.2 bekommt übrigens nur noch bis zum 31. Dezember 2026 Sicherheitsupdates. Was dabei zu beachten ist, steht in unserem Beitrag zum Ende von PHP 8.2.

Übergangslösungen verringern das Risiko nur

Wer nicht sofort aktualisieren kann, findet im Sicherheitshinweis einige Einstellungen. Das PHP-Team betont, dass sie einzelne Angriffswege erschweren, eine Installation aber nicht sicher machen.

Gegen CVE-2026-109619 hilft laut PHP-Team session.upload_progress.enabled=0, gesetzt in der php.ini oder im FPM-Pool, gefolgt von einem Neustart aller Worker. Ein ini_set() im Code oder eine .user.ini reichen nicht. Diese Einstellung blockiert die bestätigten Angriffswege über Sessions, andere Varianten aber nicht. heise hält sie nach eigenem Kenntnisstand für wirkungslos. Unter PHP 8.5 kommt fatal_error_backtraces=0 hinzu.

Gegen CVE-2026-109618 nennt das PHP-Team unter anderem:

• memory_limit=-1, so gesetzt, dass Anwendungen den Wert nicht überschreiben können, etwa per php_admin_value
• ein niedriges post_max_size, 8 MB ohne Datei-Uploads und 32 MB mit Uploads
• Grenzen für Größe und Umfang von Anfragen direkt am Webserver oder Proxy
• ein Speicherlimit über Container oder cgroups, das nur den betroffenen Worker beendet

Das PHP-Team rät ausdrücklich davon ab, statt eines solchen Limits RLIMIT_AS oder RLIMIT_DATA zu setzen, weil gerade das den anfälligen Fehler auslösen kann. Alle diese Einstellungen sind nur eine Brücke bis zum Update. heise nennt als einzige Alternative für alle, die das Risiko nicht tragen wollen, PHP-Webserver bis zum Update vom Netz zu nehmen.

Updates wie dieses übernehmen wir für Sie

Lücken wie diese zeigen, warum jemand die Sicherheitsmeldungen von PHP und den Distributionen im Blick haben muss. Bei unseren Managed Servern gehören Sicherheitsupdates dazu, für Shopware-Shops übernehmen wir das im Rahmen des Shopware-Managements.

Wenn Sie nicht sicher sind, welche PHP-Version auf Ihrem Server läuft oder ob das Update schon eingespielt ist, schreiben Sie uns.