PHP2Shell: Kritische PHP-Lücken CVE-2026-109618 und CVE-2026-109619

Im PHP-Kern stecken zwei kritische Sicherheitslücken, bekannt als PHP2Shell. Angreifer können darüber ohne Anmeldung Schadcode auf Webservern ausführen. Details sind schon vor dem Patch durchgesickert, inzwischen kursiert sogar ein öffentlicher Proof of Concept. Heute ist deshalb kein normaler Patch-Tag.

Das Wichtigste in Kürze

• Was: Zwei Lücken im PHP-Kern (CVE-2026-109618, CVE-2026-109619), die Remote Code Execution ermöglichen
• Schwere: Kritisch, CVSS 9.2
• Patch: Heute, 21.10.2026, 16:00 Uhr MESZ, nur für PHP 8.2 bis 8.5
• Exploit: Öffentlicher PoC auf GitHub, breite Angriffe sind zu erwarten
• Übergangslösung: session.upload_progress.enabled abschalten (inoffiziell)

Wer ist betroffen?

Jeder, der PHP auf einem erreichbaren Server betreibt. Das betrifft auch WordPress, Shopware, Magento, TYPO3 und viele Kundenportale. Die Lücke liegt in PHP selbst. Ein Update des CMS oder der Plugins hilft nicht.

Am größten ist das Risiko bei PHP 8.1 und älter. Für diese Versionen gibt es keinen offiziellen Fix. Laut Auswertungen laufen weltweit rund 884.000 erreichbare Server mit solchen Versionen.

Der öffentliche PoC

Auf GitHub ist ein Proof of Concept für PHP2Shell aufgetaucht. Laut Beschreibung steckt die Lücke in der Session-Upload-Fortschrittsanzeige von PHP (session.upload_progress). Diese Funktion ist standardmäßig aktiv. Ein präparierter Datei-Upload per POST-Anfrage reicht, um Speicher im PHP-Prozess zu manipulieren und Befehle auf dem Server auszuführen. Eine Anmeldung ist nicht nötig.

Was das für Sie bedeutet:

• Die Hürde für Angreifer sinkt. Mit öffentlichem Code können auch weniger versierte Angreifer automatisiert scannen.
• Es gibt einen konkreten Hebel. Wer session.upload_progress.enabled abschaltet, entzieht dem beschriebenen Angriff nach aktuellem Stand die Grundlage.
• Der PoC ist nicht offiziell bestätigt. PHP hat die Details noch nicht veröffentlicht. Führen Sie fremden Exploit-Code und die mitgelieferten Skripte niemals ungeprüft auf Produktivsystemen aus, sondern höchstens in einer isolierten Testumgebung.

Was ist zu tun?

1. Heute alle PHP-Systeme erfassen: eigene Server, Container, Hosting-Pakete, Agentur- und SaaS-Systeme.
2. Upload Progress sofort abschalten: wo die Funktion nicht gebraucht wird, also fast überall.
3. Hoster und Dienstleister fragen: Wann wird gepatcht? Lassen Sie sich das bestätigen.
4. Ab 16:00 Uhr updaten: danach PHP-FPM oder Apache neu starten und die Version prüfen.
5. Altversionen absichern: Gibt es keinen Backport Ihrer Linux-Distribution, das System vom Internet trennen oder vorübergehend offline nehmen.

# Welche PHP-Version läuft?
php -v

# Läuft PHP-FPM in einer anderen Version?
systemctl list-units --type=service | grep -i php

# Ist Upload Progress aktiv? (Standard: 1 = an)
php -i | grep session.upload_progress.enabled

# Nach dem Update: Dienst neu starten (Version anpassen)
sudo systemctl restart php8.3-fpm

So schalten Sie die Funktion bis zum Patch ab. Die Einstellung ersetzt das Update nicht, sie verkleinert nur die Angriffsfläche. Sie betrifft lediglich Fortschrittsbalken bei Datei-Uploads, die kaum eine Anwendung nutzt.

; php.ini (mod_php), danach Apache neu starten
session.upload_progress.enabled = 0

; PHP-FPM: in jedem Pool, z. B. /etc/php/8.3/fpm/pool.d/www.conf, danach reload
php_admin_flag[session.upload_progress.enabled] = off

Die europäische Cybersicherheitsbehörde CERT-EU rät zusätzlich, nicht patchbare Systeme vom Netz zu nehmen. Einige Dienste wie easybill und wiki.gg haben das bereits getan.

Nach dem Update lohnt ein Blick auf den Server: Startet ein PHP-Prozess plötzlich Shells oder lädt Dateien nach, oder liegen neue PHP-Dateien im Webroot, sollten Sie von einem Angriff ausgehen.

Mögliche Folgen

Ein erfolgreicher Angriff gibt dem Angreifer Kontrolle über den Webserver. Typische Folgen:

• Datendiebstahl: Kundendaten, Passwörter, Zugangsdaten. Dazu kommt die DSGVO-Meldepflicht.
• Manipulierte Shops: Schadcode im Checkout liest Zahlungsdaten mit.
• Hintertüren: Versteckte Zugänge bleiben auch nach dem Patch bestehen.
• Weitere Angriffe: Der Webserver wird zum Sprungbrett ins interne Netz, bis hin zu Ransomware.

Unsere Einschätzung

PHP2Shell ist ernst. PHP ist extrem verbreitet, der Angriff braucht keine Anmeldung und es gibt öffentlichen Exploit-Code. Bei der letzten großen PHP-Lücke 2024 gab es Angriffe innerhalb von 24 Stunden, damals ohne vorab geleakte Details.

Die wichtigste Frage für heute ist organisatorisch: Wer darf ein System notfalls vom Netz nehmen? Ein paar Stunden Ausfall sind fast immer günstiger als ein kompromittierter Server.

Sie brauchen Unterstützung bei Bestandsaufnahme oder Prüfung eines Servers? Sprechen Sie uns an.