php2shell: Was die kritische PHP-Lücke über Patch-Management im Mittelstand lehrt

Am 21. Oktober 2026 hat das PHP-Projekt Notfall-Updates für zwei kritische Sicherheitslücken veröffentlicht, die unter dem Namen „php2shell“ bekannt wurden. Das BSI warnte noch am selben Tag, Hoster arbeiteten die Nacht durch, manche nahmen Dienste vorsorglich vom Netz. Für viele Unternehmen war es eine unfreiwillige Übung in Sachen Patch-Management – und sie hat gezeigt, wo es hakt. Dieser Beitrag fasst zusammen, was passiert ist, wie Sie prüfen, ob Sie betroffen sind, und welche Lehren sich daraus für den Mittelstand ziehen lassen.

Was passiert ist

Die beiden Schwachstellen CVE-2026-109618 und CVE-2026-109619 stecken im Kern von PHP, also in der Sprache selbst, nicht in einer einzelnen Anwendung. Sie sind mit einem CVSS-Wert von 9,2 als kritisch eingestuft und können unter bestimmten Voraussetzungen ermöglichen, dass Angreifer ohne Anmeldung eigenen Code auf dem Server ausführen. Betroffen sind die üblichen Betriebsarten, in denen PHP Webanfragen verarbeitet – PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed.

Das Gefährliche daran ist die Reichweite: PHP läuft auf einem großen Teil aller Webserver weltweit, unter WordPress, Shopsystemen, Intranets und vielen Fachanwendungen – und häufig auch dort, wo man es nicht vermutet, etwa in Verwaltungsoberflächen von NAS-Systemen oder Firewalls. Entsprechend schnell zogen Hersteller wie Synology, QNAP oder die Anbieter von pfSense und OPNsense mit eigenen Updates nach.

Bin ich betroffen?

Die abgesicherten Versionen lauten PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Alles darunter ist verwundbar, sofern es nicht vom Distributor gepatcht wurde. Drei Fälle sind zu unterscheiden:

• Offizielle PHP-Versionen 8.2 bis 8.5: Prüfen Sie, ob mindestens die genannte Version läuft – und ob der PHP-Dienst danach neu gestartet wurde. Ein installiertes Update nützt nichts, solange der alte Prozess weiterläuft.
• PHP aus der Linux-Distribution, etwa bei Ubuntu oder Debian: Die Distributoren bauen den Fix in ihre eigenen Pakete ein, ohne die Versionsnummer anzuheben. Hier hilft nur ein Blick ins Änderungsprotokoll des Pakets, ob die beiden CVE-Nummern dort auftauchen.
• PHP 8.1 und älter: Diese Versionen bekommen vom PHP-Projekt keine Updates mehr. Wer sie ohne Distributor-Unterstützung betreibt, hat ein Problem, das sich nicht mit einem Update lösen lässt, sondern nur mit einer Migration.

Wichtig: Prüfen Sie nicht nur die Version, die Ihre Website nutzt. Auf vielen Servern liegen mehrere PHP-Versionen parallel – darunter oft alte, die niemand mehr braucht, die aber noch installiert sind oder sogar als Dienst laufen. Und die Verwaltungsoberfläche eines Hosting-Panels nutzt mitunter eine eigene PHP-Installation.

Fünf Lehren für den Mittelstand

1. Ohne Inventar kein Patch

Die erste Frage in so einer Lage lautet: Wo läuft bei uns überhaupt PHP? In vielen Unternehmen konnte das am 21. Oktober niemand auf Anhieb beantworten. Website, Intranet, Ticketsystem, die Zeiterfassung im Keller, das NAS, die Firewall-Oberfläche – jedes dieser Systeme ist ein potenzieller Einstiegspunkt. Ein gepflegtes Verzeichnis Ihrer Systeme und der darin verwendeten Komponenten ist die Grundlage für jede schnelle Reaktion.

2. Geschwindigkeit ist entscheidend

Zwischen Veröffentlichung eines Patches und den ersten automatisierten Angriffen vergehen bei kritischen Lücken oft nur Stunden. Ein Patch-Zyklus, der einmal im Monat greift, reicht für solche Fälle nicht aus. Sie brauchen einen definierten Notfallprozess: Wer bewertet die Meldung, wer entscheidet, wer patcht – auch abends oder am Wochenende?

3. Klare Zuständigkeiten mit Dienstleistern

Viele Unternehmen haben ihre Website bei einer Agentur, das Hosting bei einem Provider und den Server bei einem dritten Dienstleister. Wer ist im Ernstfall für das PHP-Update zuständig? Wenn das nicht schriftlich geregelt ist, wartet jeder auf den anderen. Bei verwaltetem Hosting patcht in der Regel der Provider, bei einem eigenen Server oder einer virtuellen Maschine meist niemand automatisch.

4. Alte Versionen sind ein dauerhaftes Risiko

Wer noch PHP 7.4 oder 8.0 einsetzt – häufig, weil eine ältere Anwendung „nur damit läuft“ –, hatte bei php2shell keine einfache Lösung. Solche Altlasten sollten nicht erst im Notfall angegangen werden. Ungenutzte Versionen gehören deinstalliert, genutzte auf einen unterstützten Stand gebracht. Wie man Altanwendungen schrittweise modernisiert, ohne alles neu zu bauen, beschreiben wir im Beitrag zur verlustfreien Migration beim Systemwechsel.

5. Überbrückung ist keine Lösung

Web Application Firewalls, das vorübergehende Abschalten bestimmter PHP-Funktionen oder das Sperren von Zugriffen können die Zeit bis zum Update überbrücken. Sie ersetzen das Update aber nicht. Und nach einem kritischen Vorfall gehört auch ein Blick in die Protokolle dazu: Gab es im Zeitfenster vor dem Patch verdächtige Zugriffe, neue oder veränderte Dateien?

Patch-Management wird zur Pflicht

Was bisher gute Praxis war, wird zunehmend gesetzlich verlangt. Die NIS2-Umsetzung verpflichtet betroffene Unternehmen zu einem geordneten Umgang mit Schwachstellen. Der Cyber Resilience Act verlangt von Herstellern digitaler Produkte, Sicherheitsupdates bereitzustellen und aktiv ausgenutzte Lücken zu melden. Und nach dem neuen Produkthaftungsrecht kann ab Dezember auch ein fehlendes Sicherheitsupdate eine Haftung auslösen. Wer Software für Kunden betreibt oder anbietet, sollte seinen Update-Prozess deshalb dokumentieren können.

Checkliste für die nächste kritische Lücke

1. Verzeichnis aller Systeme mit Webkomponenten und deren Versionen – inklusive Appliances wie NAS und Firewalls.
2. Festgelegte Verantwortliche und Vertretungen, auch außerhalb der Geschäftszeiten.
3. Schriftlich geregelte Zuständigkeiten mit Hoster, Agentur und IT-Dienstleister.
4. Ein Benachrichtigungsweg für Sicherheitswarnungen, etwa über die Warnmeldungen des BSI.
5. Ein getesteter Ablauf für Notfall-Updates einschließlich Neustart der Dienste und Funktionsprüfung.
6. Regelmäßiges Entfernen nicht mehr benötigter Versionen und Dienste.
7. Protokollierung, die es erlaubt, nachträglich verdächtige Aktivitäten zu erkennen.

Fazit

php2shell war nicht die erste kritische Lücke in einer Basistechnologie, und es wird nicht die letzte sein. Unternehmen, die ihre Systeme kennen, Zuständigkeiten geklärt haben und einen eingespielten Notfallprozess besitzen, haben die Woche mit ein paar Stunden Mehraufwand überstanden. Für alle anderen ist jetzt ein guter Zeitpunkt, die Lehren daraus umzusetzen – bevor die nächste Warnung kommt.

Wenn Sie den Betrieb Ihrer Server und Anwendungen nicht selbst im Blick behalten möchten, übernehmen wir das im Rahmen unserer Managed Services aus Stuttgart – mit Monitoring, festen Reaktionszeiten und dokumentiertem Patch-Management. Sprechen Sie uns an.