Sind Sie betroffen?
Ja. Jeder Build von PHP 7.4 ist betroffen, solange der Backport nicht eingespielt wurde. Beide Lücken stecken in PHP selbst, also ist jede Website auf dem Server angreifbar, egal was sie ausführt.
Die Ausnahme ist eine Distribution oder ein Anbieter, der das eigene 7.4-Paket gepatcht hat. Ubuntu 20.04 und Debian 11 haben PHP 7.4 ausgeliefert, RHEL 8 bietet es als AppStream-Modul an. Diese Anbieter patchen es innerhalb ihrer eigenen Supportzeiträume, manche nur in bezahlten Angeboten wie Ubuntu Pro. Kommt Ihr Paket von dort, sagt Ihnen die Sicherheitsmeldung zu beiden CVE-Nummern, ob Sie abgesichert sind. Die Versionsnummer lautet weiterhin 7.4.
Der offizielle Fix und seine Grenze
PHP 7.4 hat am 28. November 2022 sein Supportende erreicht. Ein 7.4-Release für PHP2Shell wird das PHP-Projekt nicht veröffentlichen.
Stattdessen hat das PHP-Projekt im php-src-Repository einen minimalen Quellcode-Zweig veröffentlicht: PHP-7.4-CVE-2026-109618-109619. Er enthält die beiden Fixes und sonst nichts.
Ein Quellcode-Zweig ist kein Paket
Um ihn zu nutzen, kompilieren Sie PHP selbst, mit denselben Erweiterungen und Optionen wie Ihr aktueller Build, und das bei jeder künftigen Lücke erneut. Für die meisten Websites ist das unrealistisch. Der Zweig richtet sich an Distributionen und Anbieter.
Kostenlose Auswege, nach Aufwand sortiert
1. Prüfen, ob Ihr Paket schon gepatcht ist. Unter Ubuntu oder Debian:
php -v
apt changelog php7.4-fpm | grep -E 'CVE-2026-10961[89]'
Tauchen beide Nummern auf, starten Sie PHP neu. Dann sind Sie gegen diese beiden Lücken abgesichert:
sudo systemctl restart php7.4-fpm
2. Auf einen unterstützten Zweig wechseln. 8.3.36 und 8.4.27 schließen PHP2Shell und werden bis 2027 bzw. 2028 unterstützt. Von 7.4 auf 8.x ist es eine echte Migration. PHP 8.0 hat so viel entfernt und geändert, dass alte Plugins und Bibliotheken oft nicht mehr laufen. Testen Sie zuerst auf einer Kopie und wechseln Sie auf 8.3, nicht auf 8.1 oder 8.2. Die Schritte stehen auf PHP 8.3.
3. Bei Shared Hosting stellen Sie die PHP-Version im Kundenmenü auf 8.3 oder neuer und prüfen danach, ob die Änderung greift. Welche Fragen Sie Ihrem Hoster stellen sollten, steht in der Einschätzung.
Wenn Sie heute nicht upgraden können
Die offiziellen Übergangseinstellungen gelten auch für 7.4. Sie verkleinern die Angriffsfläche, machen den Server aber nicht sicher:
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M ; 32M bei Datei-Uploads
php_admin_value[upload_max_filesize] = 4M
php_admin_value[max_input_nesting_level] = 16 ; Standard 64; senken
php_admin_flag[session.upload_progress.enabled] = off
php_admin_flag[log_errors] = on
php_admin_value[error_reporting] = E_ALL
Setzen Sie die Werte in der php.ini oder im FPM-Pool, nicht in der .user.ini, und starten Sie alle Worker neu. Begrenzen Sie zusätzlich die Anfragen am Proxy. Setzen Sie kein RLIMIT_AS und kein RLIMIT_DATA. Die Begründung für jede Zeile finden Sie auf der Startseite.
Wenn Sie Hilfe brauchen
- Erweiterter Support. Anbieter wie TuxCare, HeroDevs und Zend verkaufen gepatchte Builds alter PHP-Versionen. HeroDevs hat beide CVEs für seine Builds von 7.4, 8.0 und 8.1 bestätigt. Zend und TuxCare hatten das bei unserer Prüfung auf ihren eigenen Seiten nicht getan. Vergleich unter Alte PHP-Versionen.
- Ein geplanter Wechsel auf 8.3. Den Umfang klären wir mit Ihnen, schriftlich und auf Rechnung.
Zuletzt geprüft am 22. Oktober 2026.