Kritische Schwachstelle in Ihrer PHP-Version (PHP2Shell)

Was es ist

Am 20. und 21. Oktober 2026 wurden zwei kritische Schwachstellen direkt im Kern der Sprache PHP veröffentlicht, geführt als CVE-2026-109618 und CVE-2026-109619. In der Community hat sich dafür die Bezeichnung PHP2Shell eingebürgert. Sie erlauben es einem Angreifer, auf dem Server eigenen Code auszuführen, und zwar ohne Anmeldung und ohne jede Interaktion eines Administrators. Der Schweregrad wird mit CVSS 9,2 bewertet, also im höchsten Bereich.

Unser Scan hat bei Ihrer Website bemerkt, dass sich der Server im Header X-Powered-By mit einer PHP-Version meldet, die den Fix noch nicht enthält. Die Preisgabe der Version ist für sich genommen eine Kleinigkeit, kritisch ist hier die Version dahinter.

Warum das ein Problem ist

Nicht authentifizierte Remote-Code-Ausführung ist die schlimmste Art von Schwachstelle. Der Angreifer braucht kein Passwort und kein gültiges Konto: Es genügt, dass Ihre Website aus dem Internet erreichbar ist. Nach einer erfolgreichen Ausnutzung hat er auf dem Server dieselben Rechte wie die Anwendung selbst, kann also die Datenbank lesen, Besuchern Schadcode unterschieben, von Ihrem Server aus Spam versenden oder ihn in ein Botnetz einbinden.

Laut verfügbaren Quellen läuft die Ausnutzung in der Praxis bereits, massenhaft und automatisiert. Bei so hohem Schweregrad wird die Zeit zwischen Veröffentlichung und flächendeckendem Scannen des Internets in Stunden gemessen, nicht in Tagen.

Welche Versionen sind verwundbar

Behoben sind die Versionen 8.5.12, 8.4.27, 8.3.36, 8.2.35 und jeweils neuere innerhalb ihres Zweigs. Verwundbar ist also:

Wie finde ich meine Version heraus

Über die Kommandozeile des Servers: php -v. Beim Hosting in der Regel in der Verwaltung (cPanel „Select PHP Version“, Plesk „PHP Settings“, bzw. in den Website-Einstellungen Ihres Anbieters). Von außen verrät sie oft gerade der Header X-Powered-By:

curl -sI https://example.cz | grep -i x-powered-by

So beheben Sie es

Shared Hosting

In den meisten Fällen genügt es, in der Hosting-Verwaltung die PHP-Version auf die neueste im jeweiligen Zweig umzustellen (z. B. von 8.2.x auf das letzte 8.2) und die Anwendung kurz durchzuklicken, ob sie funktioniert. Wenn Sie diese Option nicht sehen oder unsicher sind, schreiben Sie dem Hosting-Support, dass Sie den Patch für CVE-2026-109618 benötigen.

Eigener Server (Debian / Ubuntu)

sudo apt update
sudo apt upgrade php8.3 php8.3-fpm   # Ihren eigenen Zweig einsetzen
sudo systemctl restart php8.3-fpm
php -v

Eigener Server (RHEL / AlmaLinux)

sudo dnf upgrade php php-fpm
sudo systemctl restart php-fpm
php -v

Docker

Ändern Sie das Tag im Dockerfile auf die behobene Version (z. B. php:8.3.36-fpm), bauen Sie das Image neu und deployen Sie es. Verlassen Sie sich nicht auf das gleitende Tag 8.3-fpm ohne neuen Pull, Sie könnten eine alte Schicht im Cache haben.

Wenn ein sofortiges Update nicht möglich ist

Solange Sie die behobene Version nicht haben, begrenzen Sie die Auswirkungen: Aktivieren Sie eine WAF (Cloudflare hat für diese Schwachstellenfamilie eine Regel im Managed Ruleset), sperren Sie den Zugang zur Administration per IP und prüfen Sie die Logs, ob ein Angriff nicht schon stattgefunden hat. Das ist aber nur ein vorübergehender Patch, keine Lösung.

Wie prüfe ich, dass es erledigt ist

Starten Sie nach dem Update einen neuen Scan auf vulscan.app oder prüfen Sie die Version mit php -v auf dem Server. Im Header X-Powered-By sollte keine verwundbare Version mehr erscheinen, idealerweise verbergen Sie den Header ganz (expose_php = Off in der php.ini).

Was schiefgehen kann

Der Wechsel innerhalb eines Zweigs (8.2.x auf das neueste 8.2) ist praktisch risikofrei, Korrekturen innerhalb eines Zweigs sind abwärtskompatibel. Der Sprung auf einen höheren Zweig (etwa von 8.1 auf 8.3) kann veraltete Bibliotheken oder deprecated Funktionen offenlegen, testen Sie ihn daher an einer Kopie der Website. Trotzdem ist ein Sprung auf einen höheren Zweig besser, als bei einer Version mit aktiv ausgenutzter Lücke zu bleiben.

Referenzen