PHP security update dringend empfohlen, da sich Exploit-Versuche ausbreiten
Ein PHP security update ist für zwei kritische Schwachstellen dringend erforderlich, durch die ein nicht authentifizierter Angreifer, also jemand, der nicht angemeldet ist, Code auf einem betroffenen web server ausführen kann. Die Schwachstellen CVE-2026-109618 und CVE-2026-109619 haben jeweils einen CVSS-v4.0-Wert von 9,2. CVSS ist eine Standardskala zur Bewertung des Schweregrads von Schwachstellen. Öffentliches Exploit-Material ist verfügbar, und mehrere Sicherheitsunternehmen haben von Exploit-Versuchen berichtet.
PHP, die serverseitige Software, mit der viele Websites und Webanwendungen erzeugt werden, hat korrigierte Versionen für vier unterstützte Branches veröffentlicht: PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Administratoren eigener server oder Virtual Private Servers (VPSs), also aus der Ferne gehosteter server, die einem einzelnen Kunden zugewiesen sind, sollten die passende Version sofort installieren. Kunden mit Shared Hosting oder Managed Hosting sollten sich bestätigen lassen, dass ihr Anbieter entweder eine korrigierte Version oder ein ausdrücklich gepatchtes Paket bereitgestellt hat.
Beide Schwachstellen betreffen den Umgang von PHP mit internen request-Daten, also den Informationen, die empfangen werden, wenn ein Browser oder ein anderes System eine Website kontaktiert. Es handelt sich um Fehler in der PHP runtime, der zugrunde liegenden Software, die PHP-Code ausführt, und nicht um Fehler in WordPress, einem anderen Content-Management-System, einem Plugin, einem Theme oder einer einzelnen Anwendung. Die Aktualisierung dieser Komponenten ist weiterhin eine gute Sicherheitspraxis, behebt diese beiden PHP-Schwachstellen jedoch nicht.
CVE-2026-109618 kann auftreten, wenn PHP der Arbeitsspeicher ausgeht, während request-Daten erst teilweise vorbereitet sind. Bei der Bereinigung kann PHP die unvollständigen Daten als gültig behandeln. Dies kann zu memory corruption führen, bei der vorübergehend von einem Programm gespeicherte Informationen beschädigt oder falsch verarbeitet werden, und letztlich remote code execution ermöglichen. remote code execution, häufig als RCE abgekürzt, bedeutet, dass ein Angreifer den server von einem anderen Ort aus Befehle ausführen lassen kann.
CVE-2026-109619 betrifft einen veralteten internen Zustand. Ein PHP worker, also ein laufender Prozess, der Webanfragen verarbeitet, kann eine Referenz auf request-Daten behalten, nachdem der dahinterliegende Speicher freigegeben wurde. Eine spätere Anfrage, die von demselben PHP worker verarbeitet wird, kann auf die alten Informationen zugreifen, bevor PHP sie zurücksetzt. Das Ergebnis kann information disclosure oder remote code execution sein.
Laut dem Advisory von Sucuri sollte jede PHP-Installation, die Webanfragen verarbeitet, als potenziell exponiert betrachtet werden. Dazu gehören PHP-FPM beziehungsweise FastCGI Process Manager, der Pools von PHP workers betreibt, ebenso wie Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. PHP betrachtet mod_php als die Konfiguration mit dem höchsten Risiko, weil eine nicht authentifizierte Anfrage einen nachgewiesenen Exploit auslösen kann, bevor der Anwendungscode der Website ausgeführt wird.
Öffentlicher proof-of-concept code, der zeigt, wie eine Schwachstelle ausgenutzt werden kann, verbreitete sich bereits vor den offiziellen Korrekturen. Hadrian berichtete, PHP2Shell werde in großem Umfang ausgenutzt, und erklärte, dass die meisten beobachteten Aktivitäten den session upload-progress-Pfad von PHP verwendeten. Das Unternehmen warnte außerdem, dass wahrscheinlich weitere Wege hinzukommen würden. WatchTowr, Patchstack, Cloudflare und Vega berichteten unabhängig voneinander über bösartige Aktivitäten oder Versuche im Zusammenhang mit den Schwachstellen. Ein Exploit-Versuch allein beweist nicht, dass ein server kompromittiert wurde, aber der öffentliche Code und das Ausmaß der gemeldeten Aktivitäten erhöhen die Dringlichkeit des Patchings.
Nach der Installation von PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 über das Betriebssystem, das Hosting-Control-Panel, den Paketanbieter oder einen etablierten Deployment-Prozess müssen Administratoren die relevanten PHP workers und Dienste neu starten oder neu laden. Anschließend sollten sie überprüfen, welche Version tatsächlich die Live-Website bedient. Die vom Befehlszeilenbefehl php -v zurückgegebene Version kann sich von der mit dem web server verbundenen Version unterscheiden. Logins, Checkout-Abläufe, Formulare, Uploads, geplante Aufgaben, Application Programming Interfaces (APIs) und Administrationsseiten sollten nach der Änderung vollständig getestet werden.
Shared-Hosting-Kunden können in ihrem Control-Panel nach einer PHP-Versionsauswahl suchen. Wenn dort keine korrigierte Version angezeigt wird, sollten sie den Anbieter fragen, ob er einen Vendor-Backport-Fix installiert hat, bei dem die Sicherheitskorrektur einem älteren Software-Branch hinzugefügt wurde, oder wann eine korrigierte Version verfügbar sein wird. Eine angezeigte Versionsnummer allein reicht nicht aus, da Betriebssystem- und Long-Term-Support-Anbieter manchmal Sicherheitskorrekturen hinzufügen, ohne die Branch-Nummer zu ändern.
PHP 8.1 und ältere Versionen befinden sich außerhalb des normalen Support-Zyklus des Projekts und erhalten keine regulären Upstream-Point-Releases. Wegen des Schweregrads dieser Schwachstellen hat PHP jedoch Emergency Source Backports für PHP 7.4, PHP 8.0 und PHP 8.1 veröffentlicht. Linux-Distributionen und Long-Term-Support-Anbieter können ebenfalls gepatchte Pakete bereitstellen. Betreiber müssen auf einen unterstützten Branch aktualisieren, ein Paket installieren, das ausdrücklich sowohl CVE-2026-109618 als auch CVE-2026-109619 behebt, oder den jeweiligen Emergency Source Backport anwenden. Diese Notfallkorrekturen stellen den langfristigen Support nicht wieder her, weshalb die Migration auf einen unterstützten PHP-Branch langfristig die sicherere Vorgehensweise bleibt.
Sucuri gibt an, dass seine bestehenden Regeln für die web application firewall (WAF) bereits einige mit den Schwachstellen verbundene bösartige request-Muster abgewiesen hätten und dass spezifischere virtual patching-Regeln für bekannte PHP2Shell-Pfade hinzugefügt worden seien. Eine WAF ist ein Filterdienst, der vor einer Website platziert wird, um eingehende Anfragen zu prüfen. virtual patching bedeutet, erkannten Exploit-Datenverkehr zu blockieren, bevor er verwundbare Software erreicht. Es beseitigt den Fehler jedoch nicht und kann das PHP security update nicht ersetzen.
Auch die Filterung durch eine firewall scheitert, wenn ein Angreifer den origin server, also den Rechner, auf dem die Website tatsächlich gehostet wird, direkt kontaktieren kann, ohne den Filterdienst zu durchlaufen. Betreiber sollten den direkten IPv4- und IPv6-Zugriff beschränken, Webdatenverkehr nur von genehmigten firewall-Adressen zulassen und prüfen, ob alte DNS records oder alternative Hostnamen den origin server offenlegen. Staging-, Entwicklungs-, Test- und Backup-Umgebungen sollten geschützt oder zugriffsbeschränkt sein. Ungeschützte Subdomains und alternative Ports dürfen keinen weiteren Weg zur selben Anwendung eröffnen. Alte Container, server images und Autoscaling-Templates sollten ebenfalls überprüft werden, damit sie nicht weiterhin verwundbare PHP-Builds bereitstellen.
Falls sofortiges Patching nicht möglich ist, bleibt eine Aktualisierung laut PHP die einzige vollständige Lösung. Da ein großer Teil der beobachteten Aktivitäten auf den session upload progress abzielte, können Administratoren vorübergehend session.upload_progress.enabled = Off in php.ini, einem FPM-Pool oder einer anderen serverseitigen Konfiguration festlegen, die vor dem request parsing angewendet wird, und anschließend jeden betroffenen PHP worker neu starten. Diese Maßnahme blockiert nur bestätigte session-bezogene Wege für CVE-2026-109619. Sie deckt nicht jeden Weg für diese Schwachstelle ab, schützt überhaupt nicht vor CVE-2026-109618 und kann Anwendungen beeinträchtigen, die den PHP upload progress anzeigen. PHP stellt weitere vorübergehende Empfehlungen für den Out-of-Memory-Weg bereit, doch alle derartigen Maßnahmen sollten nur als kurzfristige Übergangslösungen betrachtet werden.