Versionen und Fixes
Bin ich betroffen?
Wahrscheinlich, wenn Sie PHP hinter einem Webserver betreiben und Ihre Version unter 8.2.35, 8.3.36, 8.4.27 oder 8.5.12 liegt. Beide Lücken stecken in PHP selbst, es spielt also keine Rolle, welches CMS oder Framework Sie nutzen. Tragen Sie Ihre Version in die Prüfung ein, oder nutzen Sie die Einordnung, wenn Sie nicht sicher sind, wer PHP für Sie betreibt.
Welche Versionen sind behoben?
PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Für PHP 8.1 und älter gab es kein Release. Das PHP-Projekt hat nur für 7.4, 8.0 und 8.1 Backport-Zweige im Quellcode veröffentlicht. Die vollständige Tabelle steht unter Status.
Hosting, WordPress und WAFs
Ich nutze Shared Hosting. Muss ich etwas tun?
PHP patcht Ihr Hoster. Fragen Sie ihn, welcher PHP-Build Ihre Website ausliefert und wann die Worker neu gestartet wurden, und stellen Sie im Panel auf eine neuere Version um, wenn Ihre Website damit läuft. Die Schritte und die drei Fragen stehen in der Anleitung für Shared Hosting.
Ist WordPress selbst verwundbar?
Nein. Beide Lücken stecken in PHP. WordPress.org schreibt, dass kein WordPress-Update nötig oder geplant ist und dass Sie PHP aktualisieren sollen. Siehe PHP-Version prüfen.
Hilft eine WAF oder Cloudflare?
Nein. Laut PHP-Projekt gibt es keine vollständige Abhilfe, und das Upgrade ist der einzige sichere Weg. Cloudflare berichtet, dass Angreifer ihre Payloads angepasst haben, um an WAF-Regeln vorbeizukommen. Eine WAF kann eine zusätzliche Schutzschicht sein, das Upgrade brauchen Sie trotzdem. Siehe die Anleitung zu WAFs.
Meine Distribution zeigt eine ältere Versionsnummer. Bin ich geschützt?
Vielleicht. Ubuntu, Debian, Red Hat und andere patchen ihre eigenen Pakete und behalten die alte Nummer. Suchen Sie im Changelog des Pakets nach beiden CVE-Nummern, wie in der Anleitung für Ihr System beschrieben: Ubuntu, Debian, RHEL.
Muss ich etwas neu starten?
Ja. Ein Paket-Update ändert nichts an PHP-Prozessen, die bereits laufen. Starten Sie PHP-FPM, Apache oder LiteSpeed neu und prüfen Sie dann die Version, die die Webseite meldet. Die Schritte stehen unter Nach dem Patchen.
Angriffe und Kompromittierung
Wird die Lücke ausgenutzt?
Sicherheitsanbieter sagen ja. Cloudflare, watchTowr und Patchstack melden Angriffsversuche. Die CISA hatte bei ihrer Veröffentlichung keine Ausnutzung beobachtet, und BSI und CERT-EU hatten keine bestätigt. Auch die Ankündigung des PHP-Projekts meldet keine Ausnutzung. Den aktuellen Stand finden Sie unter Status.
Steht sie im KEV-Katalog der CISA?
Bei unserer letzten Prüfung nicht. Am 21. Oktober 2026 stand keine der beiden CVEs im Katalog der Known Exploited Vulnerabilities. Das kann sich ändern, und wir prüfen vor jedem Update erneut. Das letzte Ergebnis steht unter Status.
Alte PHP-Versionen und Docker
Was ist mit PHP 7.4 und PHP 8.1?
Beide haben ihr Lebensende erreicht, und das PHP-Projekt bietet für beide nur einen Quellcode-Zweig an, den Sie selbst kompilieren müssten. Prüfen Sie, ob Ihre Distribution oder Ihr Panel den eigenen Build schon gepatcht hat, oder wechseln Sie auf eine unterstützte Version. Siehe PHP 7.4 und PHP 8.1.
Was ist mit PHP 5?
Das PHP-Projekt äußert sich nicht zu PHP 5. Sekundärquellen nennen es betroffen, und einen Fix von PHP selbst gibt es nicht. Behandeln Sie es als betroffen und planen Sie den Umstieg. Siehe PHP 5.
Soll ich auf PHP 8.2 wechseln?
Nur für kurze Zeit. 8.2.35 behebt beide Lücken, aber der Zweig 8.2 endet am 31. Dezember 2026. Wir empfehlen 8.4, oder 8.3, wenn etwas noch nicht so weit ist. Siehe PHP 8.2.
Spielt der Tag des Docker-Images eine Rolle?
Ja. Nutzen Sie einen Tag, der auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 zeigt, etwa php:8.4.27-fpm, und bauen und deployen Sie Ihre Container neu. RC-Tags sind nicht das behobene Release, und Tags für 8.1 und älter sind nicht gepatcht. Wer einen alten Container neu startet, hat wieder das alte PHP. Siehe die Docker-Anleitung.
Ist die PHP-Kommandozeile betroffen?
Offiziell betroffen sind diese Betriebsarten: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP und LiteSpeed. Die Kommandozeile (CLI) steht nicht auf dieser Liste. Aktualisieren Sie das Paket trotzdem: CLI und Webseite stammen meist aus derselben Installation, und php -v zeigt Ihnen, was Sie haben.
Woran erkenne ich, ob ich gehackt wurde?
Möglicherweise gar nicht. Die Advisories nennen keine Indicators of Compromise, und ein sauberes Log beweist nichts, weil ein Angriff stattfinden kann, bevor PHP etwas protokolliert. Die CISA rät, auf PHP-Worker zu achten, die Shells oder Download-Werkzeuge starten. Beginnen Sie mit Nach dem Patchen und, bei WordPress, mit Wenn Ihre Website gehackt wurde.
Abhilfen und Upgrades
Kann ich einfach session.upload_progress abschalten?
Das hilft nur gegen eine der beiden Lücken. Das PHP-Projekt nennt session.upload_progress.enabled=0 als Abhilfe für CVE-2026-109619 und nichts Vergleichbares für CVE-2026-109618. Es verkleinert die Angriffsfläche, das Upgrade brauchen Sie trotzdem. Die offiziellen vorläufigen Einstellungen stehen unter Wenn Sie noch nicht upgraden können.
Geht meine Website durch das Upgrade kaputt?
Das kann passieren, vor allem wenn Sie mehrere Versionen überspringen. Testen Sie zuerst auf einer Kopie. Die Anleitungen behandeln die häufigsten Probleme: 7.4 auf 8.4, 8.1 auf 8.4, 8.2 auf 8.4, oder siehe alle Upgrades.
Über diese Seite
Wer sind Sie, und wie verdienen Sie Geld?
Wir sind eine unabhängige Seite ohne Verbindung zum PHP-Projekt oder zu WordPress. Die Informationen zum Fix sind kostenlos. Geld verdienen wir mit optionaler bezahlter Hilfe, und jeder künftige bezahlte Link wird gekennzeichnet. Details unter Über uns und Empfehlungen.
Zuletzt geprüft am 22. Oktober 2026.