PHP-Sicherheitslücken CVE-2026-109618 und CVE-2026-109619 (PHP2Shell): Welche Software betroffen ist und was jetzt zu tun ist

CVE-Monitoring und Patch-Betrieb statt Zufallsfund - WZ-IT erfasst, wo PHP in Ihrer Umgebung läuft, spielt Updates ein und prüft danach Systeme und Container. Erstgespräch buchen · Server-Audit · Nextcloud-Betrieb

Zwei Schwachstellen in PHP selbst mit CVSS 4.0 von je 9,2 betreffen nach Angaben des BSI alle PHP-Versionen bis mindestens PHP 5: CVE-2026-109618 und CVE-2026-109619, in Berichten PHP2Shell genannt. Das PHP-Projekt veröffentlicht Details und Patches am 21. Oktober 2026 um 16 Uhr deutscher Zeit. Das BSI stuft die Lage mit 3 von 4 (orange) ein: Maßnahmen müssen unverzüglich ergriffen werden.

Weil die Lücken in der Laufzeit stecken, sind voraussichtlich alle Anwendungen betroffen, die auf PHP laufen: Nextcloud, WordPress, Drupal, TYPO3, Matomo, Moodle, Shopware und viele weitere. Dieser Beitrag nennt die gängigsten, erklärt, warum ein Anwendungs-Update nicht ausreicht, und beschreibt die Schritte für den Patch-Zeitpunkt.

Inhaltsverzeichnis

• Kurz beantwortet
• Stand der Informationen
• Welche Software voraussichtlich betroffen ist
• Warum ein Anwendungs-Update nicht reicht
• Was jetzt zu tun ist
• Wenn nicht sofort gepatcht werden kann
• Veraltete PHP-Versionen
• Zeitleiste
• Verbreitete Fehlannahmen
• Stand und Methodik
• Unser Vorgehen bei WZ-IT
• Weiterführende Guides

Kurz beantwortet

Stand der Informationen

Stand 21. Oktober 2026, vor Veröffentlichung der Patches. Bekannt sind die Vorankündigung des PHP-Projekts (zwei Lücken, jeweils CVSS 4.0 9,2, Release am 21. Oktober um 14:00 UTC), das CERT-EU-Advisory 2026-018 und die BSI-Warnung 2026-297981-1032. Betroffene Konfigurationen, der Angriffsweg und die korrigierten Versionen sind erst mit dem Release öffentlich. Dieser Beitrag wird nach Erscheinen des Advisories mit diesen Angaben ergänzt.

Welche Software voraussichtlich betroffen ist

Betroffen ist die PHP-Laufzeit. Anwendungen, die auf ihr laufen, sind deshalb voraussichtlich exponiert. Das BSI nennt WordPress, Drupal, TYPO3, Joomla, Magento, Nextcloud, pfSense und OPNsense als in PHP entwickelte Projekte. Die folgende Tabelle ordnet gängige Open-Source-Anwendungen ein. Ob eine konkrete Installation angreifbar ist, entscheidet sich mit den Details des Advisories.

Dass diese Anwendungen in PHP geschrieben sind, geht aus den Projekten hervor, zum Beispiel Nextcloud, Matomo, Moodle, BookStack, Snipe-IT, GLPI und mailcow.

Zusätzlich steckt PHP laut BSI auch in einzelnen Komponenten proprietärer Produkte. Auch Begleitdienste wie phpMyAdmin oder Webmail-Clients laufen auf PHP und gehören in die Bestandsaufnahme.

Warum ein Anwendungs-Update nicht reicht

Die Lücken liegen in PHP, nicht in WordPress oder Nextcloud. Das hat drei Folgen:

• Die Laufzeit entscheidet. Gepatcht werden muss das Paket oder Image, das PHP bereitstellt, und danach muss der PHP-Prozess neu starten, damit der neue Stand läuft. Ein Update der Anwendung selbst ändert daran nichts.
• Jede Schicht zählt einzeln. Das BSI weist darauf hin, dass Container unabhängig vom Host aktualisiert beziehungsweise neu gebaut werden müssen und Hersteller von Appliances neue Firmware mit gepatchtem PHP veröffentlichen müssen. Auf einem Server können mehrere PHP-Versionen und mehrere Container zugleich laufen.
• Versionsnummern täuschen bei Backports. Debian, Ubuntu und Red Hat liefern Sicherheitsfixes oft als Backport mit unveränderter Hauptversion. Der Abgleich mit dem Advisory der Distribution (Debian, Ubuntu) ist deshalb zuverlässiger als der Vergleich der Versionsnummer allein.

Was jetzt zu tun ist

Vor dem Release: Bestand klären.

1. Erfassen, auf welchen Servern, in welchen Containern und Appliances PHP läuft. php -v zeigt die Kommandozeilenversion, der Webserver kann eine andere nutzen, etwa mit php-fpm8.3 -v für PHP-FPM.
2. Festlegen, welche dieser Systeme aus dem Internet erreichbar sind. Diese zuerst patchen.
3. Klären, wer zum Release-Zeitpunkt Updates einspielen und Dienste neu starten darf. Das BSI fordert ausdrücklich, personelle Kapazitäten bereitzuhalten.
4. Aktuelle Backups sicherstellen.

Ab dem Release: patchen und verifizieren.

1. Das Advisory auf php.net lesen: betroffene und korrigierte Versionen, mögliche Maßnahmen.
2. Systempakete aktualisieren, zum Beispiel unter Debian oder Ubuntu mit apt update und apt list --upgradable | grep -i php, und den Stand mit dem Distributions-Advisory abgleichen.
3. Container: Basis-Image ziehen oder neu bauen, Container neu erstellen, die Version im Container prüfen. Ein Host-Update ersetzt das nicht.
4. PHP-FPM und Webserver neu starten, falls das Paket das nicht selbst erledigt, und den Stand erneut prüfen.
5. Appliances: Firmware-Updates der Hersteller einspielen, sobald sie erscheinen.

Danach: beobachten. Das BSI empfiehlt, exponierte PHP-Webserver verstärkt auf Auffälligkeiten zu beobachten. Verbindliche Angriffsindikatoren liegen noch nicht vor. Als allgemeine Hygiene lassen sich kürzlich geänderte oder neue PHP-Dateien in Web- und Upload-Verzeichnissen sowie ungewöhnliche Anfragen in den Webserver-Protokollen prüfen.

Wenn nicht sofort gepatcht werden kann

• Zugriff einschränken. Das BSI empfiehlt, den Zugriff auf Webanwendungen restriktiv zu gestalten und Komponenten zu härten. Verwaltungsoberflächen gehören hinter VPN oder IP-Beschränkungen.
• Webserver vom Internet trennen. Für Systeme, die nicht kurzfristig patchbar sind, nennt das BSI die vorübergehende Trennung bis zum Patch. CERT-EU empfiehlt dasselbe für Anwendungen mit Internetzugang.
• WAF als Ergänzung. Eine Web Application Firewall verhindert eine Ausnutzung nur, wenn Erkennungsregeln für beide Lücken vorliegen und angewandt werden. Sie ersetzt den Patch nicht.
• Keine Teilmaßnahme als Ersatz. Zu session.upload_progress.enabled in php.ini ist die Lage widersprüchlich: heise online bezeichnet die Einstellung nach bisherigem Kenntnisstand als wirkungslos. Sie ersetzt kein Update.

Veraltete PHP-Versionen

Laut BSI haben alle PHP-Versionen vor 8.2 das Support-Ende erreicht, und 8.2 erhält Sicherheitsupdates nur noch bis zum Jahresende. Laut php.net laufen die Sicherheits-Zweige 8.3 bis 31. Dezember 2027, 8.4 bis 31. Dezember 2028 und 8.5 bis 31. Dezember 2029. Die letzten regulären Releases vom 24. September 2026 waren 8.5.11, 8.4.26, 8.3.35 und 8.2.34.

Betreiber von Anwendungen auf PHP 7.4, 8.0 oder 8.1 sollten die Migration auf einen unterstützten Zweig einplanen. Ob für ältere Zweige Fixes erscheinen, nennen das PHP-Advisory und die Advisories der Distributionen. Wer eine Distribution mit Langzeitwartung einsetzt, bekommt Fixes unter Umständen als Backport.

Zeitleiste

Verbreitete Fehlannahmen

• „Meine Anwendung ist aktuell, also bin ich sicher." Nein. Die Lücke liegt in PHP. Ein aktuelles WordPress oder Nextcloud auf unpatchtem PHP bleibt exponiert.
• „Host gepatcht, Container sicher." Nein. Container tragen ihr eigenes PHP und müssen neu gebaut werden.
• „Mit session.upload_progress.enabled = 0 bin ich geschützt." Nach heise online bisher nicht. Das BSI nennt keinen zuverlässigen Workaround.
• „Ich kann in Ruhe bis Freitag warten." Das BSI hält eine breite Ausnutzung innerhalb weniger Stunden nach Erscheinen der Patches für wahrscheinlich.
• „Das betrifft nur WordPress." Nein. Jede Anwendung auf PHP ist betroffen, einschließlich Verwaltungsoberflächen, Webmail und Firewalls mit PHP-Weboberfläche.

Stand und Methodik

Stand 21. Oktober 2026, vor Veröffentlichung der Patches. Die Angaben stammen aus der Vorankündigung des PHP-Projekts, dem CERT-EU-Advisory 2026-018, der BSI-Warnung 2026-297981-1032, der Übersicht der unterstützten PHP-Versionen und der Meldung von heise online. Die Zuordnung der Anwendungen beruht auf der verwendeten Programmiersprache der Projekte. Ob einzelne Installationen angreifbar sind, ist vor dem Advisory nicht belegt, ebenso wenig die Zahl betroffener Systeme.

Unser Vorgehen bei WZ-IT

• Bestandsaufnahme: Wir erfassen, wo PHP bei Ihnen läuft: Server, Container, Appliances und die Version, die der Webserver tatsächlich nutzt.
• Patchen: Wir spielen die PHP-Updates ein, bauen Container-Images neu, starten die Dienste neu und verifizieren den Stand gegen das Advisory.
• Prüfen: Wir untersuchen Webverzeichnisse und Protokolle auf Auffälligkeiten und rotieren Zugangsdaten, wenn sich ein Verdacht ergibt.
• Betrieb: Im Managed-Betrieb gehören Updates, CVE-Monitoring und Backups dazu; das Server-Audit prüft bestehende Systeme einmalig.

Weiterführende Guides

• Warum Unternehmen CVE-Monitoring brauchen
• Nextcloud Built-in CODE Server: Command Injection ohne Login (CVE-2026-110447)
• OPNsense 26.1.8: vier CVEs in sieben Tagen und Patch-Management
• cPanel CVE-2026-41940: Massenhack und souveränes Hosting
• Nextcloud-Betrieb durch WZ-IT
• CVE-Monitoring

PHP-Update ohne Zufallsfund: Wir erfassen, wo PHP bei Ihnen läuft, spielen die Updates ein und prüfen Systeme und Container. Erstgespräch buchen

Quellen

• PHP: Upcoming Critical PHP Security Release (20. Oktober 2026)
• CERT-EU Security Advisory 2026-018: Critical Vulnerabilities in PHP
• BSI: PHP - Kritische Schwachstellen bedrohen Webanwendungen weltweit (BITS-H 2026-297981-1032)
• heise online: Wichtige PHP-Updates am 21. Oktober beheben Codeeinschleusung-Schwachstellen
• PHP: Supported Versions
• Debian Security Tracker
• Ubuntu Security: CVE-2026-109618