PHP-Exploits sind öffentlich, Hoster müssen jetzt patchen

Das PHP-Projekt hat am 21. Oktober zwei kritische Lücken geschlossen, über die Angreifer ohne Anmeldung Code auf Webservern ausführen können; öffentliche Exploits existieren bereits. Das PHP-Update wirkt nur dort, wo Hoster, Distribution oder eigenes Team die Runtime austauschen. Für PHP 7 und 5 hat das Projekt keine fertige Fix-Version veröffentlicht.

Verwandt: Simon Gooch: KI-Agenten brauchen einen getesteten Stopp  ·  Wenn gekaufte KI-Router Schadcode einschleusen

Der Ablauf am 21. Oktober

Das PHP-Security-Team hatte das Update am 20. Oktober für den Folgetag um 14:00 UTC angekündigt. Für den Fall, dass Details vorher öffentlich werden, behielt es sich eine frühere Veröffentlichung vor. Die Advisories zu den beiden Lücken erschienen am 21. Oktober um 13:34 UTC auf GitHub. Noch vor dem Release schrieb die PHP-Core-Entwicklerin Gina Peter Banyard, die einzige Gegenmaßnahme sei, PHP zu patchen oder zu aktualisieren.

Die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 schließen die Fehler. Das PHP-Projekt rät allen Nutzern zum sofortigen Update. Das RUS-CERT der Universität Stuttgart meldete am selben Tag öffentlich verfügbare Exploits. Einen davon verifizierte es an einem Testsystem, Angriffe auf verwundbare Systeme im Internet waren bereits beobachtet. Das BSI riet in einer Cybersicherheitswarnung zur unverzüglichen Installation. Bestätigte Ausnutzungen kannte das BSI zu diesem Zeitpunkt nicht, wohl aber unbestätigte Berichte über existierende Exploits.

Die PHP-Lücken fielen in dieselbe Woche wie ein Vorfall bei der Zertifizierungsstelle eMudhra. Mozilla und Google entzogen einer ihrer Wurzeln das Vertrauen, weil acht Zwischenzertifikate darunter Schlüssel trugen, die sich praktisch sofort zurückrechnen ließen.

Was ist Remote Code Execution? Remote Code Execution, kurz RCE, bezeichnet Schwachstellen, über die Angreifer aus der Ferne eigenen Programmcode auf einem fremden System ausführen. Bei den aktuellen PHP-Lücken ist dafür keine Anmeldung nötig. Bei Apache mit mod_php löst eine Webanfrage den Angriff aus, bevor irgendein Anwendungscode läuft.

Zwei Fehler im Speicher

Das PHP-Projekt bewertet beide Schwachstellen auf der CVSS-v4.0-Skala mit 9,2. Die Skala ordnet Schweregrade von 0 bis 10 ein. CVE-2026-109618 betrifft den Umgang mit Speichermangel. PHP kann dabei unterbrochen werden, während interne Anfragedaten erst teilweise angelegt sind. Das Aufräumen der Anfrage behandelt die ungültigen Daten danach als gültig. Den Speicher erschöpfen lässt sich über Multipart-Anfragen, also Webanfragen aus mehreren Teilen wie bei Datei-Uploads, die scheinbar innerhalb der PHP-Grenzen bleiben.

CVE-2026-109619 betrifft internen Zustand, der eine Anfrage überlebt, nachdem ihr Speicher freigegeben wurde. Eine spätere Anfrage an denselben Worker, also denselben PHP-Prozess, kann diesen veralteten Zustand nutzen, bevor die normale Initialisierung ihn zurücksetzt. Über ein gezielt präpariertes Speicherlayout wird daraus Codeausführung.

Gefährdet ist jede PHP-Installation, die Webanfragen bedient, ob über PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP oder LiteSpeed. Das höchste Risiko sieht das Projekt bei mod_php, dem direkt in Apache geladenen PHP-Modul. Dort wurde ein Exploit gezeigt, bei dem eine Anfrage ohne Anmeldung den Angriff auslöst, bevor irgendein Anwendungscode läuft. Für CVE-2026-109618 fehlt ein vollständiger Exploit gegen PHP-FPM, die Quellcode-Analyse stützt aber die Anfälligkeit. Für CVE-2026-109619 hat das Projekt Codeausführung auch gegen PHP-FPM bestätigt, dort setzt sie allerdings einen passenden Vorgang in der Anwendung voraus. Bei der ersten Lücke ist FrankenPHP nach der Quellcode-Analyse wie mod_php wahrscheinlich unabhängig von der Anwendung angreifbar.

Wer den Patch einspielt

Linux-Distributionen und LTS-Anbieter, die ältere Versionsstände über das offizielle Support-Ende hinaus pflegen, haben die Patches vorab erhalten. Betreiber sollen bei ihrem Anbieter nach aktualisierten Paketen schauen. Bei Managed- und Shared-Hosting spielt der Provider das Update ein, dort steht die Frage nach dem Zeitplan an. Für eigene Server gilt die Empfehlung, kurz nach der Veröffentlichung ein Wartungsfenster zu planen.

Ubuntu stuft CVE-2026-109618 mit der Priorität „Critical“ ein. Die PHP-Pakete der unterstützten Ubuntu-Releases standen am Nachmittag des 21. Oktober aber noch auf „Needs evaluation“. Betreiber, die PHP aus diesen Paketen beziehen, hängen beim Update an dieser Bewertung.

Notbehelfe mit begrenzter Wirkung

Wer nicht sofort aktualisieren kann, kann einzelne Angriffswege eindämmen. Dazu zählen memory_limit=-1 über php_admin_value, ein niedriger Wert für post_max_size und session.upload_progress.enabled=0, jeweils mit Neustart jedes Workers. Das PHP-Projekt stellt klar, dass diese Maßnahmen eine Installation nicht sicher machen. Eine vollständige Lösung ist allein das Update.

Nach Einschätzung des RUS-CERT reichen die veröffentlichten Gegenmaßnahmen nicht aus, um eine öffentlich erreichbare PHP-Anwendung zu betreiben. CERT-EU rät in seinem Advisory 2026-018 Organisationen ohne Möglichkeit zum sofortigen Patchen, eine Trennung aus dem Internet erreichbarer Anwendungen vom öffentlichen Netz zu erwägen, bis ein Fix verfügbar ist.

Alte Zweige als Migrationsfrage

PHP läuft auf rund sieben von zehn Websites, deren serverseitige Programmiersprache bekannt ist. Knapp zwei Drittel dieser PHP-Websites nutzen Version 8. Rund 35 Prozent laufen auf den Hauptversionen 7 und 5, für die das PHP-Projekt keine fertige Fix-Version veröffentlicht hat.

Reguläre Updates erhalten nur die Zweige 8.2 bis 8.5. Die Unterstützung für PHP 8.1 endete am 31. Dezember 2025, die für 8.0 und 7.4 schon Jahre früher. Wegen der Schwere der Lücken stellte das PHP-Security-Team trotzdem minimale Quellcode-Backports für 7.4, 8.0 und 8.1 bereit, also auf alte Zweige übertragene Korrekturen. Sie richten sich an Betreiber, die selbst aus dem Quellcode bauen oder keinen LTS-Anbieter haben. Einige Distributionen und LTS-Anbieter liefern ebenfalls zurückportierte Fixes.

Für Zweige vor 7.4 hat das Security-Team keinen Backport bereitgestellt. Der älteste noch gepflegte Zweig 8.2 erhält Sicherheitsunterstützung nur noch bis zum 31. Dezember 2026.

Häufige Fragen

Jede Frage ist verschlossen. Ein Tippen entriegelt die Antwort.

Hilft es, PHP-Fehlermeldungen zu unterdrücken?

Nein. Weder error_reporting noch display_errors noch der @-Operator schützen gegen die beiden Lücken. Eine vollständige Lösung ist nur das Update der Runtime.

Was gilt für Nutzer des Paketarchivs rpms.remirepo.net?

Das freiwillig betreute Archiv erhält am 21. Oktober keine Updates. Das PHP-Projekt rät dessen Nutzern, auf Pakete der Distribution umzusteigen oder PHP selbst zu bauen.

Wie lange erhalten die gepatchten Zweige noch Sicherheitsupdates?

PHP 8.2 erhält Sicherheitsunterstützung bis 31. Dezember 2026, PHP 8.3 bis 31. Dezember 2027. Für PHP 8.4 gilt der 31. Dezember 2028, für PHP 8.5 der 31. Dezember 2029.

Lesetipps der Redaktion

LesetippGoogle und Apple vertrauten erratbaren eMudhra-SchlüsselnLesetippWenn der Security-Stack schneller wächst als die StrategieLesetippOpenSSL: Was Hersteller jetzt nachweisen müssen

Bildquelle: KI-generiert (Oktober 2026)

Mehr aus dem MBF Media Netzwerk

cloudmagazinGoogle kontert Meta mit Spitzen-KI zum halben Preis MyBusinessFutureNachfolge: Käufer brauchen die Bankzusage vor dem Termin Digital ChiefsMicrosoft: Deutschland ist EU-Spitze bei Cyberangriffen