PHP2Shell beheben: PHP aktualisieren und Worker neu starten

Zielversionen

• PHP 8.5.12 oder neuer im Zweig 8.5
• PHP 8.4.27 oder neuer im Zweig 8.4
• PHP 8.3.36 oder neuer im Zweig 8.3
• PHP 8.2.35 oder neuer im Zweig 8.2
• Alles Ältere: auf eine dieser Versionen wechseln oder einen Anbieter-Backport bestätigen und ihn als Übergang behandeln. Die CISA rät, ungepatchtes PHP vom Netz zu nehmen, wenn kein Update möglich ist, ausdrücklich auch PHP 8.1 und älter.

Quell-Tarballs und Windows-Builds finden Sie auf der PHP-Downloadseite. Laut php.net haben Linux-Distributionen und LTS-Anbieter die Patches vor dem öffentlichen Release erhalten, daher ist das Distributionspaket oft der richtige Weg. Derselbe Hinweis sagt, das ehrenamtliche Remi-Repository (rpms.remirepo.net) habe die Updates am 21. Oktober nicht, und rät dessen Nutzern zu Distributionspaketen oder eigenem Build.

Debian, Ubuntu und andere apt-Systeme

Debian hat Fixes veröffentlicht: DLA-4848-1 (Debian LTS) für Debian 12 bookworm, php8.2 8.2.35-1~deb12u1, und DSA-6574-1 für Debian 13 trixie, php8.4 8.4.27-1~deb13u1. Der Security-Tracker führt die Builds der Basis-Suite (bookworm php8.2 8.2.32-1~deb12u1, trixie php8.4 8.4.24-1~deb13u1) als verwundbar; der Fix kommt also nur an, wenn die Security-Suite in Ihren Paketquellen steht. Am 22. Oktober führte der Tracker testing (forky) php8.4 8.4.26-1 weiterhin als verwundbar.

Aktualisieren Sie die Metadaten und installieren Sie die tatsächlich veröffentlichten PHP-Pakete. Die Namen folgen dem Minor-Zweig (php8.3-fpm, php8.3-cli, php8.3-common sowie das Apache-Modulpaket bei mod_php). Liegt die Kandidatenversion noch unter dem Fix, warten Sie auf die Distribution, nicht auf eine fehlende Option.

sudo apt-get update
apt-cache policy php8.3-cli php8.3-fpm php8.3-common
sudo apt-get install --only-upgrade php8.3-cli php8.3-fpm php8.3-common
php8.3 -v
# Web SAPI, not just the CLI:
php-fpm8.3 -v
sudo systemctl restart php8.3-fpm
# If Apache loads mod_php, restart Apache as well:
sudo systemctl restart apache2

RHEL, Alma, Rocky, Fedora: dnf oder yum

sudo dnf clean expire-cache
sudo dnf update php php-cli php-fpm php-common
php -v
php-fpm -v
sudo systemctl restart php-fpm
# mod_php under httpd:
sudo systemctl restart httpd

Docker und andere Images

Neu bauen und neu ausrollen. Ein neues Basis-Image zu ziehen, bewirkt nichts, bis der Workload, der Verkehr bedient, ersetzt ist. Offizielle Image-Tags folgen meist der PHP-Version; prüfen Sie auf Docker Hub, ob der Tag existiert, bevor Sie ihn festlegen. Google Clouds Hinweis zu Cloud Run und GKE ist derselbe: das ausgerollte Image neu bauen, außer bei einem serverlosen Basis-Image, das Google laut eigener Aussage selbst ersetzt.

FROM php:8.3.36-fpm
# or: php:8.3.36-apache, php:8.4.27-fpm, php:8.2.35-fpm, php:8.5.12-cli

# then, on the host:
# docker pull php:8.3.36-fpm
# docker build -t your-app:php2shell-fix .
# redeploy and confirm the running container's PHP version

cPanel

1. Aktualisieren Sie cPanel selbst, damit EasyApache einen gepatchten PHP-Build anbietet. Menüs ändern sich; maßgeblich ist die cPanel-Dokumentation.
2. Öffnen Sie in WHM EasyApache 4 und stellen Sie eine PHP-Version auf oder über dem Fix des Zweigs bereit. Im MultiPHP Manager weisen Sie Domains eine PHP-Version zu.
3. Nehmen Sie öffentlich erreichbare Domains von Handlern mit PHP 8.1 oder älter, sofern Ihr Anbieter nicht bestätigt hat, dass der Build den Backport enthält.
4. Starten Sie Apache und PHP-FPM über WHM neu, prüfen Sie die PHP-Version einer Domain und entfernen Sie temporäre Testseiten.

Plesk

1. Installieren Sie Plesk- und Systempaket-Updates. Den aktuellen Klickpfad beschreibt die Plesk-Dokumentation.
2. Prüfen Sie unter Tools & Einstellungen die Updates und die Liste der PHP-Handler. Die PHP-Einstellungen der Domain zeigen, welche Version ein Abonnement tatsächlich nutzt.
3. Wählen Sie einen gepatchten Handler (8.2.35, 8.3.36, 8.4.27 oder 8.5.12 oder einen geprüften Anbieter-Build). Wenden Sie ihn zuerst auf öffentliche Websites an.
4. Starten Sie den von Plesk genutzten PHP-Dienst neu und prüfen Sie die Version an der Domain, nicht nur am Panel-Host.

宝塔面板 (BT Panel)

Laut 宝塔-Hinweis vom 22. Oktober 2026 haben die Linux- und Windows-Panels 8.2.35, 8.3.36, 8.4.27 und 8.5.12 synchronisiert. Die nur für Linux angebotenen Pakete 7.4.34, 8.0.31 und 8.1.35 sind 宝塔-Builds, keine Releases des PHP-Projekts. Klickpfad und die unvollständige Windows-Einstellung stehen auf der BT-Panel-Seite.

mod_php im Vergleich zu PHP-FPM

Beide stehen auf der Risikoliste des PHP-Projekts. mod_php gilt als höchstes Risiko, weil der demonstrierte Pfad ohne Authentifizierung vor dem Anwendungscode greift. Ein Apache-Neustart lädt mod_php neu. PHP-FPM ist ein eigener Prozess: Starten Sie jeden Pool neu (systemctl restart php8.3-fpm oder die entsprechende Unit) und bedenken Sie, dass Pools eine eigene Binärdatei festlegen können. php im PATH Ihrer Shell kann ein anderer Build sein als der Pool. FrankenPHP, php-cgi und LiteSpeed nennt PHP als Webanfragen bedienend und damit betroffen; folgen Sie deren Upgrade-Anleitungen, statt anzunehmen, ein apt-Paket php-fpm decke sie ab.

Vorläufige Maßnahmen, laut PHP unvollständig

Nutzen Sie diese nur als Übergang, übernommen aus dem php.net-Hinweis. Sie verringern bestimmte Pfade und machen einen Host nicht sicher. Setzen Sie sie in php.ini oder in einer Pool- bzw. Apache-Einstellung auf Admin-Ebene (php_admin_value). ini_set() und verzeichnisweise .user.ini greifen laut PHP für den Session-Upload-Pfad zu spät.

CVE-2026-109618

• memory_limit=-1, so festgelegt, dass die Anwendung kein endliches Limit mehr setzen kann. Laut PHP entfällt damit der steuerbare Speicherlimit-Fehler, ein zugrunde liegender Allokationsfehler kann den Fehler aber weiterhin erreichen.
• Ein niedriges post_max_size. PHP empfiehlt 8M ohne Uploads und 32M mit Uploads, wobei upload_max_filesize unter post_max_size bleibt.
• Grenzen für die Anfragegröße am Webserver oder Proxy, auch für Anfragen ohne brauchbares Content-Length. PHP nennt dekodierte Anfragegröße, Anzahl der Eingabefelder, Multipart-Teile, Header und Verschachtelungstiefe.
• Ein Container- oder cgroup-Limit als Verfügbarkeitsgrenze, die den betroffenen Worker beendet. PHP rät davon ab, RLIMIT_AS oder RLIMIT_DATA zu verwenden, weil diese den verwundbaren Allokationsfehler auslösen können.

CVE-2026-109619

• session.upload_progress.enabled=0, danach jeden Worker neu starten. Laut PHP blockiert das die bestätigten Session-Pfade, nicht andere Varianten.
• Nur bei PHP 8.5: fatal_error_backtraces=0, danach neu starten. Laut PHP blockiert das nur den bestätigten Fatal-Backtrace-Pfad.
• Ungültige oder veraltete anfragebezogene Einstellungen entfernen, die vor der Initialisierung Diagnosen ausgeben. Fehler mit error_reporting, display_errors oder @ abzuschalten, schließt die Lücke nicht.
• Fatale Fehler und Zeitüberschreitungen beheben, die ein Angreifer erreichen kann, auch in Callbacks und beim Aufräumen nach Uploads oder Importen. So formuliert es das Projekt; es ist ein Härtungshinweis, keine Aussage, dass fehlerfreier Anwendungscode FPM sicher macht.

Web Application Firewalls

Die CISA sagt, eine Web Application Firewall könne bis zum Update einen gewissen Schutz bieten. Cloudflare sagt, verwaltete Regeln für dieses Problem seien ab dem 21. Oktober 2026, 03:02 UTC, für Kunden mit kostenlosen und kostenpflichtigen WAF-Tarifen aktiv gewesen, noch unter Embargo mit der PHP Foundation und anderen entwickelt, und Kunden sollten trotzdem patchen. Eine Regel kann umgangen werden; Cloudflare beobachtete selbst, wie Angreifer Payloads anpassten. Behalten Sie die WAF, aber nutzen Sie sie nicht als Fix.

Nach dem Upgrade

• Prüfen Sie die Version an der SAPI, die HTTP-Anfragen beantwortet, und starten Sie sie neu. Expel und die University of Toronto betonen beide den Neustart.
• Priorisieren Sie öffentlich erreichbare Systeme, dann alles, was nicht vertrauenswürdige Uploads oder Importe verarbeitet, dann Appliances. Das britische NCSC und das Canadian Cyber Centre sagen beide, dass Drittprodukte mit eingebettetem PHP eigene Herstellerupdates brauchen.
• War ein Host exponiert und konnte nicht schnell gepatcht werden, rät die CISA, nach PHP-Workern zu suchen, die Shells starten oder Werkzeuge herunterladen. Das britische NCSC rät, vor dem Vertrauen in einen exponierten, aktualisierten Host nach Hintertüren zu suchen. Eine geprüfte Liste von Indikatoren können wir dem nicht hinzufügen.
• Die im britischen Hinweis verlinkten NCSC-NL-Notizen sind eine Ausgangsinventur von Produkten, keine Bescheinigung, dass ein nicht gelistetes Produkt unbedenklich ist.