PHP-Sicherheitslücke „PHP2Shell“: Was KMU mit Website, Shop und Kundenportal jetzt tun müssen

Am 21. Oktober 2026 hat das BSI vor zwei kritischen Schwachstellen in PHP gewarnt – der Skriptsprache, auf der WordPress, TYPO3, Joomla, Drupal, Magento, Shopware und Moodle laufen. Die Lücken erlauben das Ausführen von Schadcode aus der Ferne, Details waren schon vor dem Patch öffentlich. Mehrere Behörden haben ihre Webseiten vorsorglich abgeschaltet. Für KMU heißt das: Jede Website, jeder Onlineshop und jedes Kundenportal auf PHP-Basis gehört jetzt auf den Prüfstand.

Was über PHP2Shell bekannt ist

Das PHP-Projekt hatte die Sicherheitsupdates für den 21. Oktober angekündigt. Weil technische Details bereits vorab öffentlich wurden, erhielten die Schwachstellen schnell einen eigenen Namen: PHP2Shell. Gemeldet wurden sie unter anderem vom Sicherheitsunternehmen Huntress, das PHP-Sicherheitsteam und das BSI haben sie bestätigt.

Zwei Lücken im Kern von PHP

Beide Schwachstellen liegen nicht in einem Plugin oder CMS, sondern in PHP selbst. CVE-2026-109618 betrifft die Behandlung von Speicherüberläufen (Out of Memory): PHP kann dabei mitten in der Verarbeitung einer Anfrage unterbrochen werden, die halb initialisierten Daten werden anschließend als gültig behandelt. CVE-2026-109619 betrifft Zustandsdaten, die nach dem Freigeben des Speichers weiterleben und von einer späteren Anfrage auf demselben Worker genutzt werden können. In beiden Fällen ist laut PHP-Projekt Remote Code Execution möglich.

Wer betroffen ist

Laut PHP-Sicherheitsmeldung sind alle PHP-Installationen betroffen, die Web-Anfragen verarbeiten – also PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das höchste Risiko besteht bei mod_php: Hier wurde ein Angriff demonstriert, bei dem eine Anfrage ohne Anmeldung den Angriff auslöst, bevor überhaupt Anwendungscode läuft. Eine sichere Konfiguration von WordPress oder Shopware schützt deshalb nicht.

Gepatchte Versionen

Warum gerade KMU jetzt handeln müssen

In vielen mittelständischen Unternehmen läuft PHP an Stellen, die niemand als „kritisches System“ auf dem Schirm hat: die Firmenwebsite beim Webhoster, der Onlineshop bei einer Agentur, das Bewerberportal, ein Intranet-Wiki oder die Lernplattform für Schulungen. Genau diese Systeme sind aus dem Internet erreichbar – und werden von Angreifern automatisiert nach verwundbaren Versionen abgesucht.

Dazu kommt ein verbreitetes Missverständnis: Ein Update von WordPress oder einem Plugin ersetzt kein PHP-Update. PHP ist die Laufzeitumgebung darunter. Wer sie aktualisiert, hängt vom Betriebsmodell ab: Beim Shared Hosting übernimmt das in der Regel der Hoster, bei eigenen Servern, VPS oder Containern liegt die Verantwortung beim Unternehmen bzw. dessen Dienstleister. Container-Images mit eingebautem PHP müssen neu gebaut und ausgerollt werden.

Was NIS2 und ISO 27001 dazu sagen

Für Unternehmen im Anwendungsbereich von NIS2 ist der Umgang mit PHP2Shell ein Praxistest. Die Risikomanagementmaßnahmen nach § 30 BSIG verlangen die Behandlung von Schwachstellen und die Sicherheit bei der Wartung von Systemen. Wird ein Webserver kompromittiert und sind etwa Kundendaten betroffen, greifen die Meldepflichten mit 24-Stunden-Frühwarnung – bei personenbezogenen Daten zusätzlich die 72-Stunden-Frist nach Art. 33 DSGVO. In ISO 27001 adressiert Control A.8.8 (Management technischer Schwachstellen) genau diesen Fall; Auditoren wollen sehen, wie schnell kritische Lücken erkannt, bewertet und geschlossen wurden.

Sofortmaßnahmen: die Checkliste für IT-Leiter

1. Alle PHP-Systeme finden

Erstellen Sie eine Liste aller Websites, Shops und Portale – auch der von Agenturen betriebenen und der „vergessenen“ Testinstanzen. Pro System: Hoster bzw. Server, PHP-Version, Betriebsart (FPM, mod_php, Container), Verantwortlicher. Ein externer Schwachstellenscan hilft, Systeme aufzuspüren, die in keiner Liste stehen.

2. Patchen – oder vom Netz nehmen

Spielen Sie die gepatchten Versionen ein und starten Sie PHP-Worker bzw. Webserver neu. Bei Shared Hosting: beim Hoster schriftlich nachfragen, ob und wann das Update eingespielt wurde. Wo ein Update nicht kurzfristig möglich ist, empfiehlt das BSI, die Erreichbarkeit aus dem Internet vorübergehend einzuschränken oder den Server vom Netz zu nehmen.

3. Installationsstand verifizieren

Vertrauen Sie nicht auf Zusagen, prüfen Sie die tatsächlich laufende Version – etwa über die Server-Konsole oder das Hosting-Panel. Auf Systemen mit mehreren PHP-Versionen muss jede genutzte Version aktualisiert sein.

4. Übergangsmaßnahmen nur als Notlösung

Das PHP-Projekt nennt Konfigurationsänderungen, die bekannte Angriffswege erschweren – unter anderem session.upload_progress.enabled=0 mit anschließendem Neustart der Worker. Es betont aber ausdrücklich: Es gibt keine vollständige Abhilfe, nur das Update ist sicher. Systeme auf PHP 8.1 oder älter sollten Sie spätestens jetzt migrieren.

5. Auf Kompromittierung prüfen

Weil Details vor dem Patch öffentlich waren, sollten Sie Webserver-Logs auf ungewöhnliche Anfragen, neue oder veränderte PHP-Dateien im Webverzeichnis und unerwartete Prozesse prüfen. Bei Verdacht gilt Ihr Incident-Response-Plan: System isolieren, Beweise sichern, Zugangsdaten und Schlüssel erneuern.

6. Prozess für das nächste Mal festlegen

PHP2Shell zeigt, wie kurz die Zeit zwischen Bekanntwerden und Angriff sein kann. Legen Sie verbindlich fest, wer BSI-Warnungen liest, welche Patch-Fristen für kritische Lücken gelten und wie Hoster und Agenturen eingebunden sind. Wie das strukturiert gelingt, beschreibt unser Beitrag zum Patch-Management unter NIS2.

Fazit

PHP2Shell ist keine Lücke in einem exotischen Produkt, sondern in der Basis eines großen Teils der Webanwendungen im Mittelstand. Die gute Nachricht: Updates sind verfügbar. Die schlechte: Sie helfen nur, wenn jemand weiß, wo überall PHP läuft, und dafür zuständig ist. Wer jetzt Inventar, Patch-Stand und Zuständigkeiten klärt, erfüllt nicht nur die Anforderungen aus NIS2 und ISO 27001, sondern ist auch auf die nächste kritische Warnung vorbereitet.

Quellen: PHP-Projekt, Sicherheitsmeldungen vom 20. und 21.10.2026 (php.net/archive/2026.php); BSI-Cybersicherheitswarnung vom 21.10.2026, zusammengefasst bei datensicherheit.de, ZDFheute und telespiegel.de (21.10.2026); Huntress, „php2shell“-Analyse (20./21.10.2026); Help Net Security (21.10.2026). Stand: 22.10.2026. Die Lage entwickelt sich schnell – prüfen Sie die aktuellen Hinweise von PHP und BSI. Dieser Beitrag ersetzt keine Rechtsberatung.

Weiterlesen