PHP behebt zwei kritische unauthentifizierte RCE-Schwachstellen (CVE-2026-109618, CVE-2026-109619): [Aktualisiert für CVE-2026-115560]

Am Mittwoch, dem 21. Oktober 2026, um 14:00 UTC veröffentlichte das PHP-Projekt PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35, um zwei kritische Sicherheitslücken zu beheben. Beide haben einen CVSS-v4.0-Score von 9,2 und können unauthentifizierte Remote Code Execution ermöglichen. Das PHP-Sicherheitsteam empfiehlt: „Es gibt keine vollständigen Gegenmaßnahmen; ein Update ist die einzige sichere Option.“

Diese Fehler stecken in der PHP-Laufzeitumgebung, nicht in einem Composer-Paket. Das ändert, wie Sie sie erkennen und beheben können, wie wir im Folgenden erklären.

Kurzfassung Wenn Sie PHP für die Verarbeitung von Webanfragen einsetzen (PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP, LiteSpeed), aktualisieren Sie noch heute auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35. Wenn Sie Version 8.1 oder älter verwenden, beziehen Sie ein Backport-Paket von Ihrer Distribution oder Ihrem LTS-Anbieter oder führen Sie ein Upgrade durch.

Was ist passiert?

Alle Zeitangaben sind in UTC.

• 20. Oktober: Das PHP-Sicherheitsteam veröffentlichte eine Vorabankündigung für eine kritische Sicherheitsveröffentlichung am 21. Oktober um 14:00 UTC. Sie behebt zwei Schwachstellen mit einem CVSS-v4.0-Score von 9,2. Das Team behielt sich eine frühere Veröffentlichung vor, falls Details bekannt werden oder Angriffe in freier Wildbahn beobachtet werden.

• 21. Oktober, vor 14:00 UTC: Snyk veröffentlichte Hinweise zu beiden CVEs, SNYK-UNMANAGED-PHP-21347795 (CVE-2026-109618) und SNYK-UNMANAGED-PHP-21347796 (CVE-2026-109619), um Kunden über erforderliche Maßnahmen zu informieren und sicherzustellen, dass überwachte Projekte sofort erkannt werden, sobald die behobenen Versionen bekannt sind.

• 21. Oktober, 14:00 UTC: Die PHP-Sicherheitsempfehlung und die vier behobenen Versionen werden veröffentlicht. Innerhalb von etwa 30 Minuten werden die Snyk-Sicherheitshinweise mit allen relevanten Details aktualisiert, einschließlich betroffener Versionsbereiche und behobener Versionen.

• Ab dem 21. Oktober: Linux-Distributionen (die die Patches vorab erhalten hatten) beginnen, eigene Sicherheitshinweise zu veröffentlichen. Snyk veröffentlicht Hinweise dazu, sobald diese erscheinen, zum Beispiel SNYK-UBUNTU2604-PHP85-21373920. Die laufende Übersicht finden Sie unter CVE-2026-109618 und CVE-2026-109619.

Update vom 23. Oktober: session.upload_progress.enabled=0 beibehalten

Am 23. Oktober veröffentlichte das PHP-Projekt einen informativen Sicherheitshinweis zu CVE-2026-115560, einer CVE, die reserviert, aber noch nicht zugewiesen wurde. Er beschreibt einen partiellen Umgehungsweg für CVE-2026-109619. Die Einstellung, die dies verhindert, session.upload_progress.enabled=0, war bereits als Gegenmaßnahme für CVE-2026-109619 aufgeführt.

PHP veröffentlicht nicht übereilt einen Notfall-Fix, da die Voraussetzungen für einen Angriff selten sind und wahrscheinlich auf die meisten Bereitstellungen nicht zutreffen. Eine Anwendung muss session.serialize_handler auf php_binary or php_serialize setzen und anschließend zur Laufzeit mit ini_set() auf php umstellen, bevor sie session_start() aufruft, während der Upload-Fortschritt für Sitzungen aktiviert ist. Anwendungen, die den Serialisierungs-Handler zur Laufzeit nie ändern, können die Funktion aktiviert lassen.

Die Schwachstellen

Beide Schwachstellen liegen im Request-Lebenszyklus der PHP-Engine und können daher erreicht werden, bevor Anwendungscode ausgeführt wird. Das ist ein Grund dafür, dass diese Schwachstellen so weit verbreitet und gefährlich sind.

Technische Details

CVE-2026-109618, RCE durch Speicherbeschädigung bei Speichermangel: Die Behandlung von Speichermangel kann PHP unterbrechen, während interne Request-Daten noch nicht vollständig initialisiert sind. Bei der anschließenden Bereinigung des Requests werden die ungültigen Daten dann als gültig behandelt. Ein Angreifer, der einen Worker mit einer bösartigen Anfrage an sein Speicherlimit bringen kann, kann die Unterbrechung auslösen.

CVE-2026-109619, RCE durch veralteten globalen Zustand: Interner, einem Request zugeordneter Zustand kann bestehen bleiben, nachdem der zugrunde liegende Speicher freigegeben wurde. Ein späterer Request, den derselbe Worker verarbeitet, kann diesen veralteten Zustand verwenden, bevor ihn die normale Initialisierung zurücksetzt. Bei einem Modell mit langlebigen Workern entspricht dies einem Use-after-free über mehrere Requests hinweg.

Diese Fehler wurden mit Unterstützung von KI in einer Laufzeitumgebung entdeckt, die seit drei Jahrzehnten produktiv eingesetzt wird. In einer Welt voller LLMs und Agents laufen weiterhin überall Server – und bei dem Modell, das diese Fehler gefunden hat, handelt es sich um dieselbe Art von Modell, die Angreifern inzwischen zur Verfügung steht. Genau darauf basiert Evo by Snyk: KI-gestützte Sicherheit für Anwendungen, die von Agents ausgeführt werden, nicht nur für die Agents selbst. Die KI-gestützte Entdeckung ist auch ein Grund dafür, dass PHP2Shell nicht die letzte Schwachstelle dieser Art sein wird und Reaktionszeiten inzwischen in Stunden gemessen werden.

Wer ist betroffen?

Alle PHP-Installationen, die Webanfragen verarbeiten, sind gefährdet. Dazu gehören PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP, LiteSpeed usw. Apache mit mod_php ist am stärksten gefährdet. Ein demonstrierter Exploit zeigt, dass eine einzige unauthentifizierte Anfrage den Angriff auslösen kann, bevor Anwendungscode ausgeführt wird.

PHP 8.1 und ältere Versionen erhalten vom PHP-Projekt keine Updates mehr. Daher sind ungepatchte Installationen von 8.1, 8.0 oder 7.4 betroffen und es gibt keinen Upstream-Fix. Angesichts des Schweregrads veröffentlichte das PHP-Sicherheitsteam minimale Backports des Quellcodes für 7.4, 8.0 und 8.1 – für alle, die selbst aus dem Quellcode kompilieren oder keinen LTS-Anbieter haben.

Was Sie jetzt tun sollten

1. Aktualisieren Sie. Behobene Versionen sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Beachten Sie, dass Version 8.2 am 31. Dezember 2026 das Ende ihrer Lebensdauer erreicht. Wenn Sie 8.2 verwenden, sollten Sie daher jetzt auch das nächste Upgrade planen.

2. Prüfen Sie Ihren Anbieter. Linux-Distributionen und LTS-Anbieter haben die Patches vor der Veröffentlichung erhalten. Installieren Sie deren aktualisierte Pakete, statt auf einen Build aus dem Quellcode zu warten. Bei einem gepatchten Distributions-Build kann die Versionsnummer unverändert bleiben. Prüfen Sie daher auch den Sicherheitshinweis oder Patch-Stand der Distribution.

3. Prüfen Sie, was tatsächlich ausgeführt wird. Kontrollieren Sie die PHP-Version auf jedem Host und in jedem Image (php -v oder den Image-Tag). Scan-Ergebnisse allein bestätigen nicht, dass eine Installation behoben ist.

4. Wenn Sie heute nicht aktualisieren können, führt PHP Gegenmaßnahmen auf, die das Risiko bestimmter Angriffswege verringern, eine Installation aber nicht sicher machen: memory_limit=-1 dort festlegen, wo Anwendungen die Einstellung nicht überschreiben können, einen niedrigen Wert für post_max_size verwenden, session.upload_progress.enabled=0 setzen und alle Worker neu starten sowie unter 8.5 fatal_error_backtraces=0 festlegen. Die jeweiligen Sicherheitshinweise erläutern die Einschränkungen der einzelnen Maßnahmen.

5. Unabhängig davon, ob Sie aktualisiert haben, lassen Sie session.upload_progress.enabled=0 bis zum nächsten regulären Bugfix-Release aktiviert, wenn Ihre Anwendung session.serialize_handler zur Laufzeit ändert. Weitere Informationen finden Sie im obigen Update.

6. Bei PHP 8.1 oder älter sollten Sie auf eine unterstützte Version upgraden oder ein Backport-Paket von Ihrer Distribution oder Ihrem LTS-Anbieter beziehen. Die PHP-Backports des Quellcodes für 7.4, 8.0 und 8.1 sind nur die letzte Option für Teams, die selbst aus dem Quellcode kompilieren.

Die Open-Source-Seite

Das PHP-Sicherheitsteam informierte das Ökosystem einen Tag im Voraus über einen festen Veröffentlichungszeitpunkt, den Schweregrad und ohne Angaben zu Angriffen. Die Patches wurden vorab mit Linux-Distributionen geteilt, damit Paket-Fixes zeitgleich mit der Quellcode-Veröffentlichung bereitgestellt werden konnten. Für nicht mehr unterstützte Versionen veröffentlichte das Team Backports (7.4, 8.0, 8.1). Nutzer eines beliebten, von Freiwilligen betriebenen Repositories (rpms.remirepo.net) wurden darüber informiert, dass es am ersten Tag nicht aktualisiert werden würde, und erhielten Hinweise zum weiteren Vorgehen. Außerdem erläutern die Empfehlungen zu Gegenmaßnahmen sehr transparent, wovor die einzelnen Einstellungen nicht schützen.

So sieht eine koordinierte Offenlegung aus, wenn ein von Freiwilligen betriebenes Projekt sie richtig umsetzt. Das ist auch der Grund dafür, dass wir bei Snyk unsere Sicherheitshinweise vor der Veröffentlichung bereitstellen und kurz danach vervollständigen konnten: Ein veröffentlichter Zeitplan ermöglicht allen nachgelagerten Beteiligten, sich vorzubereiten.

So funktioniert Snyk SCA

Snyk Open Source liest aus, was Ihre Anwendung in Manifest- oder Build-Dateien wie composer.json und composer.lock deklariert. Der PHP-Interpreter ist keine deklarierte Abhängigkeit. Er wird über ein Dockerfile, ein Distributionspaket, ein Plattform-Image oder manuell installiert. Eine Einschränkung wie "php": ">=8.2" in composer.json gibt an, welche PHP-Version die Anwendung akzeptiert, aber nicht genau, welche Version bereitgestellt ist.

Wie die Snyk Platform Sie dabei unterstützt, exponierte PHP-Installationen zu finden

Ihre PHP-Angriffsfläche mit Snyk API & Web ermitteln

Bevor Sie Patches einspielen können, benötigen Sie eine Liste. Der Discovery-Tab von Snyk API & Web erfasst Assets auf Ihren Domains und ermittelt ihren Technologie-Stack anhand von Fingerabdrücken. Öffnen Sie Discovery, setzen Sie den Filter Tech auf PHP und Sie sehen alle ermittelten Hosts und Endpunkte, bei denen PHP erkannt wurde, einschließlich Risikobewertung, Score und Datum der letzten Erkennung – bereit zum Scannen oder Hinzufügen als Ziel.

Derselbe Filter Tech ist auch in der Liste Targets verfügbar. So können Sie die von Ihnen hinzugefügten Anwendungen auf dieselbe Weise auf PHP eingrenzen.

Die PHP-Version wird dadurch nicht angezeigt. Sie erfahren jedoch, wo Sie suchen müssen – ein entscheidender Schritt zur Behebung.

Mit Snyk API & Web auf die Schwachstelle testen

Mit Snyk API & Web können Sie Ihre Anwendungen und APIs scannen und feststellen, ob sie von der PHP2Shell-Schwachstelle betroffen sind.

Ein Scan mit einem vollständigen Profil prüft jetzt auch auf die PHP2Shell-Schwachstelle. Außerdem können Sie ein benutzerdefiniertes Scan-Profil erstellen, das ausschließlich auf PHP2Shell testet. So können Sie schnell feststellen, ob Ihre Anwendungen betroffen sind oder die Behebung bereits erfolgt ist.

Was wir unternehmen

• Sicherheitshinweise zu beiden CVEs wurden vor der PHP-Veröffentlichung um 14:00 UTC bereitgestellt und innerhalb von etwa 30 Minuten um betroffene Versionen und Informationen zu den Fixes ergänzt.

• Ein zusätzlicher Sicherheitshinweis zu CVE-2026-115560 wurde veröffentlicht. Er wird aktualisiert, sobald weitere Details und der Fix veröffentlicht werden.

• Sicherheitshinweise der Distributionen werden importiert, sobald die jeweilige Linux-Distribution sie veröffentlicht. Ubuntu und Red Hat sind bereits verfügbar.

• Für dieses Ereignis ist ein Zero-Day-Bericht für Unmanaged- und Container-Projekte verfügbar.

Wie immer verfolgt das Sicherheitsforschungsteam von Snyk diese Offenlegung und aktualisiert die Sicherheitshinweise, sobald neue Informationen vorliegen. Wenn Sie Fragen haben, wenden Sie sich an Ihr Snyk-Account-Team oder den Support.

Referenzen

• PHP-Sicherheitshinweis: Kritische Schwachstellen mit Remote Code Execution – jetzt aktualisieren (21. Oktober 2026)

• Informativer PHP-Sicherheitshinweis: Upload-Fortschritt für Sitzungen (23. Oktober 2026)

• Snyk Unmanaged-Sicherheitshinweis zu CVE-2026-109618

• Snyk Unmanaged-Sicherheitshinweis zu CVE-2026-109619

• Alle Snyk-Sicherheitshinweise zu CVE-2026-109618 und CVE-2026-109619

• Snyk Open Source-Dokumentation

• Dokumentation zum Snyk C/C++ Unmanaged-Scanning