PHP2Shell: Schätzl fordert das BSI, gemeint ist der CRA

Von /

Zwei Tage nach PHP2Shell beginnt die Phase, in der die Politik Konsequenzen fordert. Johannes Schätzl, digitalpolitischer Sprecher der SPD-Bundestagsfraktion, verlangt laut Golem ein starkes BSI, das Schwachstellen frühzeitig erkennt, Maßnahmen einleitet und Betreiber aktiv unterstützt, dazu KI-Werkzeuge und eine grundlegende Neuaufstellung der Cyberabwehr. Der Satz, der hängen bleibt: Mit Updates einer bekanntgewordenen Sicherheitslücke hinterherzulaufen, könne nicht unsere Antwort sein.

Ich habe gestern aufgeschrieben, was bei PHP2Shell tatsächlich passiert ist. Wer das gelesen hat, merkt schnell, dass Schätzls Forderung auf die falsche Behörde zielt. Das BSI hat am 21. Oktober genau das getan, wofür es da ist. Das Problem lag zwei Jahre lang woanders, und für dieses Woanders gibt es seit Dezember 2024 ein EU-Gesetz, das kaum jemand erwähnt.

Was das BSI bei PHP2Shell gemacht hat, und was nicht

Zur Erinnerung: Das PHP-Projekt hat seine Vorankündigung am 20. Oktober um 19:30 UTC veröffentlicht. Das BSI hat am 21. Oktober seine Cybersicherheitswarnung BITS-H 2026-297981-1032 mit Stufe Orange herausgegeben, noch bevor der Patch da war, mit CVSS-Einordnung, Patch-Zeitpunkt und der Empfehlung, Server notfalls vom Netz zu trennen. Am Abend kam Version 1.1 mit den Advisories nach. Mehrere Länder, Städte und der Bund sind dem gefolgt, und Digitalminister Wildberger nannte die Abschaltung der Bundes-Webseiten laut dpa eine richtige Entscheidung.

Das ist, nüchtern betrachtet, ein funktionierender Warnprozess. Schneller als die Hersteller-Vorankündigung geht es nicht, denn die Lücke war bis dahin unter Embargo. Schätzl fordert nun ein BSI, das Schwachstellen „frühzeitig erkennt”. Frühzeitig erkannt wurde PHP2Shell aber bereits. Laut dem Statement der PHP Foundation fand ein Core-Entwickler die ersten Anzeichen 2024 beim Aufräumen nach einem externen Audit. Der Fix lag danach zwei Jahre in einem Konsensverfahren, weil ein kleines Team sich nicht zwischen drei unangenehmen Varianten entscheiden konnte und niemand Zeit hatte.

Was hätte ein stärkeres BSI daran geändert? Nichts. Das BSI schreibt keine Zend-Engine. Es kann sie auch nicht patchen, nicht reviewen und nicht gegen tausende Third-Party-Extensions testen. Die Entscheidung, welcher von drei Fixes das Ökosystem am wenigsten zerlegt, trifft niemand in Bonn, und das ist auch gut so.

Wer die Software herstellt, trägt die Verantwortung

Schätzl sagt selbst, Sicherheit liege in der Verantwortung jeder Behörde und jedes Unternehmens. Das ist richtig, aber unvollständig. Vor der Behörde, die PHP betreibt, steht der Hersteller, der PHP in sein Produkt eingebaut hat. Golem zitiert den Verband eco mit dem Hinweis, dass PHP in Routern, Speichersystemen und Sicherheitsprodukten steckt, oft ohne dass die Betreiber es wissen. Genau das ist der Punkt. Eine Kommune, deren Fachverfahren oder NAS-Oberfläche im Hintergrund auf PHP 7.4 läuft, kann die Lücke nicht erkennen, weil sie nicht weiß, dass sie da ist. Der Hersteller weiß es. Oder müsste es wissen.

Und dafür gibt es seit dem 10. Dezember 2024 den Cyber Resilience Act, die Verordnung (EU) 2024/2847. Er gilt in voller Breite ab dem 11. Dezember 2027, aber die Meldepflichten nach Artikel 14 gelten bereits seit dem 11. September 2026, also seit sechs Wochen. Hersteller von Produkten mit digitalen Elementen müssen aktiv ausgenutzte Schwachstellen binnen 24 Stunden an die ENISA und die nationalen CSIRTs melden. Das CSIRT in Deutschland ist das BSI. Wer also ein Produkt mit eingebettetem PHP verkauft, war seit Mittwoch meldepflichtig, sobald er von einer Ausnutzung erfuhr.

Dazu kommt die Software-Stückliste. Anhang I Teil II des CRA verlangt von Herstellern, die Komponenten ihrer Produkte zu dokumentieren, in einem maschinenlesbaren Format, das mindestens die obersten Abhängigkeiten abdeckt. Das BSI hat dafür mit der TR-03183 Teil 2 längst eine Vorgabe geschrieben. Eine SBOM ist genau das Werkzeug, das am 21. Oktober gefehlt hat: ein Dokument, aus dem ein Betreiber in fünf Minuten ablesen kann, ob PHP drinsteckt und welche Version. Dass die Pflicht erst ab Ende 2027 vollständig greift, ist ein Terminproblem, kein Konzeptproblem. Die Antwort auf PHP2Shell steht im Gesetz, sie ist nur noch nicht in Kraft.

Der CRA kennt sogar die PHP Foundation

Der CRA hat auch an den Fall gedacht, der bei PHP2Shell im Zentrum stand: eine Stiftung, die eine frei verfügbare Sprache pflegt, mit der andere Geld verdienen. Artikel 24 schafft dafür die Rolle des Open-Source-Software-Stewards. Stewards unterliegen einem leichteren Regime als Hersteller, müssen aber eine dokumentierte, überprüfbare Cybersicherheitsstrategie haben, die beschreibt, wie Schwachstellen behandelt, behoben und in der Community geteilt werden, und sie müssen mit den Marktüberwachungsbehörden kooperieren.

Lesen Sie das noch einmal mit dem Foundation-Statement daneben. Die Foundation räumt ein, dass ihr Entscheidungsprozess im Konsens über Monate blockiert war und erst nach August 2026 auf Mehrheitsentscheidungen umgestellt wurde. Genau diesen Prozess soll ein Steward nach Artikel 24 schriftlich haben. Der CRA adressiert das Versagen von PHP2Shell also schon, nur nicht beim BSI, sondern dort, wo es entstanden ist. Und er nimmt die Bußgelder für Stewards ausdrücklich heraus, weil der Gesetzgeber verstanden hat, dass man eine unterfinanzierte Stiftung nicht mit Strafen besser macht.

Die Frage, die Schätzl nicht stellt: Wer bezahlt

Die Foundation hat die 2024er-Audit-Runde nicht selbst bezahlt. Das war die Sovereign Tech Agency des Bundes mit 205.000 Euro für 2023 und 2024, für Audit, Extension-Infrastruktur, Dokumentation und Testwerkzeuge. Der Audit fand laut php.net 27 Punkte, 17 davon sicherheitsrelevant, vier CVEs. Und beim Aufräumen fiel die Lücke auf, die jetzt PHP2Shell heißt.

Das ist die Pointe, die in der Debatte fehlt: Der Bund hat das Richtige getan. Er hat Geld in die Hand genommen, der Audit hat geliefert, das Problem wurde gefunden. Was danach fehlte, war die Kontinuität, also jemand, der zwei Jahre lang bezahlt wird, um den Fund zu Ende zu bringen. Die Foundation schreibt im Statement wörtlich, ohne ihre Finanzierung wäre es unmöglich gewesen, mehrere Leute Vollzeit auf das Thema zu setzen. Das heißt im Umkehrschluss: Mit mehr Finanzierung wäre es 2024 möglich gewesen.

Schätzl will mehr Geld und Personal für das BSI. Ich will das auch, das BSI hat seit dem NIS-2-Umsetzungsgesetz vom 6. Dezember 2025 mit dem neuen BSIG deutlich mehr Aufsichtsaufgaben und braucht dafür Leute. Aber ein Euro im BSI schließt keine Lücke in PHP. Ein Euro in der Sovereign Tech Agency oder direkt bei der Foundation tut das. Wer die Cyberabwehr „grundlegend neu aufstellen” will, sollte mit der Frage anfangen, warum 70 Prozent des Webs auf einer Sprache laufen, deren Security-Team laut eigener Aussage aus einer Handvoll bezahlter Entwickler und etwas ehrenamtlicher Hilfe besteht.

Die Gegenposition: Was an Schätzls Forderung stimmt

Fairerweise: Schätzl hat an zwei Stellen recht. Erstens schrumpft das Zeitfenster zwischen Patch und Angriff tatsächlich. Cloudflare-Chef Matthew Prince hat auf X beschrieben, wie die Angriffsversuche von tausenden vor der Veröffentlichung auf Millionen am nächsten Morgen stiegen. Wenn KI Exploits in Stunden baut, reicht ein Patch-Zyklus von Tagen nicht mehr. Da hat er einen Punkt, und eco-Vorstand Norbert Pohlmann sagt laut Golem dasselbe.

Zweitens ist ein BSI, das Betreiber aktiv unterstützt, statt nur zu warnen, eine sinnvolle Forderung. Die Niederlande haben laut Borncity über ihr NCSC ein öffentliches GitHub-Repository mit Erkennungswerkzeugen und Härtungshinweisen zu PHP2Shell veröffentlicht. So etwas vom BSI wäre am Mittwoch für viele Admins wertvoller gewesen als die dritte Pressemitteilung.

Nur folgt aus beidem nicht, dass das BSI Schwachstellen „frühzeitig erkennen” soll. Erkannt war sie. Was fehlte, war ein Prozess beim Hersteller, der den Fund in einen Fix verwandelt, und ein Dokument beim Betreiber, das sagt, wo das Produkt betroffen ist. Für beides steht die Regel im CRA. Dass das Wort in Schätzls Statement nicht vorkommt, ist das eigentliche Problem daran.

Was stattdessen zu fordern wäre

Wenn ich eine Forderung formulieren müsste, wäre es diese: Erstens, der Bund sorgt dafür, dass die Sovereign Tech Agency aus Einzelprojekten eine Dauerfinanzierung für die Software macht, auf der seine eigenen Portale laufen. Die Foundation hat am Mittwoch Regierungen ausdrücklich um genau das gebeten. Zweitens, das BSI nutzt seine Rolle als CSIRT unter dem CRA, um die Meldepflicht ab September 2026 bei Herstellern eingebetteter PHP-Produkte tatsächlich durchzusetzen, statt nur Warnungen zu schreiben. Drittens, öffentliche Auftraggeber verlangen in Ausschreibungen schon jetzt eine SBOM, ein Jahr bevor der CRA sie vorschreibt, denn nichts hindert sie daran.

Das ist weniger spektakulär als eine „grundlegende Neuaufstellung der Cyberabwehr”. Es hätte am Mittwoch aber funktioniert.

Fazit

PHP2Shell war kein Versagen des BSI. Es war ein Versagen beim Hersteller, der einen bekannten Fund zwei Jahre nicht fixen konnte, und bei Betreibern, die nicht wussten, wo PHP bei ihnen läuft. Für das erste kennt der CRA den Open-Source-Steward und die Meldepflicht, für das zweite die SBOM. Beides gilt teils seit September, vollständig ab Ende 2027. Wer jetzt nach dem BSI ruft, verlangt von der Feuerwehr, dass sie die Bauordnung schreibt.

Herr Schätzl ist Informatiker mit Berufspraxis in der IT-Branche. Er weiß, dass man eine Engine nicht per Behördenauftrag patcht. Die richtige Forderung liegt auf seinem Tisch, sie heißt Cyber Resilience Act und Dauerfinanzierung für Open Source. Ich würde ihn bitten, beim nächsten Interview mit dem Handelsblatt dieses Wort zu benutzen.

Quellen:

Nach oben scrollen