PHP-Sicherheitsupdates schließen zwei kritische RCE-Schwachstellen
Die am 21. Oktober 2026 behobene PHP-Schwachstelle besteht aus zwei kritischen Fehlern, durch die ein nicht authentifizierter Angreifer, also jemand, der nicht angemeldet ist, aus der Ferne Code auf einem Webserver ausführen kann. PHP veröffentlichte die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35, um beide Probleme zu beheben. Websites, die WordPress, Drupal, Magento, Joomla, Laravel oder eine andere PHP-Anwendung verwenden, sind gefährdet, solange die zugrunde liegende PHP-Installation verwundbar bleibt.
Das Risiko betrifft die wichtigsten Methoden, mit denen PHP Webanfragen verarbeitet, darunter PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. PHP betrachtet mod_php als die Konfiguration mit dem höchsten Risiko, da eine schädliche Anfrage die Schwachstelle erreichen kann, bevor der anwendungseigene Code der Website ausgeführt wird. Das Problem liegt im PHP-Interpreter, also der Software, die PHP-Code ausführt, und nicht in einem bestimmten Content-Management-System oder Plugin.
Bei den Schwachstellen handelt es sich um CVE-2026-109618 und CVE-2026-109619. Beide sind gemäß CVSS v4.0, einem Standardsystem zur Beschreibung des Schweregrads von Schwachstellen, mit Critical und 9.2 bewertet. CVE-2026-109618 betrifft das Out-of-Memory-Handling. PHP kann unterbrochen werden, während seine internen Anfrageinformationen erst teilweise vorbereitet sind. Bei der anschließenden Bereinigung können ungültige Informationen irrtümlich als legitim behandelt werden. CVE-2026-109619 ermöglicht es, dass anfragespezifische interne Informationen bestehen bleiben, nachdem der dafür genutzte Speicher freigegeben wurde. Eine spätere Anfrage, die von demselben worker, also dem PHP-Prozess zur Verarbeitung von Anfragen, bearbeitet wird, kann diese veralteten Informationen verwenden, bevor sie durch die normale Initialisierung gelöscht werden.
Wiz Research, das die Schwachstellen an PHP meldete, erklärt, dass jede PHP-Version bis zurück zu 5.4 von mindestens einem der Fehler betroffen ist. Die Forscher demonstrierten remote code execution bei den neuesten WordPress-, Drupal- und Joomla-container-Images sowie die Ausnutzung einer einfachen Hello-World-Anwendung. Ein container ist ein isoliertes Paket, das eine Anwendung und die dafür erforderliche Software enthält. Die Forscher demonstrierten außerdem das Auslesen des Speichers von PHP-workern, ohne zuvor eine Codeausführung zu erreichen. Dieser Speicher kann Passwörter, API-Schlüssel und Zugriffstoken enthalten. Wiz zufolge behebt der Patch von PHP das zugrunde liegende Problem einschließlich zusätzlicher Varianten.
Details wurden am 20. Oktober vor der geplanten koordinierten Offenlegung bekannt, woraufhin das Problem unter dem Namen PHP2Shell bekannt wurde. Das Sicherheitsunternehmen watchTowr bestätigte bereits vor der Veröffentlichung, dass die Schwachstellen echt waren. Am 21. Oktober um 07:34 UTC meldeten mehrere Hostingpartner Patchstack aktive Ausnutzungsfälle. Cloudflare berichtete um 07:43 UTC von frühen Angriffen und führte erste Web Application Firewall-Regeln ein, die Webanfragen prüfen und filtern, um bekannte Exploit-Wege zu blockieren. Um 13:52 UTC veröffentlichte PHP die korrigierten Versionen. Fünf Minuten später erklärte Patchstack, seine eigenen Telemetriedaten zeigten zu diesem Zeitpunkt Sondierungsversuche, aber keine belastbaren Belege für erfolgreiche Sicherheitsverletzungen. Das Unternehmen warnte jedoch, dass sich dies ändern könne, sobald Einzelheiten zu den Patches öffentlich würden.
Mehrere Dienste wurden vorsorglich offline genommen, bevor die Korrekturen verfügbar waren. Der niederländische Sender NOS berichtete von Ausfällen bei DigiD, MijnOverheid, der Website der niederländischen Zweiten Kammer, Tweakers und der Website des niederländischen National Cyber Security Centre. ITmedia meldete Notfallwartungen bei japanischen Diensten wie Kodmon, Shadowverse: Worlds Beyond und Sakura Rental Server, die vermutlich mit der Schwachstelle zusammenhingen. BASE und Xserver sollten voraussichtlich folgen. Die Entwickler von The SEO Framework erklärten ebenfalls, dass sie ihre Server offline genommen hätten. CERT-EU veröffentlichte eine Sicherheitsempfehlung, während das UK National Cyber Security Centre zu sofortigen Updates aufrief.
Cloudflare erklärt, dass seine anfänglichen firewall-Regeln allen Kunden einschließlich kostenloser Nutzer zur Verfügung stehen, bezeichnet sie jedoch nur als vorübergehende Barriere. Sie helfen ausschließlich dann, wenn der origin server Datenverkehr nur über Cloudflare akzeptiert. Sie ersetzen das PHP-Sicherheitsupdate nicht, da möglicherweise andere Wege zum Server oder bislang unbekannte Angriffsvarianten offenbleiben.
Administratoren sollten PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 installieren oder das entsprechende korrigierte Paket von ihrem Betriebssystemanbieter beziehen. Linux-Distributionen und Long-Term-Support-Anbieter erhielten die Patches vorab. PHP warnte, dass die von Freiwilligen gepflegten Pakete auf rpms.remirepo.net an diesem Tag nicht aktualisiert würden, und empfahl stattdessen Pakete der jeweiligen Distribution oder einen Source-Build. PHP 8.1 und ältere Versionen erhalten vom PHP-Projekt keine Korrekturen mehr. Mehrere externe Maintainer haben die Korrektur jedoch backported, das heißt, sie haben sie für ältere Versionen angepasst.
Die Verfügbarkeit der Pakete war am 22. Oktober unterschiedlich. Pakete von packages.sury.org und ppa:ondrej/php deckten End-of-Life-Branches von PHP 5.6 bis 8.1 ab. Ubuntu 22.04 korrigierte sein PHP-8.1-Paket mit php8.1 8.1.2-1ubuntu2.28. Ubuntu Pro deckte Versionen von 14.04 bis 20.04 ab, wobei für 14.04 und 16.04 das Legacy-Add-on erforderlich war. Freexian ELTS deckte PHP 7.0 unter Debian 9, PHP 7.3 unter Debian 10 und PHP 7.4 unter Debian 11 ab. Der eigene Support von Debian für Debian 11 endete am 31. August 2026, das php7.4-Paket von Sury bot jedoch eine kostenlose Möglichkeit zur Absicherung.
AlmaLinux veröffentlichte Korrekturen für PHP-streams auf den Versionen 8, 9 und 10, einschließlich End-of-Life-streams, garantierte jedoch keine zukünftigen Korrekturen. Red Hat stellte Korrekturen für php:7.4 unter RHEL 8 und PHP 8.0 unter RHEL 9 bereit, jedoch nicht für eingestellte streams wie 7.2 und 8.1 unter RHEL 9. Remi deckte 7.4, 8.0 und 8.1 unter RHEL 8 und 9 ab, nicht aber 7.2 oder 7.3. CloudLinux veröffentlichte korrigierte EasyApache-4-ea-php-Pakete von ea-php52 bis ea-php85 für cPanel. TuxCare ELS führte Branch-spezifische Korrekturen ein, während Zend erklärte, dass seine Long-Term-Support-Builds von PHP 7.2, 7.3, 7.4 und 8.1 bereits bei der Veröffentlichung korrigiert waren. Offizielle PHP-Docker-Images erhielten für PHP 8.1 oder ältere Versionen keine Korrektur.
PHP veröffentlichte als letzte Möglichkeit außerdem Source-Backports für 7.4, 8.0 und 8.1. Dabei handelt es sich um begrenzte Schutzmaßnahmen und nicht um einen erneuerten Support: Sie deaktivieren den Session-Upload-Fortschritt unabhängig von php.ini und fügen kein festes Speicherlimit hinzu. Bei Ubuntu und älteren Sury-Builds, die die Upstream-Versionsnummern beibehalten, sollten Administratoren die Paket-Changelogs auf beide CVEs prüfen. Debian und neuere Sury-Pakete führen möglicherweise nur eine neue Upstream-Version auf, während in den Changelogs der RHEL-8.2- und RHEL-8.3-streams möglicherweise lediglich rebase steht. PHP empfiehlt dort die Verwendung von dnf updateinfo. Falls keine Korrektur eines Anbieters verfügbar ist, sollte auf eine unterstützte Version umgestiegen werden. PHP 8.2 erhält nur bis zum 31. Dezember 2026 Sicherheitskorrekturen und PHP 8.3 bis zum 31. Dezember 2027. PHP empfiehlt daher, PHP 8.4 oder 8.5 anzustreben.
Jede PHP-Installation muss berücksichtigt werden. Dazu zählen Produktionsserver, container, Staging-Websites, Appliances und Produkte von Drittanbietern, die PHP mitliefern. Inoffizielle Fix-Plugins und kopierte Codeausschnitte sollten vermieden werden, da sie nicht überprüft sind und eine Website beschädigen können. Falls ein Dienst mit hohem Risiko nicht sofort aktualisiert werden kann, empfiehlt auch das UK NCSC, ihn offline zu nehmen oder in den maintenance mode zu versetzen.
Nur ein Update behebt die PHP-Schwachstelle vollständig.