PHP-Sicherheitsupdate behebt zwei aktiv angegriffene RCE-Schwachstellen
Ein PHP-Sicherheitsupdate behebt zwei kritische Schwachstellen, durch die ein nicht authentifizierter Angreifer Code auf einem Webserver ausführen könnte. Der Begriff remote code execution (RCE) bedeutet, dass ein Angreifer das betroffene System Befehle ausführen lassen kann, ohne sich zuvor anzumelden. Die Schwachstellen CVE-2026-109618 und CVE-2026-109619 haben jeweils einen CVSS v4.0-Wert von 9,2. Sucuri berichtete am 21. Oktober 2026, dass bereits Ausnutzungsversuche beobachtet wurden.
PHP hat vier bereinigte Versionen veröffentlicht: PHP 8.5.12, PHP 8.4.27, PHP 8.3.36 und PHP 8.2.35. Administratoren, die einen eigenen Server oder virtuellen privaten Server betreiben, sollten die passende Version über ihr Betriebssystem, ihren Paketanbieter, ihr Control Panel oder ihren etablierten Bereitstellungsprozess installieren. Kunden von Shared oder Managed Hosting sollten sich bestätigen lassen, dass ihr Anbieter einen bereinigten PHP-Build oder ein Paket mit einem ausdrücklichen backport der Korrekturen installiert hat.
Es handelt sich um Schwachstellen in der PHP runtime, also der Serversoftware, die PHP-Anwendungen ausführt, und nicht in WordPress, einem anderen content management system, einem plugin oder einem theme. Eine Aktualisierung des WordPress core und seiner Erweiterungen beseitigt das anfällige Serververhalten daher nicht. Laut Sicherheitshinweis sollte jede PHP-Installation, die Webanfragen verarbeitet, als potenziell gefährdet betrachtet werden. Dazu gehören PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. PHP betrachtet mod_php als die Konfiguration mit dem höchsten Risiko, da ein nachgewiesener exploit durch eine nicht authentifizierte Anfrage ausgelöst werden kann, bevor der Anwendungscode der Website ausgeführt wird.
CVE-2026-109618 betrifft eine out-of-memory condition, die eintritt, wenn ein Prozess nicht den benötigten Arbeitsspeicher erhalten kann. PHP kann unterbrochen werden, während interne Anfragedaten nur teilweise initialisiert sind. Während der Bereinigung kann PHP diese unvollständigen Daten fälschlicherweise als gültige Informationen behandeln, den Speicher beschädigen und möglicherweise remote code execution ermöglichen.
CVE-2026-109619 betrifft einen stale internal state. Ein PHP worker, also ein Prozess, der Websiteanfragen verarbeitet, kann einen Verweis auf Anfragedaten behalten, nachdem der zugrunde liegende Speicher bereits freigegeben wurde. Eine spätere Anfrage, die von demselben PHP worker verarbeitet wird, kann auf die veralteten Informationen zugreifen, bevor PHP sie zurücksetzt. Dies könnte zur Offenlegung von Informationen oder zu remote code execution führen.
Öffentlich verfügbarer proof-of-concept code, der zeigt, wie eine Schwachstelle ausgelöst werden kann, kursierte bereits vor dem Erscheinen der offiziellen Korrekturen. Hadrian erklärte, PHP2Shell-Ausnutzung in großem Umfang zu beobachten, und berichtete, dass ein großer Teil der festgestellten Aktivitäten den session upload-progress path von PHP missbrauchte. Das Unternehmen warnte außerdem, dass wahrscheinlich weitere Ausnutzungswege auftreten würden. WatchTowr, Patchstack, Cloudflare und Vega meldeten unabhängig voneinander schädliche Aktivitäten oder Versuche im Zusammenhang mit den Schwachstellen. Ein Ausnutzungsversuch allein beweist nicht, dass ein Server erfolgreich kompromittiert wurde. Der öffentliche Code und das hohe Aktivitätsvolumen machen ein schnelles Patchen jedoch wichtig.
Nach der Installation des PHP-Sicherheitsupdates müssen Administratoren die als PHP worker laufenden Prozesse und alle zugehörigen Dienste neu starten oder neu laden, damit die aktiven Prozesse den neuen Build verwenden. Anschließend sollten sie prüfen, welche Version tatsächlich die produktive Website bedient. Die vom Kommandozeilenbefehl php -v angezeigte Version kann sich von der Version unterscheiden, die der Webserver verwendet. Die Tests sollten Anmeldungen, Bezahlvorgänge, Formulare, Datei-Uploads, geplante Aufgaben, application programming interfaces (APIs) und Administrationsseiten abdecken.
Websites, die PHP 8.1 oder älter verwenden, erfordern besondere Sorgfalt. Diese Branches befinden sich außerhalb des normalen PHP-Supportzyklus und erhalten keine regulären upstream point releases. Aufgrund der Schwere dieser Schwachstellen veröffentlichte PHP Notfall-backports des Quellcodes für PHP 7.4, PHP 8.0 und PHP 8.1. Linux-Distributionen und Long-Term-Support-Anbieter können eigene gepatchte Pakete bereitstellen. Eine angezeigte Versionsnummer reicht nicht aus, um festzustellen, ob eine ältere Installation sicher ist, da Anbieter eine Sicherheitskorrektur anwenden können, ohne die Branch-Nummer zu ändern. Administratoren müssen bestätigen, dass das installierte Paket ausdrücklich beide CVE-Kennungen abdeckt. Diese Notfall-backports stellen den langfristigen Support nicht wieder her. Der Wechsel zu einer unterstützten PHP branch bleibt daher langfristig die sicherere Vorgehensweise.
Sucuri teilte mit, dass seine web application firewall (WAF), eine Filterschicht, die Anfragen prüft, bevor sie eine Website erreichen, bereits einige mit den Schwachstellen verbundene schädliche Muster blockierte. Das Unternehmen hat gezieltere Regeln für virtual patching für bekannte PHP2Shell-Pfade hinzugefügt. Diese Filter können die Gefährdung während der Bereitstellung eines Updates verringern, korrigieren PHP selbst jedoch nicht und können nur Anfragen blockieren, die sie erkennen. PHP erklärt, dass die Installation eines gepatchten Builds die einzige vollständige Lösung ist.
Die Firewall-Filterung setzt außerdem voraus, dass der Datenverkehr die Firewall durchläuft. Wenn ein Angreifer eine direkte Verbindung zum origin server herstellen kann, also zu dem Computer, auf dem die Website tatsächlich gehostet wird, können die Filterregeln umgangen werden. Administratoren, die die WAF von Sucuri verwenden, sollten den direkten IPv4- und IPv6-Zugriff beschränken, Webdatenverkehr ausschließlich von genehmigten Sucuri Firewall-Adressen akzeptieren und alte DNS records oder alternative Hostnamen entfernen, die den origin offenlegen. Staging-, Entwicklungs-, Test- und Backup-Umgebungen benötigen ebenfalls Schutz oder Zugriffsbeschränkungen. Teams sollten prüfen, dass ungeschützte Subdomains und alternative Ports nicht dieselbe Anwendung zugänglich machen und dass alte Container, Server-Images oder Autoscaling-Templates nicht weiterhin anfällige PHP-Builds bereitstellen.
Wenn das Patchen nicht sofort möglich ist, kann das Deaktivieren von session upload progress auf Serverebene mit `session.upload_progress.enabled = Off` die Gefährdung durch bestätigte sitzungsbezogene Pfade für CVE-2026-109619 verringern. Die Einstellung muss über php.ini, einen FPM pool oder eine andere Konfiguration angewendet werden, die vor dem request parsing geladen wird. Anschließend muss jeder betroffene PHP worker neu gestartet werden. Dies ist nur eine vorübergehende Maßnahme: Sie deckt nicht jeden Pfad zu CVE-2026-109619 ab, schützt überhaupt nicht vor CVE-2026-109618 und kann Anwendungen beeinträchtigen, die den PHP-Uploadfortschritt anzeigen. PHP hat in seinem vollständigen Sicherheitshinweis außerdem vorübergehende Anweisungen für den out-of-memory-Pfad bereitgestellt. Keine Umgehungslösung kann jedoch eine ungepatchte Installation sicher machen.
Administratoren sollten nach unbekannten PHP-Dateien, unerwarteten geplanten Aufgaben, unbekannten Administratorkonten, verdächtigen ausgehenden Verbindungen und ungewöhnlichen uploadbezogenen Anfragen suchen. Für WordPress-Betreiber, die spezialisierte Websiteverwaltung bevorzugen, anstatt alles selbst zu verwalten, bietet AEU Hosting durchgängig abgesichertes Managed WordPress Hosting an. Unabhängig vom Anbieter sollten Betreiber dennoch bestätigen, dass der produktive PHP-Build beide Korrekturen enthält. Unmittelbare Priorität haben die Installation einer bereinigten Version oder eines bestätigten backport, der Neustart von PHP, die Überprüfung der produktiv verwendeten Webversion und die Sicherstellung, dass eine vorhandene Firewall nicht durch direkten Zugriff auf den origin server umgangen werden kann.