PHP-Lücke: Wie meine Systeme noch in derselben Nacht sicher waren und was Sie Ihren IT-Dienstleister jetzt fragen sollten

Am 21. Oktober 2026 hat das Bundesamt für Sicherheit in der Informationstechnik (BSI) für eine Schwachstelle in PHP die Warnstufe 3 ("Orange") ausgerufen und das Risiko als "außerordentlich hoch" eingestuft. Die Lücke läuft unter dem Namen "PHP2Shell". Städte, Universitäten und Kliniken haben vorsorglich Websites vom Netz genommen.

Meine öffentlich erreichbaren Systeme mussten nicht vom Netz. Noch in der Nacht zum Donnerstag, gut acht Stunden nachdem die PHP-Entwickler ihre Patches veröffentlicht hatten, liefen alle auf abgesicherten Versionen. Das ist nicht mein Verdienst allein, denn wann ein Patch existiert, bestimmen die Hersteller. Mein Anteil ist ein anderer: Ich habe sofort gemerkt, wann welcher Patch da war, und ich konnte ihn ohne Zittern einspielen. Beides ist vorbereitbar, und genau darum geht es hier.

Worum es geht

PHP ist die Programmiersprache, auf der ein Großteil des Internets läuft, darunter WordPress, Shopware, TYPO3 und viele individuell gebaute Firmenportale. Die gemeldeten Schwachstellen (CVE-2026-109618 und CVE-2026-109619) erlauben es Angreifern laut Berichterstattung, ohne Anmeldung Schadcode auf dem Server auszuführen. Das bedeutet im ungünstigen Fall: Übernahme der Website, Zugriff auf Datenbank und Kundendaten, Missbrauch des Servers für weitere Angriffe. Details wurden laut dpa unbeabsichtigt vorab öffentlich, ein funktionierender Exploit wurde bereits gezeigt.

Gepatcht ist die Lücke in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Ältere, nicht mehr unterstützte Versionen bekommen keine regulären Updates. Das BSI rät, Systeme im Zweifel vom Netz zu nehmen, bis der Patch eingespielt ist. Das ist für jeden richtig, der nicht schnell patchen kann. Die Frage ist: Wie schnell können Sie es?

Das Problem hat mehrere Adressen

Bei mir läuft PHP nicht an einer Stelle, sondern an mehreren: in der Container-Umgebung meiner eigenen Website, auf dem Mailserver und auf dem Server einer WordPress-Seite. Mir nützt der Patch der PHP-Entwickler allein nichts, ich brauche den Patch der Anbieter, deren Software ich einsetze. Jede dieser Stellen bekommt ihn von einem anderen Lieferanten, zu einem anderen Zeitpunkt.

Die PHP-Entwickler veröffentlichten ihre Patches am Nachmittag des 21. Oktober. Für den Mailserver kam das Update des Herstellers gut drei Stunden später, die Container-Grundlage meiner Website folgte nach rund sieben Stunden, für den WordPress-Server stand der Fix ebenfalls noch am selben Tag bereit. Ich habe jedes Update eingespielt, sobald es verfügbar war. Gegen Mitternacht war der letzte Server dran. Schon gegen 18 Uhr hatte ich zusätzlich die Schutzregeln meines Netzwerkdienstleisters (Cloudflare) aktiviert, die bekannte Angriffswege vorab abfangen. Diese Regeln wirken nur für Datenverkehr, der über diesen Dienst läuft, sie sind eine Überbrückung und kein Ersatz für den Patch.

Das ist der Normalfall und die eigentliche Lehre für Unternehmer: Es gibt nicht "das eine Update". Wer nicht weiß, wo überall PHP läuft, patcht nur einen Teil und fühlt sich sicher.

Warum es bei mir schnell ging

1. Ich wusste, wo PHP läuft. Ich führe ein Inventar aller Systeme, ihrer Versionen und der Quellen, aus denen ihre Updates kommen. Als die Meldung kam, musste ich nichts suchen.

2. Eine automatische Wache hat für mich gewartet. Direkt nach der Warnung habe ich einen Auftrag eingerichtet, der alle 30 Minuten die Quellen meiner Hersteller und Lieferanten prüft und mich sofort benachrichtigt, sobald für eines meiner Systeme ein Fix verfügbar ist. Das übernimmt eine KI. Sie liest nur und meldet nur. Eingespielt habe ich selbst. Der Vorteil ist banal und enorm: Ich musste nicht den ganzen Tag Nachrichtenseiten und Hersteller-Hinweise im Blick behalten.

3. Das Einspielen ist bei mir Routine, kein Ausnahmezustand. Update-Vorschläge für meine Software entstehen automatisch (über das Werkzeug Renovate), die Tests laufen von selbst, und die eigentliche Anwendung steckt in Containern, die sich komplett neu bauen und austauschen lassen. Dadurch ist ein PHP-Update bei mir derselbe Ablauf wie jedes andere Update, nur eilig. Es wird erst auf einer Testumgebung geprüft und dann produktiv genommen.

Was ich nicht behaupte

Eine Nacht ist kein Naturgesetz. Mein Setup ist überschaubar, ich kenne jede Komponente, und ich bin eine Person ohne Abstimmungsrunden. Ein Unternehmen mit zehn Systemen, drei Dienstleistern und einem Hoster, der PHP zentral verwaltet, hängt von deren Tempo ab. Das kann trotzdem schnell gehen, aber nur, wenn vorher geklärt wurde, wer zuständig ist und wer benachrichtigt wird.

Fünf Fragen an Ihren IT-Dienstleister oder Hoster, heute noch

1. Wo überall läuft bei uns PHP (Website, Shop, Mailserver, Portale, Testsysteme), und welche Version?
2. Ist das Update eingespielt? Seit wann, und woran sehen wir das?
3. Wurde das Update nicht nur installiert, sondern auch wirksam gemacht, also Dienste neu gestartet oder Container neu ausgerollt? Ein installiertes Paket schützt nicht, wenn ein laufender Prozess noch den alten Stand nutzt.
4. Gibt es Systeme mit nicht mehr unterstützter PHP-Version (8.1 und älter)? Wenn ja: Was ist der Plan, und was schützt sie bis dahin?
5. Wer prüft ab sofort, wann Fixes verfügbar sind, und wer entscheidet im Zweifel über das Abschalten?

Bekommen Sie auf diese Fragen keine klare Antwort, ist das die eigentliche Information. Die Lücke ist dann nur der Anlass.

Wenn Sie wissen möchten, wo Sie stehen

Ich schaue mir gern an, wie schnell Ihre Systeme im Ernstfall patchbar wären, und sage Ihnen ehrlich, ob das ein Problem ist oder nicht. Das ist ein kurzes, unverbindliches Gespräch ohne Verkaufsdruck. Schreiben Sie mir über das Kontaktformular auf jacomeit.de oder direkt per E-Mail.