PHP2Shell: PHP-RCE-Lücken auf dem Server prüfen und patchen

PHP2Shell: PHP-RCE-Lücken auf dem Server prüfen und patchen

Am 21. Oktober 2026 hat das PHP-Projekt 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht, um zwei Lücken in PHP selbst zu schließen, die unter dem Spitznamen PHP2Shell laufen. Beide erlauben es einer Anfrage von jemandem, der nicht angemeldet ist, Code als PHP-Worker auszuführen. Der Fehler steckt in der Laufzeitumgebung, nicht in WordPress, Drupal oder Joomla, ein Update des CMS oder seiner Plugins schließt ihn also nicht. Diese Anleitung zeigt, wer betroffen ist, wie Sie einen Server mit einem Befehl prüfen, was Sie heute tun, wenn Sie noch nicht upgraden können, und wie Sie sicher upgraden.

Was die beiden Lücken sind

• CVE-2026-109618, Speicherkorruption bei Speichermangel - schlägt eine Speicherzuweisung fehl, kann PHP eine Anfrage abbrechen, während ihre internen Daten erst halb eingerichtet sind, und die anschließende Aufräumroutine vertraut diesen kaputten Daten. Eine präparierte Multipart-Anfrage kann das sogar innerhalb Ihrer konfigurierten Größenlimits auslösen.
• CVE-2026-109619, veralteter globaler Zustand - Zustand, der zu einer Anfrage gehört, kann den Speicher dahinter überleben. Die nächste Anfrage, die derselbe Worker bedient, kann diesen freigegebenen Speicher nutzen, bevor er zurückgesetzt wird (ein Use-after-free). Der bestätigte Weg führt über die Funktion Session Upload Progress und fatale Fehler.

Beide sind nach CVSS 4.0 mit 9.2 (kritisch) bewertet. Laut der PHP-Ankündigung wurde während der Untersuchung ein funktionierender Exploit gebaut, und das Risiko ist am höchsten bei Apache mit mod_php, wo der Angriff vor jedem Anwendungscode läuft. Innerhalb weniger Tage erschienen mehrere öffentliche Proof-of-Concept-Exploits; Rapid7 berichtet, dass jeder nur für eine Kombination aus Betriebssystem, PHP-Version und Webserver funktioniert, und hat Ausnutzungsversuche beobachtet. Behandeln Sie es als Notfall-Patch.

Wer betroffen ist

Jede PHP-Installation, die Webanfragen bedient: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das umfasst fast jeden Server mit WordPress, WooCommerce, Drupal, Joomla, Magento, Laravel und Nextcloud.

PHP-Zweig	Betroffen	Erste gefixte Version
8.5	8.5.0 - 8.5.11	8.5.12
8.4	8.4.0 - 8.4.26	8.4.27
8.3	8.3.0 - 8.3.35	8.3.36
8.2	8.2.0 - 8.2.34	8.2.35
7.4, 8.0, 8.1	alle	kein Release auf php.net; Backports im Quellcode, Pakete der Distribution oder eines LTS-Anbieters
7.3 und älter	alle	kein Fix

Distributionen behalten oft die alte Versionsnummer und portieren den Fix zurück (etwa ein Debian- oder Ubuntu-Paket, das weiterhin 8.2.x anzeigt). Prüfen Sie bei paketiertem PHP daher den Security-Tracker Ihrer Distribution für das Paket, nicht nur die Nummer.

Einen Server mit einem Befehl prüfen

Speichern Sie dies als php2shell-check.php und führen Sie es mit demselben PHP aus, das Ihre Website ausliefert. Es gibt die Version aus, ob diese Version älter als der Fix ist, und die zwei Einstellungen, die die Notmaßnahmen unten ändern.

<?php
// PHP2Shell check: is this PHP build older than the October 21, 2026 fixes?
$fixed = ['8.5' => '8.5.12', '8.4' => '8.4.27', '8.3' => '8.3.36', '8.2' => '8.2.35'];
$branch = PHP_MAJOR_VERSION . '.' . PHP_MINOR_VERSION;
echo "PHP " . PHP_VERSION . " (" . PHP_SAPI . ")\n";
if (!isset($fixed[$branch])) {
    echo "Branch $branch gets no php.net release: check your distro or LTS vendor, or upgrade to 8.4.\n";
} elseif (version_compare(PHP_VERSION, $fixed[$branch], '<')) {
    echo "VULNERABLE: upgrade to {$fixed[$branch]} or later (or a distro build with the backport).\n";
} else {
    echo "Patched upstream version ({$fixed[$branch]}+).\n";
}
echo "session.upload_progress.enabled = " . (ini_get('session.upload_progress.enabled') ? 'On' : 'Off') . "\n";
echo "post_max_size = " . ini_get('post_max_size') . ", memory_limit = " . ini_get('memory_limit') . "\n";

php php2shell-check.php

Ausgabe geprüft am 2026-10-24 in den offiziellen php-Docker-Images:

PHP 8.3.30 (cli)
VULNERABLE: upgrade to 8.3.36 or later (or a distro build with the backport).
session.upload_progress.enabled = On
post_max_size = 8M, memory_limit = 128M

PHP 8.4.27 (cli)
Patched upstream version (8.4.27+).

PHP 7.2.34 (cli)
Branch 7.2 gets no php.net release: check your distro or LTS vendor, or upgrade to 8.4.

Das php der Kommandozeile kann ein anderer Build sein als der hinter Ihrer Website. Für die Webseite prüfen Sie php-fpm -v (oder php-fpm8.3 -v unter Debian und Ubuntu), oder Sie legen das Skript für eine einzige Anfrage ins Web-Root und löschen es sofort danach.

Wenn Sie heute nicht upgraden können: Notmaßnahmen

Das PHP-Team stellt klar, dass es keine vollständige Abhilfe gibt und ein Update die einzige sichere Wahl ist. Diese Einstellungen verkleinern die Angriffsfläche, während Sie das Update planen. Setzen Sie sie dort, wo die Anwendung sie nicht überschreiben kann - in php.ini oder im FPM-Pool mit php_admin_value -, denn ini_set() und .user.ini greifen zu spät. Starten Sie danach jeden Worker neu.

; FPM pool, e.g. /etc/php/8.3/fpm/pool.d/zz-php2shell.conf (the [www] section of your pool)
[www]
php_admin_value[session.upload_progress.enabled] = 0
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 30M

php-fpm8.3 -t && systemctl restart php8.3-fpm

Wir haben diese Pool-Datei mit php-fpm -t auf PHP 8.4 geprüft (configuration test successful). Was jede Zeile bewirkt:

• session.upload_progress.enabled = 0 blockiert den bestätigten Weg von CVE-2026-109619, nicht jede Variante. Schalten Sie es ab, sofern kein Upload-Fortschrittsbalken davon abhängt.
• post_max_size von 8M ohne Uploads oder 32M, wenn die Website Uploads annimmt, mit upload_max_filesize darunter, wie das PHP-Team empfiehlt. Begrenzen Sie die Anfragegröße zusätzlich in nginx (client_max_body_size 32m;) oder Apache (LimitRequestBody).
• Nur unter PHP 8.5: zusätzlich fatal_error_backtraces = 0 setzen.
• PHP schlägt außerdem ein vom Admin gesetztes memory_limit = -1 vor, damit das Speicherlimit selbst nicht zum Auslösen von CVE-2026-109618 genutzt werden kann. Tun Sie das nur mit einem Speicherlimit per Container oder cgroup um PHP herum, sonst kann eine einzige böse Anfrage den gesamten RAM des Servers belegen. Verwenden Sie dafür nicht RLIMIT_AS oder RLIMIT_DATA: Sie können die Lücke auslösen.

Fehler zu verbergen (display_errors, error_reporting, @) hilft nicht, und ein leeres Fehlerlog beweist nicht, dass ein Server nicht angegriffen wurde.

So upgraden Sie

1. Paketiertes PHP (Debian, Ubuntu, RHEL, AlmaLinux). Installieren Sie das Sicherheitsupdate (apt update && apt upgrade oder dnf upgrade 'php*') und starten Sie danach PHP-FPM oder Apache neu, denn laufende Worker behalten den alten Code. Prüfen Sie, dass das Changelog des Pakets CVE-2026-109618 nennt.
2. Docker-Images. Bauen Sie mit docker compose build --pull auf einem gefixten Tag neu (php:8.4-fpm zeigt jetzt auf 8.4.27) und erstellen Sie die Container neu. Ein laufender Container behält das alte PHP, bis er ersetzt wird.
3. PHP 7.4 - 8.1. Nutzen Sie das zurückportierte Paket Ihres Anbieters oder wechseln Sie auf 8.4. PHP 7.3 und älter bekommt nie einen Fix: Stellen Sie die Website hinter eine Allow-List oder ein VPN, bis sie migriert ist.
4. Nach dem Upgrade führen Sie das Prüfskript erneut aus und durchsuchen das Webserver-Log nach ungewöhnlichen Multipart-POST-Anfragen und Abstürzen von PHP-Workern seit dem 21. Oktober.

Wenn Sie Unterstützung brauchen: Die Managed Server-Administration deckt solche Patches ab, und unsere Anleitung zum Cloud-Server für WordPress zeigt ein PHP-FPM-Setup, das diese Einstellungen im Pool hält. Machen Sie vor dem Upgrade einer produktiven Website einen Snapshot: Backup und Wiederherstellung einer VM erklärt, wie.

Was wir getan haben

In derselben Woche haben wir jeden DCXV-Dienst mit PHP geprüft und die Maßnahmen aus dieser Anleitung umgesetzt. Kundenserver werden von ihren Eigentümern verwaltet: Wenn Sie PHP auf einem Cloud- oder dedizierten Server von DCXV betreiben, führen Sie die Prüfung oben noch heute aus. Ein neuer Cloud-Server erhält beim ersten apt upgrade die aktuellen Pakete.

Quellen (geprüft am 2026-10-24): die Ankündigung der PHP-8.x-Sicherheitsreleases vom 21. Oktober 2026, die PHP-Advisories GHSA-w8hw-w9fx-j79w und GHSA-6wmf-4rv5-p3rp sowie die Analyse von Rapid7.