PHP2Shell: Zehn Tage nach den Patches. Ist Ihre Website wirklich aktualisiert?

Kurz gesagt

Die PHP-Lücken vom 21. Oktober werden inzwischen aktiv ausgenutzt. Sicher sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 oder ein gleichwertiges Update Ihres Anbieters. Fragen Sie schriftlich nach, ob das Update auf Ihren Servern angekommen ist, und lassen Sie auf Einbruch prüfen.

Was ist passiert?

PHP ist die Sprache, in der ein großer Teil aller Websites läuft, darunter WordPress, TYPO3 und die meisten kleinen Onlineshops. Am 21. Oktober hat das PHP-Projekt zwei Lücken geschlossen, über die ein Angreifer ohne Passwort fremden Code auf dem Webserver ausführen kann. Seit dem 26. Oktober führt die US-Behörde CISA beide Lücken als aktiv ausgenutzt. Am 23. Oktober kam eine dritte, deutlich seltenere Lücke hinzu, für die es bisher nur eine Schutzeinstellung gibt.

Was bedeutet das?

Bei kleinen Betrieben liegt die Website meist bei einer Agentur oder einem Hoster, die Firewall beim Systemhaus. Im Haus weiß oft niemand, welche PHP-Version läuft. Genau dort bleiben Lücken offen. Ein Update von WordPress oder Plugins hilft nicht: Entscheidend ist PHP selbst auf dem Server.

Was Sie jetzt tun können

1. Liste machen: Website, Shop, Kundenportal, Nextcloud, Firewall, Speichergerät. Zu jedem: Wer betreibt es?
2. Schriftlich anfragen. Vorlage: „Bitte bestätigen Sie, dass auf unseren Systemen CVE-2026-109618 und CVE-2026-109619 geschlossen sind. Nennen Sie die PHP-Version, die der Webserver tatsächlich nutzt, und das Datum des Updates.“
3. Die richtige Version prüfen. Maßgeblich ist das PHP, das die Webseite ausliefert, nicht das auf der Kommandozeile. Beide können verschieden sein. Prüfen lässt es sich im Kundenmenü des Hosters, über die Paketversion von PHP-FPM bzw. mod_php oder kurzzeitig über eine phpinfo()-Seite, die danach sofort gelöscht wird.
4. Backports beachten. Linux-Pakete tragen oft eine eigene Versionsnummer. Dann im Sicherheitshinweis der Distribution nachsehen (Ubuntu, Debian, Red Hat).
5. Container und Geräte: Docker-Abbilder mit PHP neu bauen. Für Firewall und NAS die Herstellerseite auf ein Update prüfen.
6. Dritte Lücke: session.upload_progress.enabled=0 setzen lassen, bis das nächste PHP-Update erscheint.
7. Auf Einbruch prüfen lassen: unbekannte PHP-Dateien im Webverzeichnis, ungewöhnliche Uploads in den Protokollen seit dem 21. Oktober. Ein Patch schließt die Tür, er wirft niemanden hinaus, der schon drin ist.

Häufige Fragen

Reicht das WordPress-Update? Nein. Die Lücke steckt in PHP, nicht in WordPress. Wir haben keinen eigenen Server. Sind wir sicher? Wahrscheinlich hat Ihr Hoster aktualisiert. Lassen Sie es sich trotzdem bestätigen. Was, wenn kein Update möglich ist? Das BSI empfiehlt dann, eine Trennung vom Internet zu erwägen. Kein Workaround schützt vollständig.

Quellen

• php.net: Security advisory, Critical remote code execution vulnerabilities (21. Oktober 2026)
• php.net: Informational advisory, Session upload progress (23. Oktober 2026)
• BSI: Cybersicherheitswarnung PHP, Version 1.2 (22. Oktober 2026)
• CISA: Known Exploited Vulnerabilities Catalog (Aufnahme 26. Oktober 2026)

Stand: 31. Oktober 2026. Ersetzt keine Prüfung im Einzelfall. Transparenz: Diese Einordnung ist KI-generiert mit menschlicher Prüfung, gekennzeichnet nach Art. 50 der europäischen KI-Verordnung. Auswahl, Quellenprüfung und Freigabe: Schoonnect.