Jede Branche hat ihre eigenen Stolpersteine. Wir kennen sie, weil wir sie in der Region täglich sehen.
- ProduktionMaschinennetze trennen, Hallen-WLAN, Wiederanlauf
- LogistikScanner, mehrere Standorte, Erreichbarkeit
- HandelKassensysteme, Filialen, Shop-Anbindung
- ArztpraxenVertraulichkeit belegen, Praxissoftware, TI
- KanzleienRechtssichere Archivierung, Mandantentrennung
- Kommunen & StadtwerkeNIS2, Netztrennung, Nachweise für die Aufsicht
- DienstleisterMobiles Arbeiten, Cloud, Zusammenarbeit
Eigene Leute an drei Standorten in Mittelfranken – deshalb sind wir im Notfall noch am selben Tag bei Ihnen.
Hand in Hand
Alles rund um Ihre IT – aus einer Hand
Von der Leitung im Serverraum bis zur KI im Arbeitsalltag: zwölf Bereiche, für jeden davon eigene Spezialisten. Was BES nicht selbst macht, übernimmt ein Haus der L&S Unternehmensgruppe – abgestimmt, nicht weitergereicht.
PHP2Shell: die kritische PHP-Lücke – und was Ihr Unternehmen jetzt tun muss
Seit dem 21. Oktober gibt es Notfall-Updates für zwei Schwachstellen, über die Angreifer ohne Zugangsdaten fremden Code auf Webservern ausführen können. Betroffen ist nicht nur Ihre Website – sondern alles im Haus, in dem PHP steckt.
Das Wichtigste in drei Sätzen
Zwei kritische Schwachstellen in PHP (CVE-2026-109618 und CVE-2026-109619, zusammen „PHP2Shell“) erlauben es, über eine einzige Anfrage aus dem Internet Code auf dem Server auszuführen – ohne Login, ohne Zutun eines Nutzers. Das BSI bewertet sie mit 9,2 von 10 und hat am 21. Oktober gewarnt. Sichere Versionen sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35; alles darunter gehört aktualisiert, und zwar heute.
Was PHP2Shell überhaupt ist
PHP ist die Sprache, in der ein Großteil des Webs läuft – WordPress, TYPO3, Shopware, Nextcloud, aber auch die Oberflächen vieler Firewalls und NAS-Systeme. Die beiden Lücken sitzen nicht in einem Plugin oder einer Anwendung, sondern in PHP selbst.
Vereinfacht: Bricht eine Anfrage unsauber ab – etwa weil der Arbeitsspeicher ausgeht –, kann PHP Reste dieser Anfrage im Speicher liegen lassen. Die nächste Anfrage, die derselbe Arbeitsprozess bearbeitet, nutzt diese Reste weiter. Wer das gezielt herbeiführt, kann den Speicher so manipulieren, dass eigener Code ausgeführt wird – mit den Rechten des Webservers.
Der unangenehme Teil: Das passiert, bevor Ihre Anwendung überhaupt startet. Es spielt keine Rolle, ob Ihr WordPress aktuell ist, ob Sie ein Sicherheits-Plugin einsetzen oder ob die Seite ein Login hat. Der Name PHP2Shell ist eine Anspielung auf Log4Shell von 2021 – und die Größenordnung ist vergleichbar.
Gefunden wurden die Schwachstellen von Wiz Research, Calif und dem Codex-Security-Team von OpenAI – mit erheblicher Unterstützung durch KI-Modelle. Die Fehler steckten nach Angaben der Forscher über ein Jahrzehnt unbemerkt im Code.
Welche PHP-Version ist sicher?
| PHP-Zweig | Sicher ab | Status |
|---|---|---|
| 8.5 | 8.5.12 | unterstützt |
| 8.4 | 8.4.27 | unterstützt |
| 8.3 | 8.3.36 | unterstützt |
| 8.2 | 8.2.35 | unterstützt |
| 8.1, 8.0, 7.4 | kein reguläres Update | offiziell abgekündigt |
| 7.3 und älter | – | seit Jahren ohne Pflege |
Betroffen ist praktisch jede PHP-Version der letzten zehn Jahre, zurück bis 7.x und früher. Für 7.4, 8.0 und 8.1 hat das PHP-Projekt zwar minimale Quellcode-Korrekturen veröffentlicht, aber keine fertigen Pakete. Wer dort noch läuft, bekommt eine Korrektur nur über die Linux-Distribution oder einen Wartungsvertrag – oder gar nicht.
Im Klartext: Wenn auf einem Ihrer Systeme PHP 7.4 oder 8.1 läuft, ist das jetzt kein technischer Schönheitsfehler mehr, sondern ein offenes Scheunentor.
Bin ich betroffen? So prüfen Sie das
- Website bei einem Hoster. Im Kundenmenü steht die eingestellte PHP-Version meist direkt beim Paket. Mehrere große Anbieter haben am 21. Oktober nachgezogen – nachsehen heißt trotzdem nachsehen, nicht hoffen.
- WordPress. Unter Werkzeuge → Website-Zustand → Bericht → Server steht die laufende PHP-Version. TYPO3 und Shopware zeigen sie im Systemstatus.
- Eigener Server.
php -vzeigt die Kommandozeilen-Version – entscheidend ist aber die des Webservers. Nach dem Update müssen alle Arbeitsprozesse neu gestartet werden, sonst läuft der alte Code weiter. - Appliances und Geräte. Firewall-, NAS- und Monitoring-Oberflächen zeigen ihre PHP-Version selten an. Hier zählt die Herstellermeldung, nicht der eigene Blick.
Shared Hosting, Managed Server oder eigener Server?
Wer was tun muss, hängt davon ab, wem der Server gehört. Das wird gerade häufig verwechselt:
| Ihr Vertrag | Wer aktualisiert PHP | Was Sie tun |
|---|---|---|
| Webhosting / Shared | der Anbieter | Statusmeldung lesen, eingestellte PHP-Version prüfen und ggf. auf einen gepflegten Zweig umstellen |
| Managed Server | der Anbieter | Bestätigung einholen, dass alle PHP-Zweige aktualisiert und die Prozesse neu gestartet wurden |
| vServer / Root-Server | Sie selbst | Sofort Updates einspielen, PHP und Webserver neu starten, alle Installationen prüfen |
| Server im eigenen Haus | Sie oder Ihr Systemhaus | wie oben, zusätzlich interne Anwendungen und Appliances |
Beispiele vom 21. Oktober: Hetzner meldete, PHP 7.4 sowie 8.0 bis 8.5 auf Webhosting- und Managed-Servern aktualisiert zu haben; Backports für ältere Zweige liefen noch. IONOS führte Sicherheitswartung durch, mit zeitweiligen Einschränkungen bei der Erreichbarkeit. Alfahosting verwies für Webspace auf die eigene Pflege und für vServer und Root-Server auf die Kunden. Das Muster ist überall dasselbe: Shared wird gepflegt, eigene Server nicht.
Fragen Sie bei Ihrem Anbieter konkret nach: Sind alle PHP-Zweige auf dem korrigierten Stand? Wurden die Arbeitsprozesse danach neu gestartet? Gibt es einen Backport für unsere ältere Version? Eine allgemeine Beruhigungsmail ist keine dieser drei Antworten.
Nicht nur die Website: wo PHP sonst noch läuft
Das ist der Punkt, der in der Berichterstattung untergeht. In den meisten mittelständischen Netzen läuft PHP an deutlich mehr Stellen als auf der Firmenwebsite:
- Firewalls und Router. Mehrere Hersteller – darunter Cisco, Palo Alto, OPNsense und pfSense – haben eigene Bulletins veröffentlicht. OPNsense hat mit 26.7.7 (Community) und 26.4.2p3 (Business) nachgezogen; wer dort das Captive Portal nutzt, muss den Dienst nach dem Update zusätzlich neu starten.
- NAS-Systeme. Die Weboberflächen von Synology und QNAP basieren auf PHP. Prüfen Sie die Herstellerhinweise und spielen Sie Firmware-Updates ein.
- Interne Anwendungen. Nextcloud, Ticketsysteme, Intranets, Monitoring-Oberflächen, Zeiterfassungs-Portale – vieles davon ist PHP.
- Vergessene Altlasten. Die Test-Instanz von 2019, das alte Kundenportal, die Subdomain für eine Messe. Genau dort läuft erfahrungsgemäß die älteste PHP-Version im ganzen Haus.
Intern erreichbar ist nicht gleich ungefährlich: Wer es einmal ins Netz geschafft hat – über eine Phishing-Mail etwa –, findet in einer ungepatchten Appliance den bequemsten Weg zu höheren Rechten. Dass Verwaltungsoberflächen von Firewalls und Routern nicht aus dem Internet erreichbar sein sollten, gilt seit dieser Woche noch etwas dringender.
Wenn Sie nicht sofort aktualisieren können
Es gibt Notmaßnahmen – aber sie schließen die Lücke nicht. Ein PHP-Kernentwickler hat das deutlich gesagt: Nur der Patch hilft wirklich. Als Überbrückung für wenige Stunden kommen in Frage:
session.upload_progress.enabled = 0setzen und anschließend alle Arbeitsprozesse neu starten.post_max_sizeklein halten – 8 MB ohne Datei-Uploads, 32 MB mit.- Regeln einer Web Application Firewall aktivieren. Cloudflare hat am 21. Oktober Regeln für alle Tarife ausgerollt; Angreifer haben ihre Anfragen allerdings schon am selben Tag angepasst.
- Systeme, die sich nicht zeitnah aktualisieren lassen, vom Netz nehmen – so die Empfehlung des britischen NCSC.
Was nicht hilft: Fehlermeldungen unterdrücken, die PHP-Version verstecken oder darauf setzen, dass die eigene Seite zu klein ist. Gescannt wird automatisiert, und zwar flach über das gesamte Internet.
Woran Sie einen Angriffsversuch erkennen
Die Angriffe laufen unterhalb der Anwendung ab – im WordPress-Protokoll steht also wenig. Auffällig sind nach Angaben der Forscher:
- Ungewöhnliche multipart-Anfragen, gefolgt von Speicherfehlern oder gehäuften 500er-Fehlern
- Auffällig große oder fehlerhafte
PHPSESSID-Cookies in den Antworten - Arbeitsprozesse des Webservers, die sich ohne erkennbaren Grund ständig neu starten
Wenn Sie so etwas sehen: Erst sichern, dann aktualisieren. Ein Server, auf dem bereits Code ausgeführt wurde, ist mit einem Update allein nicht wieder sauber – dann geht es um Spurensuche, nicht um Patchen. Wie so ein Ablauf vorbereitet aussieht, steht in unserem IT-Notfallplan.
Wie der Zeitplan aussah
| Zeitpunkt | Was passierte |
|---|---|
| 20. Oktober | Vorab-Warnung des PHP-Projekts; Details sickern vorzeitig durch, Veröffentlichung wird vorgezogen |
| 21. Oktober, 16:00 Uhr | Notfall-Updates erscheinen; das BSI warnt am selben Tag |
| 21. Oktober, ab 16:19 Uhr | Sicherheitsforscher melden erste aktive Ausnutzungsversuche |
| seitdem | Das SANS Internet Storm Center hat seine Warnstufe auf Gelb angehoben |
Bestätigte Einbrüche bei konkreten Unternehmen sind öffentlich bislang nicht dokumentiert (Stand 22. Oktober 2026). Bei Log4Shell lagen zwischen den ersten Scans und den ersten großen Schadensfällen allerdings auch nur Tage.
Wenn wir den Betrieb verantworten
Updates wie dieses einzuspielen ist bei betreuten Kunden Teil des Vertrags – und zwar auf allen Systemen, nicht nur auf der Website. Dazu gehören die Stellen, an die zuerst niemand denkt: Firewalls, NAS-Systeme, interne Anwendungen. Und der Neustart der Arbeitsprozesse, ohne den der alte Code einfach weiterläuft. Liegt ein System bei einem Dritten, fragen wir dort nach.
Wenn Sie wissen möchten, wie Ihre Umgebung gerade dasteht: ein Anruf genügt.
Wenn Sie nicht sicher sind, wo überall PHP läuft: Genau das ist der Punkt, an dem laufendes Schwachstellenmanagement den Unterschied macht. Es geht nicht darum, nach einer Schlagzeile hektisch zu suchen, sondern vorher zu wissen, welche Systeme es gibt und was darauf läuft. Für Unternehmen, die unter NIS2 fallen, ist nachweisbares Patchmanagement ohnehin Pflicht.
Häufige Fragen
Ist meine Website betroffen, wenn sie bei einem großen Hoster liegt?
Vermutlich war sie es, und vermutlich ist sie es nicht mehr: Mehrere große Anbieter haben am 21. Oktober aktualisiert. Prüfen Sie trotzdem im Kundenmenü, welche PHP-Version für Ihr Paket eingestellt ist – welcher Zweig dort läuft, entscheiden bei Webhosting meist Sie selbst und nicht der Anbieter. Steht dort noch 7.4 oder 8.0, stellen Sie um. Für vServer und Root-Server ist der Anbieter grundsätzlich nicht zuständig.
Reicht es, WordPress und alle Plugins zu aktualisieren?
Nein. Die Lücke steckt in PHP selbst und wird ausgelöst, bevor WordPress überhaupt startet. Ein tagesaktuelles WordPress auf einem ungepatchten PHP ist angreifbar, ein veraltetes WordPress auf gepatchtem PHP ist es aus diesem Grund nicht. Beides gehört aktuell – aber hier zählt zuerst PHP.
Wir nutzen noch PHP 7.4. Was jetzt?
Prüfen Sie, ob Ihre Linux-Distribution eine korrigierte Version nachliefert – einige tun das im Rahmen ihres erweiterten Supports. Falls nicht, bleibt nur der Umstieg auf einen gepflegten Zweig. Das ist unangenehm, weil ältere Anwendungen daran hängen, aber die Alternative ist ein dauerhaft offenes System. Als Zwischenschritt kann das System vom Internet getrennt werden.
Schützt uns unsere Firewall?
Teilweise, und nur mit aktuellen Regeln einer Web Application Firewall. Angreifer haben ihre Anfragen bereits am Tag der Veröffentlichung angepasst, um solche Regeln zu umgehen. Hinzu kommt: Viele Firewall-Oberflächen laufen selbst auf PHP und brauchen ihrerseits ein Update – die Firewall ist hier also auch Betroffene, nicht nur Schutz.
Woran erkenne ich, ob bereits jemand eingedrungen ist?
Zuverlässig nur durch eine Untersuchung: geänderte oder neu hinzugekommene Dateien im Webverzeichnis, ungewöhnliche ausgehende Verbindungen, neue Benutzerkonten, Auffälligkeiten in den Webserver-Protokollen. Wenn der Verdacht besteht, sichern Sie Protokolle und Daten, bevor Sie etwas ändern – sonst sind die Spuren weg.
Betrifft das auch unsere Systeme im Haus, die gar nicht aus dem Internet erreichbar sind?
Ja, nur mit geringerer Dringlichkeit. Ein Angreifer, der bereits im Netz ist, nutzt solche Systeme gern für den nächsten Schritt. Setzen Sie die Reihenfolge nach Erreichbarkeit: zuerst alles, was aus dem Internet antwortet, dann das Interne.
Wenn Sie nicht wissen, wo Sie anfangen sollen
Rufen Sie an. Wir sehen uns mit Ihnen an, welche Ihrer Systeme PHP ausführen, welche Version jeweils läuft und was zuerst drankommt. Das sind in den meisten Betrieben 30 bis 60 Minuten, und danach wissen Sie, woran Sie sind – auch dann, wenn Sie anschließend selbst aktualisieren.
Akuter Verdacht auf einen Vorfall? Notfallnummer 09122 98211-50 · Vertrieb 09122 98211-20
