Das Wichtigste in Kürze
Am 21. Oktober 2026 hat das PHP-Projekt außerplanmäßige Sicherheitsupdates für zwei kritische Schwachstellen veröffentlicht, die unter dem Namen „PHP2Shell“ zusammengefasst werden. BSI und CERT-EU warnen und empfehlen, Systeme mit PHP unverzüglich zu identifizieren und zu aktualisieren.
- Was: Zwei Fehler im PHP-Kern (
CVE-2026-109618,CVE-2026-109619), beide mit CVSS 9,2 als kritisch eingestuft. Mögliche Folge: Remote Code Execution ohne Authentifizierung. - Wer: Jeder Server, auf dem PHP läuft – unabhängig von WordPress, TYPO3, Joomla, Shopware, Magento oder Eigenentwicklung. Endanwender-PCs sind in der Regel nicht betroffen.
- Sicher: PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 sowie gepatchte Distributionspakete. Ältere Zweige erhalten keine offiziellen Updates mehr.
- Jetzt: Inventar erstellen, patchen, Hoster und Hersteller nachfragen, Logs auf Angriffsspuren prüfen – oder uns damit beauftragen.
Bin ich betroffen? Der Kurzcheck
PHP steckt in weit mehr Systemen, als vielen Unternehmen bewusst ist. Gehen Sie diese vier Bereiche durch – wenn Sie bei einem Punkt unsicher sind, ist das bereits Grund genug für eine Analyse.
WordPress, TYPO3, Joomla, Drupal, Contao, Shopware, Magento, WooCommerce, OXID – alle laufen auf PHP. Ein CMS-Update allein hilft nicht: Die PHP-Version auf dem Server bzw. beim Hoster muss aktualisiert sein.
Intranet, Nextcloud, Moodle, Matomo, Zabbix, Roundcube, phpMyAdmin, Ticket- und Wiki-Systeme, Eigenentwicklungen aus der Fachabteilung. Gerade „interne“ Systeme werden selten gepatcht – und sind nach einem Einbruch ins Netzwerk das nächste Ziel.
Viele Firewalls, Router, NAS-Systeme, Management-Konsolen und Drucker-Server nutzen eine PHP-basierte Weboberfläche. Hier können Sie nicht selbst patchen – Sie sind auf Firmware-Updates des Herstellers angewiesen. Einzelne Hersteller haben bereits Betroffenheit bestätigt.
PHP in Docker-Images, Kubernetes-Deployments, Staging-Servern und Build-Pipelines wird oft mit fixierter Version ausgerollt. Diese Images müssen neu gebaut und neu deployt werden – ein apt upgrade auf dem Host reicht nicht.
Wenn Sie nicht sicher sagen können, auf welchen Systemen PHP in welcher Version läuft, gehen Sie von Betroffenheit aus. Eine Betroffenheitsanalyse dauert in der Regel wenige Stunden – ein Vorfall kostet Wochen.
Welche PHP-Versionen sind sicher?
Die PHP-Entwickler haben für alle aktiv unterstützten Zweige Updates veröffentlicht. Für ältere Versionen gibt es keine offiziellen Patches mehr – Linux-Distributionen wie Debian, Ubuntu, RHEL oder SUSE liefern teilweise eigene Backports für ihre Pakete aus.
| PHP-Zweig | Sichere Version | Status |
|---|---|---|
| PHP 8.5 | 8.5.12 | Gepatcht (21.10.2026) |
| PHP 8.4 | 8.4.27 | Gepatcht (21.10.2026) |
| PHP 8.3 | 8.3.36 | Gepatcht (21.10.2026) |
| PHP 8.2 | 8.2.35 | Gepatcht – Security-Support endet 31.12.2026 |
| PHP 8.1 und älter (8.0, 7.x, 5.x) | – | Kein offizieller Patch · migrieren oder abschalten |
Wer heute auf 8.2.35 aktualisiert, ist kurzfristig sicher – steht aber in zwei Monaten erneut ohne Sicherheitsupdates da. Planen Sie die Migration auf PHP 8.3 oder 8.4 jetzt mit ein, statt zweimal anzufassen.
Sofortmaßnahmen: Die ersten 48 Stunden
So gehen wir bei unseren Kunden vor – in dieser Reihenfolge:
- Inventarisieren: Alle Systeme mit PHP erfassen – Webserver, Anwendungen, Appliances, Container. Aus dem Internet erreichbare Systeme zuerst.
- Patchen: PHP auf eine sichere Version aktualisieren (Hoster, Distribution, Container-Image). Dienste neu starten – PHP-FPM, mod_php, php-cgi, FrankenPHP und LiteSpeed gelten als betroffene Laufzeitumgebungen.
- Nicht patchbare Systeme absichern: Alte PHP-Versionen oder Appliances ohne Hersteller-Update vom Internet trennen, hinter WAF/VPN legen oder temporär abschalten.
- Hoster und Lieferanten abfragen: Schriftliche Bestätigung einholen, dass Ihre Webseite, Ihr Shop und Ihre SaaS-Anwendungen gepatcht sind.
- Auf Kompromittierung prüfen: Webserver-Logs ab dem 17. Oktober auf ungewöhnliche Anfragen, unbekannte Dateien im Webroot (Webshells), neue Cronjobs und unerwartete ausgehende Verbindungen kontrollieren. Patchen allein entfernt keinen bereits eingedrungenen Angreifer.
- Dokumentieren: Für Geschäftsführung, Versicherer und ggf. NIS2-Meldepflichten festhalten, welche Systeme wann geprüft und gepatcht wurden.
So helfen wir Ihnen – konkret
Als Managed-Services-Partner für den Mittelstand und Konzerne in der DACH-Region patchen wir PHP2Shell gerade bei unseren Kunden flächendeckend. Diese Erfahrung stellen wir auch Unternehmen zur Verfügung, die bisher keinen IT-Dienstleister haben oder deren Dienstleister überlastet ist.
Wir erfassen alle PHP-Systeme in Ihrem Unternehmen – intern und extern erreichbar – und liefern eine priorisierte Liste: Was ist betroffen, was ist gepatcht, was ist kritisch.
Wir aktualisieren PHP auf Ihren Servern, koordinieren mit Hostern und Agenturen, bauen Container-Images neu und sichern nicht patchbare Systeme ab – mit Rollback-Plan und Funktionstest.
Wir prüfen, ob die Lücke vor dem Patch bereits ausgenutzt wurde: Log-Analyse, Dateisystem-Scan auf Webshells, Prüfung auf Persistenz. Bei Verdacht übernehmen wir Eindämmung und Wiederanlauf.
PHP2Shell wird nicht die letzte kritische Lücke sein. Mit unserem Managed Patch Management werden Sicherheitsupdates nach Kritikalität priorisiert und automatisiert ausgerollt – mit 24/7-Monitoring und klaren SLAs.
Häufige Fragen zur PHP-Sicherheitslücke
Was ist PHP2Shell?
Welche PHP-Versionen sind sicher?
Reicht ein WordPress-, TYPO3- oder Shop-Update?
Sind auch Endanwender-PCs betroffen?
Woher weiß ich, ob mein Unternehmen betroffen ist?
Was tun, wenn ein System bereits angegriffen wurde?
Quellen: Security-Advisory des PHP-Projekts vom 21.10.2026 (php.net), Warnmeldungen von BSI und CERT-EU, RUS-CERT. Stand dieser Seite: 23. Oktober 2026. Die Lage entwickelt sich; wir aktualisieren bei neuen Erkenntnissen.