Sind Sie betroffen?
Ja. Jeder Build von PHP 8.1 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 8.1-Paket gepatcht hat. Ubuntu 22.04 liefert PHP 8.1 aus, und Canonical pflegt es, zum Teil über Ubuntu Pro. Kommt Ihr Paket von dort, sagt Ihnen die Sicherheitsmeldung zu beiden CVE-Nummern, ob Sie abgesichert sind. Die Versionsnummer lautet weiterhin 8.1.
Der offizielle Fix und seine Grenze
PHP 8.1 hat am 31. Dezember 2025 sein Supportende erreicht. Ein 8.1-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-8.1-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:
php -v
apt changelog php8.1-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 php8.1-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 8.1 auf 8.3 müssen Sie meist nur ein paar Deprecations beheben. Testen Sie vorher Plugins und Erweiterungen. 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 8.1. 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.