Nach dem Patchen: nachweisen, dass der Fix läuft

Ein aktualisiertes Paket reicht erst, wenn jeder PHP-Worker neu gestartet ist. So prüfen Sie die laufende Version bei FPM, Apache und Containern.

Warum die installierte Version nicht reicht

Ein Paket-Update ersetzt Dateien auf der Platte. PHP-FPM-Master, Apache mit mod_php und LiteSpeed behalten den alten Code im Speicher, bis sie neu starten. Auf der Kommandozeile meldet der Server dann die neue Version und beantwortet Anfragen trotzdem noch mit der alten.

1. Jeden PHP-Worker neu starten

sudo systemctl restart php8.3-fpm     # jede Version, die Sie betreiben: php8.2-fpm, php8.4-fpm …
sudo systemctl restart apache2        # mod_php; unter RHEL httpd
sudo systemctl restart lsws           # LiteSpeed

Mehrere PHP-Versionen nebeneinander sind bei Panels wie cPanel und Plesk üblich. Starten Sie jede neu, die eine Website ausliefert.

Bei Containern muss das Image auf dem behobenen Tag neu gebaut und jeder laufende Container ersetzt werden. Ein Neustart des alten Containers bringt das alte PHP zurück.

2. Die Webseite fragen, welche Version läuft

Legen Sie im Web-Root einer Website eine temporäre Datei an:

<?php echo PHP_VERSION, ' ', PHP_SAPI;

Rufen Sie sie im Browser auf, lesen Sie die Ausgabe ab und löschen Sie die Datei danach. Erwartet wird etwa 8.3.36 fpm-fcgi. Bei einem Paket der Distribution kann die Nummer niedriger bleiben; bestätigen Sie den Fix dann im Changelog des Pakets:

apt changelog php8.3-fpm | grep -E 'CVE-2026-10961[89]'
rpm -q --changelog php-fpm | grep -E 'CVE-2026-10961[89]'

3. Die sinnvollen Einstellungen behalten

Das PHP-Projekt empfiehlt, session.upload_progress.enabled = 0 auch nach dem Patchen beizubehalten, wenn Sie den Upload-Fortschritt nicht nutzen. Auf den meisten Websites kostet das nichts.

4. Die Logs ansehen, mit Vorsicht

Schalten Sie log_errors mit error_reporting = E_ALL ein und lesen Sie die Logs von PHP und Webserver aus den Tagen vor dem Patch: abgestürzte Worker, Speicherfehler direkt beim Start einer Anfrage, ungewöhnliche Uploads.

Saubere Logs sind kein Beweis

Die Advisories berichten nicht von Angriffen in freier Wildbahn. Ein Angriff auf diese Lücken kann allerdings stattfinden, bevor PHP etwas schreibt. Ein ruhiges Log zeigt also nicht, dass nichts passiert ist. Wenn Sie echte Anzeichen einer Kompromittierung sehen, ziehen Sie einen Incident-Response-Dienstleister hinzu; Forensik bieten wir nicht an.

Fertig

Mit PHP2Shell sind Sie fertig, wenn jeder Server und jede PHP-Version, die eine Website ausliefert, von der Webseite aus einen behobenen Build meldet. Notieren Sie Datum und Versionen; Kunden und Prüfer fragen danach.

Zuletzt geprüft am 22. Oktober 2026.