PHP2Shell ist kein Patch-Problem. Es ist ein Asset-Management-Problem.

Als am 21. Oktober die kritischen PHP-Schwachstellen bekannt wurden, wie lange hätten Sie gebraucht, um eine einzige Frage verlässlich zu beantworten: Wo überall führen wir PHP aus?

PHP2Shell (CVE-2026-109618, CVE-2026-109619) hat Organisationen weltweit in Alarmbereitschaft versetzt. In den Niederlanden nahm das Cyber-Zentrum NCSC-NL seine eigene Website präventiv vom Netz – DigiD, Overheid.nl, das Parlament und der Hafen von Rotterdam folgten dem Beispiel. Im DACH-Raum reagierte das Informationstechnikzentrum Bund (ITZBund) umgehend und deaktivierte mehrere Portale. Zeitgleich forderte das schwedische CERT-SE, Teil des nationalen Cybersicherheitszentrums, Unternehmen dringend auf, betroffene Systeme zu identifizieren und zu aktualisieren.

Systeme offline zu nehmen, verschafft Zeit für das Patch-Management. Es ist jedoch nur eine Notlösung, kein Fix. Die eigentliche Behebung ist trivial: PHP updaten und neu deployen. Die wahre Herausforderung liegt in dem Schritt davor: jeden einzelnen Ort zu finden, an dem PHP ausgeführt wird.

Theoriezustand vs IT-Realität

Ihre Datenbanken, Konfigurationsdateien und Asset-Listen beschreiben lediglich den Soll-Zustand Ihres Deployments – nicht zwingend das, was heute tatsächlich in Ihrer Infrastruktur aktiv ist. Diese Diskrepanz ist kritisch. Laut Wiz Research ist jede PHP-Version des letzten Jahrzehnts (bis zurück zu PHP 5.4) von mindestens einer der Schwachstellen betroffen. Jede veraltete Instanz, die überlebt hat, ist somit ein potenzielles Ziel – inklusive des Testservers, der vor Jahren manuell aufgesetzt wurde - und seitdem in Vergessenheit geraten ist.
Dabei dauert es keine Jahre, bis diese Lücke zwischen Soll und Ist entsteht. Es genügen Monate oder Tage: Ein Service, der sein letztes Redeployment verpasst hat, oder ein Update, das auf halbem Weg abgebrochen ist, reicht völlig aus.

In all diesen Fällen läuft unter Umständen eine Version, die in Ihrem Repository längst nicht mehr existiert. Wenn eine kritische Schwachstelle eine so omnipräsente Technologie wie PHP trifft, lautet die erste Aufgabe daher nicht "Patchen". Sie lautet: Herausfinden, was wirklich in Ihrer Umgebung läuft.

Wo sich PHP-Versionen verstecken können

Unserer Erfahrung nach taucht PHP vor allem an vier Orten auf, die bei herkömmlichen Asset-Scans oft durchs Raster fallen:

• Shared Container-Images: Viele Teams bauen ihre Services auf einem Shared Base Image auf, das PHP enthält. Ist dieses Basis-Image veraltet, gilt das für jeden darauf aufbauenden Service – auch für solche, die auf den ersten Blick gar nicht wie PHP-Applikationen aussehen.

• Dynamische Image-Tags: Teams verweisen oft über allgemeine Tags wie „PHP 8 mit Apache“ auf ein Image. Der Tag wirkt statisch, verweist aber bei jedem Update des Images auf einen neueren Build. Wenn Sie Ihre Services nicht auf einen exakten, eindeutigen Build (Image Digest) pinnen, wissen Sie nie mit Sicherheit, welche PHP-Version gerade läuft.

• Verwaiste Services und Schatten-IT: Alte Testumgebungen, Demo-Server, Infrastruktur, die an der IT vorbei eingesetzt wird und vergessene interne Tools überdauern oft die Mitarbeiter, die sie einst aufgesetzt haben. In IT-Inventaren und CMDBs tauchen sie fast nie auf.

• Zugekaufte Software (Third-Party): Viele kommerzielle Produkte nutzen unter der Haube PHP, ohne dass dies für den Anwender ersichtlich ist. Unsere eigene Plattform gehört ebenfalls dazu. Als PHP2Shell bekannt wurde, haben wir unsere Systeme umgehend gepatcht und unsere Kunden proaktiv informiert.

Wie will man etwas patchen, wenn man nicht weiß, dass es existiert?

Alle oben genannten Punkte lassen sich auf ein zentrales Risiko reduzieren: Assets, von denen niemand weiß. Die Systeme auf Ihrer Asset-Liste sind innerhalb von Tagen gepatcht. Die Systeme, die für Breaches sorgen, sind jene, die niemand auf dem Schirm hatte.

Niemand überwacht diese Systeme, niemand fühlt sich verantwortlich. Wenn sie aus dem Internet erreichbar sind, macht PHP2Shell keinen Unterschied, wie alt oder vergessen sie sind.

Ihre Angriffsfläche umfasst alles, was ein Angreifer erreichen kann – auch die Bereiche, die Ihr Team aus den Augen verloren hat. Sie können nicht bewerten, patchen oder überwachen, was Sie nicht gefunden haben. Asset Discovery muss daher immer an erster Stelle stehen. Sobald Sie wissen, was Sie haben, ist die Remediation der einfache Teil.

Wie Sie die PHP-Schwachstellen richtig beheben

Aktualisieren Sie auf PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35, wie im offiziellen Security Advisory von PHP angegeben. Bauen (Rebuild) Sie Ihre Container-Images neu, anstatt laufende Container zu patchen, und starten Sie PHP anschließend neu. Ein Fix greift erst, wenn die Webserver- und PHP-Prozesse neu gestartet wurden.

Sollte sich Ihre Versionsnummer nach dem Update scheinbar nicht geändert haben, prüfen Sie das Changelog des Pakets. Linux-Distributionen implementieren Sicherheitsfixes häufig per Backporting, ohne die Hauptversionsnummer anzupassen.
Achtung: PHP 8.1 und älter erhalten keine offiziellen Updates mehr. Das CERT-EU empfiehlt, nicht mehr unterstützte Versionen als kompromittiert zu betrachten, es sei denn, Ihr Vendor hat den Fix per Backport bereitgestellt. Können Sie ein System nicht zeitnah aktualisieren, nehmen Sie es vom Netz. Internetexponierte Systeme haben absolute Priorität.

Ein erfolgreiches Deployment ist kein Indiz für Sicherheit

Ein erfolgreiches Deployment beweist lediglich, dass die neue Version ausgeliefert wurde. Es beweist nicht, dass die alte Version verschwunden ist. Eine verwaiste Kopie, die noch im Speicher läuft, ein fehlgeschlagenes Update oder ein Server außerhalb Ihres regulären Deployment-Prozesses können die angreifbare Version am Leben erhalten.

Das ist der feine Unterschied zwischen „Wir haben den Fix ausgerollt“ und „Wir sind nicht mehr darüber angreifbar“. Überprüfen Sie, was tatsächlich läuft, nicht nur das, was in der Pipeline steht.

Best Practice

Bei Zero-Days und kritischen CVEs zählt Geschwindigkeit. PHP veröffentlichte den Fix am 21. Oktober; bereits am nächsten Morgen hatten wir bei Holm Security Vulnerability-Tests für PHP2Shell (für unauthentifizierte und authentifizierte Scans) in unserer Plattform verfügbar.

Innerhalb einer Stunde nach Bekanntwerden einer kritischen Schwachstelle sollten Sie als CISO oder IT-Sicherheitsleiter folgende vier Fragen beantworten können:

• Welche Systeme führen die betroffene Software aus? (Inklusive Third-Party-Produkte, nicht nur Eigenentwicklungen).
• Welche Versionen laufen dort tatsächlich? (Nicht die Version in Ihrem Code).
• Welche dieser Systeme sind aus dem Internet erreichbar? (Diese haben Prio 1).
• Wer ist der Owner des jeweiligen Systems? (Ein System ohne Owner wird nicht gepatcht).

Drei Gewohnheiten sorgen dafür, dass Sie diese Antworten sofort parat haben:

• Führen Sie ein exaktes Verzeichnis der Shared Images, auf denen Ihre Services basieren.
• Pinnen Sie jeden Service an einen eindeutigen Image-Build (Digest).
• Scannen Sie Ihre Live-Umgebungen regelmäßig, um aufzudecken, was Ihr Code nicht zeigt (Continuous Exposure Management).

So hat Holm Security PHP2Shell gehandhabt

Da auch unsere Plattform PHP nutzt, haben wir denselben Prozess intern durchlaufen. Hier ist unser aktueller Stand:

• Wir haben unsere Cloud-Plattform vollständig gepatcht.
• Der Rollout des Patches für Kunden mit einem selbstgehosteten Security Center (On-Premises) ist im Gange.
• Unsere Vulnerability-Tests sind sowohl für Cloud-Scanner als auch für Scanner Appliances live und wurden bestehenden Scan-Profilen automatisch hinzugefügt.
• Im Einklang mit dem europäischen Cyber Resilience Act (CRA) haben wir eine frühzeitige Meldung an die ENISA übermittelt.
• Unsere Scans prüfen, was tatsächlich in Ihrer Umgebung läuft – einschließlich der Schatten-IT, die in Ihrem Code nicht auftaucht.

FAQ

1. Was ist PHP2Shell?

   PHP2Shell ist die Bezeichnung für CVE-2026-109618 und CVE-2026-109619. Es handelt sich um kritische PHP-Schwachstellen, die eine Remote Code Execution (RCE) auf einem Webserver ohne vorherige Authentifizierung ermöglichen. Beide Schwachstellen weisen einen CVSS v4.0 Score von 9.2 (von 10) auf. 
   
   

2. Welche PHP-Versionen sind betroffen?

   Jede PHP-Version, die im letzten Jahrzehnt veröffentlicht wurde (bis zurück zu PHP 5.4), ist von mindestens einer der Schwachstellen betroffen. Die gepatchten Versionen sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. PHP 8.1 und ältere Versionen erhalten keine offiziellen Updates mehr.
   
   

3. Ist ein Container sicher, sobald ich sein Image aktualisiere?

   Nein. Erst wenn Sie das Image neu bauen (Rebuild), neu deployen und aktiv verifizieren, dass keine alten Instanzen mehr laufen, ist die Schwachstelle behoben.
   
   

4. Warum sieht meine PHP-Versionsnummer nach dem Update unverändert aus?

   Linux-Distributionen pflegen Sicherheitsfixes oft per Backporting in ältere Versionen ein, ohne die Hauptversionsnummer zu ändern. Überprüfen Sie das Changelog Ihres Pakets auf die entsprechenden CVE-IDs.
   
   

5. Welche PHP-Setups sind am stärksten gefährdet?

   PHP-Installationen, die Web-Requests verarbeiten, sind betroffen (inkl. mod_php, PHP-FPM, php-cgi, FrankenPHP und LiteSpeed). Laut dem Advisory des Canadian Cyber Centre stuft PHP mod_php als das höchste Risiko ein, da hier ein unauthentifizierter Request die Schwachstelle auslösen kann, bevor überhaupt Applikationscode ausgeführt wird.
   
   

6. Wie finde ich alle Systeme, Assets oder Services, in denen PHP läuft?

   Beginnen Sie bei den Shared Images, auf denen Ihre Services aufbauen. Überprüfen Sie anschließend die Versionen, die in Ihrer Live-Umgebung laufen – vergessen Sie dabei weder eingekaufte Third-Party-Produkte noch alte Umgebungen ohne Owner. Nur ein regelmäßiges Assessment Ihrer Live-Umgebung deckt die Schatten-IT auf, die Ihr Code verschweigt.