Kurz gesagt: Die Lieferkette einer Website reicht vom PHP-Projekt über Distribution und Hoster bis zu CMS, Plugins, Agentur und eingebundenen Diensten. Für die IT-Sicherheit zählt jedes Glied, denn ein Patch erreicht Ihre Website erst, wenn alle ihn weitergegeben haben. Wer die Kette aufschreibt, für jedes Glied eine zuständige Stelle und einen Nachweis festlegt und Zugänge begrenzt, macht sie belastbar.
Ein Patch und seine lange Reise
Am 21.10.2026 um 14:00 UTC veröffentlichte das PHP-Projekt die Korrekturen für PHP2Shell. Damit war die Lücke für keine einzige Website geschlossen. Zunächst mussten Distributionen wie Debian, Ubuntu oder die RHEL-Familie die Korrekturen in ihre Pakete übernehmen; laut Berichten wurden Backports teils noch am selben Tag ausgeliefert. Dann mussten Hoster und Admins diese Pakete installieren und alle PHP-Prozesse neu starten. Erst danach war die jeweilige Website geschützt.
Jedes Glied in dieser Kette kann verzögern. Und an jedem hängt eine andere Organisation mit eigenen Prioritäten. Wer nicht weiß, wie seine Kette aussieht, kann nicht sagen, wo der Patch gerade steckt.
Manche Ketten haben zusätzliche Glieder, die kaum jemand kennt. Viele Debian- und Ubuntu-Server beziehen PHP nicht aus der Distribution, sondern aus dem Repository von Ondřej Surý auf sury.org, einer verbreiteten Drittquelle. Laut Berichten hat sie Builds für alle Zweige von 5.6 bis 8.5 bereitgestellt. Das ist hilfreich, aber es ist nicht das Sicherheitsarchiv von Debian: Wer diese Quelle nutzt, hängt an einem anderen Glied, mit eigenem Takt und eigener Verantwortung. Ob ein Server so eingerichtet ist, zeigt die Liste der Paketquellen, und genau diese Information gehört in die Dokumentation der Kette.
Die Glieder der Lieferkette im Überblick
Die folgende Tabelle zeigt die typischen Glieder einer PHP-Website und was Sie von jedem verlangen können.
| Glied | Typisches Risiko | Was Sie festlegen sollten |
|---|---|---|
| PHP-Projekt | Lücke im Interpreter, Ende des Supports | unterstützte Version im Einsatz, Plan für Supportende |
| Distribution oder Drittquelle | Backport fehlt oder kommt spät | bekannte Paketquelle, Sicherheitsmeldungen abonniert |
| Hoster oder Plattformdienst | Update ohne Neustart, keine Information | Pflicht zu Update, Neustart, Nachweis und Benachrichtigung |
| CMS-Hersteller | Lücke im Kern | Update-Kanal, zuständige Person |
| Plugin- und Theme-Anbieter | aufgegebene oder unsichere Erweiterungen | nur gepflegte Plugins aus offiziellen Quellen |
| Agentur oder Entwickler | weitreichende Zugänge, unklare Zuständigkeit | persönliche Zugänge, schriftliche Aufgaben |
| Externe Skripte und Dienste | fremder Code im Browser, Datenabfluss | Liste, feste Versionen, Zweck geprüft |
Zwei Beispiele aus der PHP2Shell-Woche zeigen, wie leicht ein Glied übersehen wird. Vercel weist darauf hin, dass ein Update der lokalen Entwicklungsumgebung, des Anwendungscodes oder der Plugins nicht reicht; entscheidend ist die PHP-Laufzeit, die tatsächlich ausliefert. Coolify rät, die PHP-Laufzeit jeder Anwendung einzeln zu aktualisieren, auch hinter Cloudflare. Und laut Berichten plant WordPress.org kein eigenes Update gegen PHP2Shell, weil die Lücke im Interpreter liegt. Wer auf das CMS wartet, wartet vergeblich.
Die Kette sichtbar machen: fünf Schritte
So bringen Sie Ordnung in die Abhängigkeiten Ihrer Websites:
- Kette je Website aufschreiben: von der PHP-Laufzeit bis zu externen Skripten, mit Name des Anbieters oder der Person.
- Zuständigkeit je Glied festlegen: Wer spielt Updates ein, wer prüft, wer informiert wen?
- Nachweise vereinbaren: Was gilt als erledigt? Bei der PHP-Laufzeit etwa Paketstand und Neustart, wie unter So fragen Sie Ihren Hoster nach dem Patch-Status beschrieben.
- Zugänge begrenzen: Jede Agentur und jeder Dienstleister bekommt nur die Rechte, die er braucht, mit persönlichen Konten.
- Ausweichwege planen: Was tun, wenn ein Glied ausfällt, etwa ein Plugin-Anbieter aufgibt oder ein Dienstleister nicht erreichbar ist?
Fragen Sie jeden Dienstleister, wie er Sie über kritische Lücken informiert. Wer nur auf Nachfrage antwortet, ist in einer Lage wie PHP2Shell ein Risiko für Ihren Zeitplan. Halten Sie die Antwort schriftlich fest.
Plugins und Erweiterungen: die unübersichtlichste Stelle
Bei vielen Websites ist der größte Teil der Lieferkette unsichtbar: Plugins und Themes, die über die Jahre hinzugekommen sind. Jedes stammt von einem anderen Anbieter, mit eigenem Tempo bei Sicherheitsupdates. Manche Anbieter geben ihr Produkt auf, ohne es anzukündigen. Andere Erweiterungen werden aus inoffiziellen Quellen bezogen und erhalten nie Updates.
Hier hilft eine einfache Regel: Jedes Plugin braucht einen Zweck, einen gepflegten Anbieter und eine offizielle Bezugsquelle. Fehlt eines davon, kommt es auf die Liste zum Ersetzen. Ähnliches gilt für eingebundene Dienste wie Zahlungsanbieter, Buchungssysteme, Chat-Fenster oder Analysewerkzeuge. Sie bringen eigenen Code auf Ihre Seite oder erhalten Daten Ihrer Besucher. Halten Sie fest, welche Dienste eingebunden sind, wer sie beauftragt hat und ob sie noch gebraucht werden. Ein vergessenes Skript eines Anbieters, mit dem längst kein Vertrag mehr besteht, ist ein Glied ohne Verantwortlichen.
Wie Sie Plugins und Pakete dauerhaft aktuell halten, beschreibt Abhängigkeiten aktuell halten: Composer, npm und Plugins.
Lieferkette, Verträge und NIS2
Für Unternehmen, die unter NIS2 fallen, gehört die Sicherheit der Lieferkette ausdrücklich zum Risikomanagement, also auch die Beziehungen zu Dienstleistern und Anbietern. Einzelheiten stehen unter NIS2 und Webserver-Sicherheit. Doch auch ohne gesetzliche Pflicht gilt: Ausgelagerte Aufgaben bleiben Ihr Risiko. Deshalb gehören die Ergebnisse der fünf Schritte in die Verträge mit Agentur, Hoster und Dienstleistern; welche Punkte dort geregelt werden sollten, beschreibt IT-Dienstleister-Verträge: Sicherheitspflichten klar regeln. Diese Seite ist allgemeine Information und keine Rechtsberatung.
Wie hilft PHP SOS konkret?
- Wir zeichnen mit Ihnen die Lieferkette jeder Website auf, von der PHP-Laufzeit bis zu externen Skripten.
- Wir prüfen Plugins, Themes und Pakete auf Pflegezustand und Herkunft und empfehlen Ersatz, wo nötig.
- Wir stimmen mit Hoster und Agentur ab, wer welche Glieder verantwortet und welche Nachweise geliefert werden.
- Wo ein Glied unbesetzt ist, übernehmen wir es dauerhaft über einen Security-Wartungsvertrag.
Fazit: Die Sicherheit einer Website ist so stark wie das langsamste Glied ihrer Lieferkette. Wer die Kette kennt und jedes Glied mit einer zuständigen Stelle und einem Nachweis verknüpft, weiß im Ernstfall, wo der Patch steckt.
Häufige Fragen
Was bedeutet Lieferkette bei einer Website?
Alle Beteiligten, von deren Arbeit die Sicherheit Ihrer Website abhängt: das PHP-Projekt, die Linux-Distribution, Hoster oder Plattformdienst, CMS-Hersteller, Plugin- und Theme-Anbieter, die Agentur und eingebundene Dienste wie Zahlungsanbieter oder externe Skripte.
Bin ich verantwortlich, wenn ein Dienstleister nicht patcht?
Die Verantwortung für die eigene Website und die Daten darauf bleibt in der Regel bei Ihnen, auch wenn Aufgaben ausgelagert sind. Deshalb sollten Zuständigkeiten vertraglich klar sein und überprüft werden. Für die rechtliche Bewertung sind Anwalt und Datenschutzbeauftragter zuständig.
Reicht es, wenn der Hoster PHP aktualisiert?
Für die PHP-Laufzeit beim Hoster ja, sofern er auch alle Prozesse neu startet und das belegt. Laufen Teile Ihrer Anwendung anderswo, etwa in Containern, auf Plattformdiensten oder auf einem zweiten Server, muss dort jede Laufzeit einzeln aktualisiert werden.
Wie erkenne ich riskante Plugins?
Warnzeichen sind lange keine Updates, ein Anbieter ohne erkennbaren Sicherheitskontakt, Bezug aus inoffiziellen Quellen und Funktionen, die niemand mehr nutzt. Solche Plugins sollten ersetzt oder entfernt werden.