php2shell:
Wie ein gelebtes ISMS im Ernstfall für Sicherheit und Ruhe sorgt

01Kapitel 1 von 4

Wissen, was man betreibt: die Software-Stückliste

Wie schnell könnte Ihr Haus verbindlich sagen, auf welchen Systemen PHP läuft, in welcher Version, wer dafür verantwortlich ist und welches davon aus dem Internet erreichbar ist?

Die Kolleginnen und Kollegen von ProSec Defense beschreiben, wie man die Lücke technisch schließt: erst eine Schutzregel vor der Anwendung, dann ein geprüfter Notfall-Patch.²² Beide Schritte gelingen am besten, wenn ein Unternehmen schon vorher weiß, wo die betroffene Komponente steckt. Dieses Wissen aufzubauen und aktuell zu halten, ist eine Aufgabe der Governance, und es hilft bei jeder künftigen Lücke wieder.

Die Lage in vier Tagen

Warum diese Lücke alle Branchen trifft

Das BSI nennt den Grund selbst: PHP steckt nicht nur in klassischen Websites, sondern auch in Komponenten proprietärer Produkte. Genannt werden WordPress, Drupal, TYPO3, Joomla, Magento, Nextcloud, pfSense und OPNsense, also Redaktionssysteme, Shops, Dateiablagen und Firewalls.⁴ Die Lücken liegen in der Laufzeitumgebung, nicht in einer Anwendung. Ein Update der Anwendung reicht deshalb nicht; die PHP-Laufzeit darunter muss gepatcht, Container müssen neu gebaut werden, und Hersteller müssen unter Umständen neue Firmware mit gepatchtem PHP veröffentlichen.⁴ heise weist darauf hin, dass PHP oft unbemerkt als Abhängigkeit mitinstalliert wird.⁹

Unsere Einordnung: Das ist das Muster von Heartbleed und Log4Shell, auf das auch heise und das BSI verweisen.^{4, 9} Eine einzige quelloffene Komponente wird von fast allen Unternehmen genutzt, oft ohne dass sie es wissen. Das Risiko entsteht in der Lieferkette und trifft alle gleichzeitig. Unternehmen, die ihre Lieferkette kennen, können die ersten Stunden direkt zum Patchen nutzen.

Offizieller HerausgeberBelege 1, 2 BehördlichBelege 4, 5, 6, 7

Zwei Listen, zwei Gesetze

Für die Frage „Wo läuft PHP?“ braucht ein Unternehmen zwei Listen, die oft verwechselt werden. Die erste beschreibt, was es betreibt. Die zweite beschreibt, was in den Produkten steckt, die es herstellt oder einkauft.

Der CRA definiert die Software-Stückliste als „formale Aufzeichnung der Einzelheiten und Lieferkettenbeziehungen der Komponenten“ eines Produkts.¹⁴ Anhang I verlangt, dass daraus „zumindest die obersten Abhängigkeiten“ hervorgehen.¹⁷ Für php2shell genügt das nicht immer: PHP ist oft keine oberste Abhängigkeit, sondern steckt eine Ebene tiefer, im Basis-Image eines Containers oder im Betriebssystem einer Appliance. Die Technische Richtlinie TR-03183 des BSI beschreibt in ihrem Teil zur Stückliste, welche Angaben eine belastbare SBOM enthält.²⁰

Viele Unternehmen sind beides, Betreiber und Hersteller: Sie betreiben ein Kundenportal und verkaufen zugleich ein Gerät mit Weboberfläche oder eine Software, die vor Ort beim Kunden läuft. Unsere Einordnung: Reine Cloud-Dienste ohne Produktbezug fallen in der Regel nicht unter den CRA, wohl aber unter NIS2. Für Software und Geräte, die Sie in der EU bereitstellen, trifft Sie der CRA als Hersteller, und zwar für jede eingebaute Komponente, die Sie nicht selbst geschrieben haben.

Nachweis: Inventar mit Stand und Verantwortlichen; SBOM je Produktversion; dokumentierte Sorgfaltsprüfung für Komponenten Dritter.

RechtstextBelege 11, 14, 15, 17, 18

Was eine gute Liste in der ersten Stunde beantwortet

Eine Stückliste ist dann brauchbar, wenn sie die Fragen beantwortet, die in einer Lage wie dieser in der ersten Stunde gestellt werden:

Die Behörden arbeiten selbst mit diesem Ansatz: Das niederländische NCSC sammelt die betroffenen Produkte mit PHP-Abhängigkeit in einem öffentlichen Verzeichnis, dessen Quelldaten im SBOM-Format SPDX gepflegt werden.⁷ CERT-EU und BSI verweisen darauf.^{4, 5} Unsere Einordnung: Wer seine eigene Stückliste maschinenlesbar führt, kann sie gegen ein solches Verzeichnis abgleichen und hat seine Antwort in kurzer Zeit.

1. 1Inventar der Systeme und Dienste
2. 2SBOM je Produkt und Version
3. 3Verantwortliche und Lieferanten zuordnen
4. 4SBOM von Lieferanten einfordern
5. 5Automatischer Abgleich mit Warnmeldungen

Nachweis: Für ein Stichprobensystem lässt sich aus der Liste in Minuten ablesen: PHP-Version, Betriebsart, Exposition, Prozess, Verantwortlicher, Lieferant, Supportende.

EinordnungBelege 2, 4, 5, 6, 7, 20

02Kapitel 2 von 4

Früh informiert: Vorsprung durch eine geregelte Frühwarnung

Wie gelangt eine Ankündigung wie die vom 20. Oktober in Ihrem Haus schnell zur richtigen Person?

Diese Lage bot einen Vorlauf, den es selten gibt. Am 20. Oktober kündigten die PHP-Entwickler ein kritisches Sicherheitsrelease für den Folgetag an und baten die Nutzer, sich auf ein schnelles Update vorzubereiten.¹ Das BSI riet am 21. Oktober, „dringend die personellen Kapazitäten bereitzuhalten“.⁴ Wer diese Ankündigungen erhielt und gegen seine Stückliste abglich, hatte rund 24 Stunden, um Betroffenheit festzustellen, Zuständige zu alarmieren und Wartungsfenster vorzubereiten. Viele Häuser haben diese Zeit genutzt. Wer erst aus den Abendnachrichten davon erfuhr, kann seine Frühwarnung jetzt so einrichten, dass er beim nächsten Mal mit demselben Vorsprung startet.

Was das Gesetz verlangt

§ 30 Abs. 2 Nr. 5 BSIG verlangt ein „Management und Offenlegung von Schwachstellen“.¹¹ Unsere Einordnung: Ein Management von Schwachstellen beginnt mit dem Empfang der Information. Mit festgelegten Quellen, Empfängern und Bewertungsregeln kommt eine Warnung verlässlich und rechtzeitig bei den Zuständigen an. Auch der CRA setzt auf diesen Fluss: Hersteller müssen Informationen über Schwachstellen in ihren Produkten und in den Komponenten Dritter austauschen, eine Kontaktadresse für Meldungen angeben und behobene Schwachstellen so beschreiben, dass Nutzer das betroffene Produkt erkennen.¹⁷ Bei einer aktiv ausgenutzten Schwachstelle informiert der Hersteller seine Nutzer, wo nötig in einem maschinenlesbaren Format (Art. 14 Abs. 8).¹⁶ Für die Kunden dieser Hersteller lohnt es sich deshalb, zu klären, wo deren Meldungen im eigenen Haus ankommen.

RechtstextBelege 11, 16, 17

Die Quellen, die diesmal rechtzeitig waren

Unsere Einordnung: Die Quellen sind öffentlich und kostenlos und damit für jedes Haus erreichbar. Wirksam werden sie, wenn jemand zuständig ist, sie zu lesen, und wenn es eine Liste gibt, gegen die man sie lesen kann. Maschinenlesbare Sicherheitshinweise im Format CSAF, das das BSI fördert, und die Stückliste aus Kapitel 1 machen aus diesem Abgleich einen automatischen Schritt.²¹

Frühwarnung und Nachprüfung gehören zusammen

Amazon berichtet von einem ersten Ausnutzungsversuch am 17. Oktober und von Proof-of-Concept-Exploits rund zwölf Stunden vor der geplanten Veröffentlichung.⁸ Cloudflare sah nach Reuters Angriffsversuche schon rund zehn Stunden vor der Veröffentlichung der Details.¹⁰ Ein Patch am 21. Oktober schließt die Lücke. Ob vorher jemand eingedrungen ist, klärt eine ergänzende Prüfung. Amazon empfiehlt, Untersuchungen beim frühesten bekannten Ausnutzungsdatum zu beginnen, also beim 17. Oktober.⁸

Hinzu kommt eine Entwicklung, die über diesen Fall hinausweist. Das BSI nennt Wiz und Calif, die zusammen mit OpenAI an der Entdeckung beteiligt waren, und weist darauf hin, dass Angreifer mit KI-gestützten Werkzeugen Patches in kurzer Zeit analysieren und Exploits erzeugen können.⁴ heise rechnet damit, dass vorsorgliche Abschaltungen künftig häufiger zu sehen sein werden.⁹ Unsere Einordnung: Lagen wie php2shell werden häufiger auftreten. Mit einem eingeübten Ablauf bleiben sie beherrschbar, und jede Übung macht das Haus sicherer.

Nachweis: Festgelegte Warnquellen mit Empfängern und Vertretung; Bewertungsregel, ab wann die Leitung informiert wird; Zeitstempel von Eingang und Bewertung der letzten kritischen Meldung.

BerichtetBelege 4, 8, 9, 10

03Kapitel 3 von 4

Klar entscheiden und melden: die ersten 72 Stunden

Wie gelingt es, in einer Nacht wie der vom 21. Oktober schnell und gut begründet zu entscheiden, ob der Webshop online bleibt?

Am 21. Oktober standen viele Häuser vor derselben Wahl. Das BSI hält nach aktuellem Stand nur zwei Maßnahmen für vollständig wirksam: patchen oder vom Internet trennen. Übergangsmaßnahmen der Entwickler und Regeln in einer Web Application Firewall erschweren die Ausnutzung, schließen sie aber nicht aus.⁴ ProSec Defense argumentiert, dass eine Abschaltung Abläufe und Wertschöpfung stört und die Lücke nicht löst, und beschreibt ein zweistufiges Vorgehen aus Schutzregel und geprüftem Notfall-Patch.²²

Die Wahl ist eine Risikoentscheidung der Leitung

Unsere Einordnung: Beide Positionen sind vereinbar, wenn man die Entscheidung dort trifft, wo sie hingehört. Wer eine verwundbare Website online lässt und durch eine Schutzregel absichert, akzeptiert ein Restrisiko, das das BSI ausdrücklich benennt. Wer sie abschaltet, akzeptiert einen Betriebsausfall. Beides ist eine Abwägung zwischen Risiken, und § 30 Abs. 1 BSIG verlangt, dass die Maßnahmen verhältnismäßig sind und die Risikoexposition, die Eintrittswahrscheinlichkeit, die Schwere und die Auswirkungen berücksichtigen.¹¹ Diese Abwägung trifft am besten jemand mit Befugnis, der auf Grundlage der Business-Impact-Analyse befristet und schriftlich entscheidet. Das entlastet auch den Administrator, der um zwei Uhr nachts am System arbeitet.

Nachweis: Entscheidungsvermerk je betroffenem System: Option, Begründung, Entscheider, Uhrzeit, Frist für Wiedervorlage.

EinordnungBelege 2, 4, 11, 22

Was zu melden ist, und was nicht

Eine Schwachstelle ist noch kein Sicherheitsvorfall. § 32 BSIG verpflichtet besonders wichtige und wichtige Einrichtungen, einen erheblichen Sicherheitsvorfall zu melden: binnen 24 Stunden nach Kenntnis eine frühe Erstmeldung, binnen 72 Stunden eine Meldung mit erster Bewertung, einen Monat danach eine Abschlussmeldung.¹² Unsere Einordnung: Die bloße Betroffenheit von php2shell löst diese Frist nicht aus. Findet die Prüfung auf Kompromittierung aber Spuren eines Eindringens, kann sie laufen, und zwar ab dem Zeitpunkt, an dem Ihr Haus davon Kenntnis hat. Ob eine längere vorsorgliche Abschaltung eines kritischen Dienstes als erhebliche Betriebsstörung zu werten ist, ist im Einzelfall zu prüfen und zu dokumentieren. Sind personenbezogene Daten betroffen, läuft daneben die 72-Stunden-Frist des Art. 33 DSGVO.²³

Für Hersteller gilt ein zweiter, eigener Regelkreis. Seit dem 11. September 2026 meldet ein Hersteller jede aktiv ausgenutzte Schwachstelle in seinem Produkt gleichzeitig dem koordinierenden CSIRT und der ENISA über die einheitliche Meldeplattform: Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden, Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Korrektur.¹⁶ Das gilt nach Art. 69 Abs. 3 auch für Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden.¹⁸ Wer eine Firewall, ein Speichersystem oder eine Software mit eingebautem PHP verkauft, hat die Schwachstelle damit in seinem Produkt.

Eine Schwachstelle gilt nach Art. 3 Nr. 42 CRA als aktiv ausgenutzt, wenn „verlässliche Nachweise“ vorliegen, dass ein böswilliger Akteur sie in einem System ohne Zustimmung des Eigners ausgenutzt hat.¹⁴ Unsere Einordnung: Am 22. Oktober sind Angriffsversuche in großer Zahl berichtet, eine erfolgreiche Ausnutzung aber nicht belegt; CISA hatte bei Veröffentlichung keine Ausnutzung beobachtet.^{6, 8, 9} Ob und wann die Schwelle erreicht ist, muss jeder Hersteller für sein Produkt bewerten, laufend und mit Zeitstempel. Die Frist beginnt mit der Kenntnis, etwa wenn ein Kunde eine Kompromittierung meldet oder die eigene Produktsicherheit (PSIRT) eine feststellt. Unabhängig davon müssen Hersteller Schwachstellen in eingebauten Komponenten nach Art. 13 Abs. 6 behandeln und beheben und den Nutzern Sicherheitsaktualisierungen unverzüglich und kostenlos bereitstellen.^{15, 17}

RechtstextBelege 12, 14, 15, 16, 18, 23

Ein Ablauf, der Ruhe gibt

Unsere Einordnung: In einer Lage mit Stundenfristen gibt ein vorher beschlossener Ablauf allen Beteiligten Sicherheit. Er ordnet jedem Schritt eine Rolle zu und lässt die Leitung dort entscheiden, wo Budget, Betrieb oder Haftung berührt sind.

Nachweis: Beschlossener Ablauf mit Rollen und Vertretung; Protokoll der letzten Lage mit Zeitstempeln von Kenntnis, Betroffenheit, Entscheidung, Schutz.

EinordnungBelege 8, 12, 16

04Kapitel 4 von 4

Wie die Geschäftsleitung ihr Haus handlungsfähig macht

Welche wenigen Zahlen zur Software-Lieferkette helfen einer Geschäftsleitung, gut zu steuern?

§ 38 BSIG verpflichtet die Geschäftsleitungen besonders wichtiger und wichtiger Einrichtungen, die Risikomanagementmaßnahmen nach § 30 umzusetzen und ihre Umsetzung zu überwachen. Das Gesetz knüpft daran eine Haftung nach den Regeln des Gesellschaftsrechts und sieht regelmäßige Schulungen der Geschäftsleitung vor, damit sie Risiken und ihre Auswirkungen auf die eigenen Dienste beurteilen kann. Eine Leitung, die ihre Vorgaben dokumentiert und überwacht, kann jederzeit zeigen, dass sie ihrer Verantwortung gerecht wird.¹³ Mehr zur persönlichen Haftung steht in unserem Ratgeber zur Geschäftsführerhaftung nach § 38.

Für Hersteller kommt der CRA hinzu: Verstöße gegen die Anforderungen des Anhangs I oder gegen die Pflichten aus Art. 13 und 14 können mit bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes geahndet werden, je nachdem, welcher Betrag höher ist.¹⁸ Das deutsche Durchführungsgesetz, das Zuständigkeit und Bußgeldverfahren regelt, hat der Bundestag noch nicht verabschiedet; es liegt dort als Regierungsentwurf (Stand 22.10.2026). Die Pflichten selbst gelten unabhängig davon, denn die Verordnung wirkt unmittelbar.¹⁹

RechtstextBelege 13, 18, 19

Die Dauer der Verwundbarkeit liegt in Ihrer Hand

Unsere Einordnung: Lücken in Komponenten, die die halbe Welt nutzt, wird es immer wieder geben. Wie lange das eigene Haus verwundbar bleibt, kann jedes Unternehmen selbst gestalten. Dieses Fenster setzt sich aus drei Strecken zusammen, die alle in der Hand der Organisation liegen:

Sechs Hebel der Geschäftsleitung

Bei den Lieferantenpflichten lohnt ein genauer Blick auf den CRA. Er verpflichtet Hersteller, einen Unterstützungszeitraum von in der Regel mindestens fünf Jahren festzulegen und Sicherheitsaktualisierungen kostenlos bereitzustellen.^{15, 17} Unsere Einordnung: Für Betreiber wird das ab Dezember 2027 zu einem starken Hebel im Einkauf. Wer Stückliste, Meldeweg und Supportzeitraum schon heute vertraglich vereinbart, nutzt diesen Vorteil früher. Altverträge lassen sich bei der nächsten Verlängerung nachziehen.

Vier Kennzahlen, die eine Geschäftsleitung sehen sollte

1. AbdeckungAnteil der Systeme und Produkte mit aktueller Stückliste
2. Zeit bis WissenStunden von der Warnung bis zur festgestellten Betroffenheit
3. Zeit bis SchutzStunden bis Patch oder dokumentierte Überbrückung bei kritischen Lücken
4. AltlastZahl der Systeme ohne Herstellerunterstützung, mit Ablösedatum

Unsere Einordnung: php2shell eignet sich gut als Ausgangswert. Wer heute festhält, wann Warnung, Betroffenheit, Entscheidung und Schutz je System erreicht waren, hat den ersten belastbaren Wert für alle vier Kennzahlen. Beim nächsten Fall lässt sich dann zeigen, wie viel schneller das Haus geworden ist.

Nachweis: Beschluss der Geschäftsleitung zu Fristen und Befugnissen; Vertragsklauseln zu SBOM und Meldung; EOL-Register mit Risikoakzeptanzen; Kennzahlenbericht mit Datum; Teilnahmenachweis der Leitung an Schulungen nach § 38 Abs. 3.

EinordnungBelege 2, 8, 11, 13, 15, 17