PHP stopft zwei kritische Lücken für Remotecode-Ausführung, Angriffe bereits unterwegs
Mit den Updates 8.5.12, 8.4.27, 8.3.36 und 8.2.35 behebt PHP zwei kritische Schwachstellen, die Code-Ausführung ohne Anmeldung erlaubten. Amazon beobachtete einen Ausnutzungsversuch schon vier Tage vor Veröffentlichung der Patches.
PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 enthalten Korrekturen für CVE-2026-109618 und CVE-2026-109619, die beide unter CVSS v4.0 mit 9,2 bewertet sind und den Beinamen php2shell tragen. Bei beiden handelt es sich um Verletzungen der Speichersicherheit im Request-Lebenszyklus, eine im Umgang mit Out-of-Memory-Situationen und eine bei Zuständen, die die Speicherbasis überdauern, und laut Sansec sind sie in jeder ungepatchten PHP-Version seit 5.4 vorhanden. In der Ankündigung heißt es unmissverständlich zu den Optionen: "Es gibt keine vollständigen Minderungen; ein Update ist die einzige sichere Wahl."
Die Exposition hängt davon ab, wie PHP betrieben wird, und die Sicherheitshinweise sind genau darin, was tatsächlich nachgewiesen wurde. Bei Apache mod_php wurde für beide Schwachstellen eine entfernte Codeausführung bestätigt, validiert "über HTTP gegen mod_php mit den PHP-Standardeingabe- und Speicherlimits." Für PHP-FPM wurde der Fall des Session-Lebenszyklus validiert, doch beim Out-of-Memory-Fehler stellt der Hinweis klar, dass "für diese SAPI kein vollständiger FPM-Exploit demonstriert wurde." FrankenPHP wird allein aufgrund der Quellcodeanalyse als wahrscheinlich anfällig beschrieben.
Die Angreifer kamen vor dem Patch an. Amazon Threat Intelligence fand in der MadPot-Telemetrie einen Ausnutzungsversuch vom 17. Oktober, der von "einer IP-Adresse aus dem Umfeld eines kommerziellen Anonymisierungsnetzwerks" stammte, und riet Kunden, Vorfälle "zumindest ab dem 17. Oktober" zu untersuchen. Cloudflare setzte WAF-Regeln am 21. Oktober um 03:02 UTC ein, rund neun Stunden vor der Veröffentlichung.
Die koordinierte Offenlegung war bereits gescheitert. Die PHP Foundation berichtet selbst, dass die CVE-Identifikatoren zwei Tage vorzeitig kursierten, dass ein Forscher "versehentlich ein Video" mit einem Proof of Concept veröffentlichte und dass "Chainguard die Embargofrist einseitig brach und fertige Images mit dem Fix veröffentlichte." Die Folge sei gewesen, dass "jeder Angreifer den Fix in Binärform studieren konnte, während alle anderen PHP-Nutzer noch auf die Veröffentlichung warteten." Die veröffentlichte Richtlinie von Chainguard, zuletzt einen Monat vor dem Vorfall aktualisiert, erlaubt es, Offenlegungsfristen zu verkürzen, wenn "eine Schwachstelle als aktiv ausgenutzt entdeckt wird."
Manche Betreiber nahmen ihre Dienste lieber vom Netz, statt zu warten. Auf r/selfhosted beschrieb der Kommentator iamShorteh die Abschaltung:
Ich habe alle meine Websites offline genommen (Apache2 abgeschaltet). Jemand hat vor ein paar Stunden die Schritt-für-Schritt-Anleitung für die RCE auf Twitter geleakt. Ich will nicht riskieren, noch 5 bis 6 Stunden zu warten, bis der Hotfix erscheint.
Das niederländische nationale Cyber-Sicherheitszentrum nahm seine eigene Website vorsorglich offline, ebenso die niederländische Abgeordnetenkammer. Sansec teilten Geschäften mit, dass dies nicht nötig sei.
Herauszufinden, ob PHP überhaupt lief, stand für viele an erster Stelle. Kommentatoren fanden es hinter OPNsense, OpenMediaVault, Nextcloud und Coolify, und der Kommentator spartacle benannte, warum das schwer war:
Bei vielem Homelab-Zeug ist es wirklich übel, aber ich weiß nicht, welche Sprachen ein Haufen der Software nutzt; Container haben das vor mir verborgen.
Dann kam das Warten auf die Pakete. Debian Trixie erschien schnell, während Ubuntu, Red Hat und die offiziellen Docker-Images nachzogen, und der Kommentator Takeoded wies darauf hin, dass das Ubuntu-Sicherheitsteam dreizehn Minuten nach der Offenlegung noch nichts veröffentlicht hatte. Der Maintainer Ondřej Surý erhielt in r/PHP den lautesten Dank, und sein Launchpad-PPA brach unter der Last zusammen, woraufhin die Betreiber zu packages.sury.org auswichen, wo das PPA ohnehin zusammengeführt wird. Ein Team verzichtete auf Docker Hub und baute die Images selbst aus dem zusammengeführten Dockerfile, was in acht Minuten erledigt war.
Zu bestätigen, dass der Patch tatsächlich eingespielt war, erwies sich als eigene Falle. Der Kommentator SirRobinBlibs sammelte die Stolpersteine, die den Leuten Zeit kosteten:
Distro-Builds backporten. Das gefixte Paket von Ubuntu 24.04 ist 8.3.6-0ubuntu0.24.04.13 und meldet weiterhin 8.3.6. Prüfe die vollständige Paketversion im Tracker deiner Distribution, nicht mit php -v. Die CLI ist nicht der Webserver. FPM- und Apache-Worker behalten die alte Engine im Speicher, bis sie neu gestartet werden.
Der Ubuntu-Hinweis bestätigt diese Versionsangaben. Beide PHP-Sicherheitshinweise fordern die Betreiber auf, nach dem Update jeden Worker neu zu starten.
Wie schwerwiegend es tatsächlich war, ist noch umstritten. Beide CVEs tragen AC:H und AT:P, also hohe Angriffskomplexität mit zusätzlichen Angriffsvoraussetzungen, und Sansec revidierte seine Erwartung einer Massenausnutzung:
Die öffentlichen Exploits funktionieren nicht gegen eine PHP-Standardinstallation.
Praktiker kamen zum gleichen Ergebnis. SirRobinBlibs warnte davor, mit GitHub-Proof-of-Concepts zu testen, weil "die meisten mit Sternen versehenen auf einem unveraenderten PHP nicht funktionieren und bösartige PoC-Repositories ein bekanntes Phänomen sind", und JFrog dokumentierte gefälschte Exemplare, die als Scherz kursierten, darunter eines, das das Wallpaper des Opfers änderte.
Kommentatoren in r/PHP fragten, wie viele Leute diese Arbeit leisten. Die Foundation antwortete im selben Beitrag und schrieb, dass die Sicherheitsarbeit an PHP "weiterhin von einer kleinen Gruppe foundation-finanzierter Entwickler abhängt" und dass "es heute zu wenige davon gibt."
Die Upgrade-Lücke erhielt den am höchsten bewerteten Kommentar des Threads, der die End-of-Life-Politik als brutal bezeichnete. PHP 8.1 und älter erhält vom Projekt nichts, obwohl es minimale Backports für 7.4, 8.0 und 8.1 veröffentlichte, und Ubuntu lieferte Fixes bis hinunter zu 14.04 im Rahmen von ESM. PHP 8.2 erreicht das Lebensende am 31. Dezember 2026.
Ein drittes Problem, CVE-2026-115560, ist weiterhin ungepatcht. PHP rät, session.upload_progress.enabled=0 zu setzen, bis zur nächsten Bugfix-Veröffentlichung, mit der auch der vollständige Sicherheitshinweis erscheinen soll.
PostgreSQL für Time-Series im großen Maßstab Bewältigen Sie riesige Time-Series-Datenmengen mit PostgreSQL, ohne Leistungseinbußen. Erfahren Sie, wie Tiger Data schnelles Ingest, schnelle Abfragen und skalierbaren Speicher bietet. Mehr erfahren.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 carry fixes for CVE-2026-109618 and CVE-2026-109619, both rated 9.2 under CVSS v4.0 and nicknamed php2shell. Both are memory-safety failures in the request lifecycle, one in out-of-memory handling and one in state that outlives the memory backing it, and Sansec reports they are present in every unpatched PHP since 5.4. The announcement is blunt about the options: "There are no complete mitigations; updating is the only safe choice."
Exposure varies by how PHP is served, and the advisories are careful about what has actually been proven. Apache mod_php carries confirmed remote code execution for both, validated "over HTTP against mod_php with default PHP input and memory limits." For PHP-FPM the session lifecycle case was validated, but on the out-of-memory bug the advisory states that "no complete FPM exploit has been demonstrated for this SAPI." FrankenPHP is described as likely susceptible on source analysis alone.
Attackers arrived before the patch did. Amazon Threat Intelligence found an exploitation attempt dating to October 17 in MadPot telemetry, originating from "an IP address associated with a commercial anonymization network," and told customers to investigate "from at least starting on October 17th." Cloudflare deployed WAF rules at 03:02 UTC on October 21, roughly nine hours ahead of release.
The coordinated disclosure had already collapsed. In its own account, the PHP Foundation says the CVE identifiers began circulating two days early, that a researcher "mistakenly published a video" showing a proof of concept, and that "Chainguard unilaterally broke the embargo and published built images containing the fix." The consequence, it writes, was that "any attacker could now study the fix in binary form while every other PHP user was still waiting for the release." Chainguard’s published policy, last updated a month before the incident, allows it to shorten disclosure timelines when "a vulnerability is discovered to be under active exploitation."
Some operators stopped serving rather than wait. On r/selfhosted, commenter iamShorteh described shutting down:
I’ve taken all of my websites offline (turned off apache2). Somebody leaked the step by step for RCE on twitter a few hours ago. Not going to risk sitting around another 5-6 hours until the hotfix lands.
The Dutch national cyber security centre took its own website offline as a precaution, as did the Dutch House of Representatives. Sansec told stores they did not need to.
Working out whether PHP was running at all came first for many. Commenters found it behind OPNsense, OpenMediaVault, Nextcloud and Coolify, and commenter spartacle named why that was hard:
For quite a bit of homelab stuff, it’s really bad but I don’t know what languages a bunch of stuff uses, containers obfuscated this away from me.
Then came the wait for packages. Debian Trixie landed quickly while Ubuntu, Red Hat and the official Docker images trailed, and commenter Takeoded noted the Ubuntu security team had published nothing thirteen minutes after disclosure. Maintainer Ondřej Surý drew the loudest thanks on r/PHP, and his Launchpad PPA buckled under load, sending operators to packages.sury.org, where the PPA is being merged anyway. One team gave up on Docker Hub and built images from the merged Dockerfile themselves, finishing in eight minutes.
Confirming the patch had taken proved its own trap. Commenter SirRobinBlibs collected the ones that cost people time:
Distro builds backport. Ubuntu 24.04’s fixed package is 8.3.6-0ubuntu0.24.04.13, which still reports 8.3.6. Check the full package version against your distro’s tracker, not php -v. The CLI isn’t the web server. FPM/Apache workers keep the old engine in memory until restarted.
Ubuntu’s advisory confirms those version strings. Both PHP advisories tell operators to restart every worker after updating.
How bad it proved is still contested. Both CVEs carry AC:H and AT:P, high attack complexity with additional attack requirements, and Sansec revised its expectation of mass exploitation:
The public exploits do not work against a default PHP installation.
Practitioners found the same. SirRobinBlibs warned against testing with GitHub proof-of-concepts because "most of the starred ones don’t work on vanilla PHP, and malicious PoC repos are a known thing," and JFrog documented fake ones spreading as pranks, including one that changed the victim’s wallpaper.
Commenters on r/PHP asked how many people handle this work. The Foundation answered in the same post, writing that security work on PHP "still depends on a small group of foundation-funded developers" and that "today there are too few of them."
The upgrade gap drew the thread’s highest-voted comment, which called the end-of-life policy brutal. PHP 8.1 and older get nothing from the project, though it published minimal backports for 7.4, 8.0 and 8.1, and Ubuntu issued fixes as far back as 14.04 under ESM. PHP 8.2 reaches end of life on December 31, 2026.
A third issue, CVE-2026-115560, remains unpatched. PHP advises setting session.upload_progress.enabled=0 until the next bugfix release, when it will publish the full advisory.
PostgreSQL Built for Time-Series Scale Handle massive time-series data with PostgreSQL, without sacrificing performance. Discover how Tiger Data delivers high-speed ingest, fast queries, and scalable storage. Learn More.