Kurz gesagt: Wer Abhängigkeiten aktualisieren will, braucht einen Prozess für drei Paketwelten: Composer-Pakete im PHP-Code, npm-Module im Frontend-Build und Plugins oder Themes im CMS. Dazu gehören ein fester Rhythmus, eine verantwortliche Person, Tests vor dem Ausrollen und ein Plan für Pakete ohne Update. Gegen PHP2Shell hilft das nicht, denn diese Lücke steckt in PHP selbst, aber gegen die vielen Lücken in fremdem Code.
Drei Paketwelten, ein blinder Fleck
In der Woche nach dem 21.10.2026 drehte sich alles um den PHP-Interpreter. Viele Teams haben dabei gemerkt, dass sie die Versionen ihrer eigenen Bausteine nicht genau kennen. Die Website läuft, die Agentur kümmert sich, das Plugin meldet sich schon, wenn es etwas Neues gibt: So oder ähnlich lauten die Annahmen, bis jemand nachsieht.
Ein typisches PHP-Projekt besteht heute aus deutlich mehr fremdem als eigenem Code. Die OWASP Top 10 führen verwundbare und veraltete Komponenten als eigene Risikokategorie. Das Problem ist selten das fehlende Werkzeug, sondern die fehlende Routine: Updates passieren, wenn jemand Zeit hat, und Sicherheitsmeldungen landen in einem Postfach, das niemand liest.
Welche Abhängigkeiten aktualisieren Sie wo?
Jede Paketwelt hat eigene Werkzeuge und eigene Fallstricke. Die folgende Übersicht hilft, nichts zu übersehen.
| Paketwelt | Bestand anzeigen | Lücken prüfen | Typischer Fallstrick |
|---|---|---|---|
| Composer (PHP-Bibliotheken) | composer show |
composer audit |
indirekte Pakete, die niemand kennt |
| npm (Frontend-Build) | npm ls |
npm audit |
Update ohne Neubau erreicht den Server nie |
| CMS-Plugins und Themes | Admin-Oberfläche oder CLI | Herstellerhinweise, Sicherheitsdienste | aufgegebene Plugins, Kaufplugins ohne Update-Kanal |
| PHP und Erweiterungen | Paketverwaltung | Security-Tracker der Distribution | angezeigte Version sagt wenig über Backports |
Die letzte Zeile gehört streng genommen nicht zu den Abhängigkeiten der Anwendung, wird aber oft im selben Atemzug vergessen. Gleiches gilt für Skripte, die direkt von fremden Servern eingebunden werden, etwa Bibliotheken aus einem CDN, Chat-Widgets oder Tracking-Code. Sie tauchen in keiner Lock-Datei auf, laufen aber im Browser Ihrer Besucher. Nehmen Sie sie mit in die Liste und prüfen Sie, ob feste Versionen statt „immer die neueste“ eingebunden sind. Die Details zu composer audit, Lock-Datei und Einbindung in den Build stehen im Ratgeber Composer-Abhängigkeiten auf Lücken prüfen. Wie Composer grundsätzlich arbeitet, erklärt Composer: Die Paketverwaltung für PHP.
Der Wartungszyklus in sechs Schritten
Ein tragfähiger Prozess muss nicht kompliziert sein. Diese Reihenfolge hat sich bewährt:
- Bestand festhalten: Für jedes Projekt eine Liste der direkten Abhängigkeiten mit Version, Herkunft und Zweck. Lock-Dateien (
composer.lock,package-lock.json) gehören ins Repository. - Meldungen sammeln: Prüfwerkzeuge laufen bei jedem Build und zusätzlich regelmäßig auf dem ausgelieferten Stand, auch ohne Codeänderung.
- Bewerten: Wird das betroffene Paket im Produktivbetrieb genutzt, ist die betroffene Funktion erreichbar, gibt es eine behobene Version?
- In Staging aktualisieren und testen: Erst Sicherheitsupdates innerhalb derselben Hauptversion, Sprünge auf neue Hauptversionen als eigenes Vorhaben planen.
- Ausrollen mit Rückweg: Vorheriger Stand bleibt als Paket oder Release verfügbar, Datenbank-Backup vor dem Update.
- Dokumentieren: Was wurde wann aktualisiert, was bewusst nicht und warum.
Achten Sie dabei auf die Versionsangaben in composer.json und package.json. Zu enge Vorgaben verhindern, dass Sicherheitskorrekturen überhaupt installiert werden können. Zu weite Vorgaben holen dagegen ungeprüft neue Hauptversionen ins Projekt. Bewährt hat sich, Updates innerhalb der Hauptversion zu erlauben und den Sprung auf die nächste bewusst zu planen.
Für Plugins im CMS lassen sich verfügbare Updates oft auch auf der Kommandozeile anzeigen, bei WordPress etwa mit WP-CLI:
# Verfügbare Updates anzeigen, ohne etwas zu ändern
wp plugin list --update=available
wp theme list --update=available
# Frontend-Pakete: veraltete Versionen und bekannte Lücken
npm outdated
npm audit --omit=dev
Automatische Plugin-Updates direkt auf dem Produktivsystem sind bequem, aber riskant, wenn niemand danach prüft. Schalten Sie sie nur ein, wenn ein Backup vor jedem Lauf und eine Kontrolle danach sichergestellt sind.
Wenn es kein Update gibt
Nicht jede Meldung lässt sich mit einem Klick lösen. Das OWASP Cheat Sheet zum Umgang mit verwundbaren Abhängigkeiten unterscheidet mehrere Fälle, die sich gut auf den Alltag übertragen lassen:
- Patch verfügbar: in Staging einspielen, testen, ausrollen. Bricht etwas, den eigenen Code anpassen statt das Update liegen zu lassen.
- Patch angekündigt, aber noch nicht da: Workaround des Herstellers umsetzen, betroffene Funktion wenn möglich abschalten oder abschirmen, Entscheidung festhalten.
- Kein Patch zu erwarten: Ersatzpaket suchen oder den Fix selbst zurückportieren, mit Test, der die Lücke vor und nach dem Patch unterscheidet.
Bei CMS-Plugins kommt ein vierter Fall häufig vor: Das Plugin ist aufgegeben. Dann hilft nur Ersatz oder Entfernung. Gleiches gilt für Plugins aus unklaren Quellen, etwa „kostenlose“ Kopien von Kaufplugins. Sie erhalten keine Updates über den offiziellen Kanal und enthalten nicht selten selbst Schadcode. Hinweise für WordPress-Betreiber bündelt WordPress und PHP2Shell.
Zuständigkeit klären, bevor die nächste Meldung kommt
Der häufigste Grund für veraltete Pakete ist keine technische Hürde, sondern eine offene Frage: Wer macht es? Bei Projekten, die eine Agentur gebaut hat und die intern betrieben werden, fühlt sich oft niemand zuständig. Legen Sie für jedes Projekt fest, wer Meldungen erhält, wer bewertet und wer freigibt, und schreiben Sie es auf.
Planen Sie außerdem Zeit ein. Ein fester Wartungstermin im Monat, an dem Abhängigkeiten geprüft und aktualisiert werden, verhindert, dass sich Updates über Jahre stauen. Je länger ein Projekt nicht aktualisiert wurde, desto größer und riskanter wird der nächste Sprung. Wie sich Updates von PHP und Paketen in einen übergreifenden Ablauf einfügen, beschreibt Patch-Management als Prozess statt Feuerwehr.
Wie hilft PHP SOS konkret?
- Wir erfassen alle Abhängigkeiten Ihrer Projekte aus Composer, npm und CMS und markieren veraltete, verwundbare und aufgegebene Pakete.
- Wir richten automatische Prüfungen ein und legen fest, wer welche Meldung bewertet.
- Wir aktualisieren in Staging, testen die wichtigsten Abläufe und rollen mit Rückweg aus.
- Im Rahmen eines Security-Wartungsvertrags übernehmen wir den monatlichen Zyklus dauerhaft, PHP-Updates eingeschlossen.
Fazit: Aktuelle Abhängigkeiten sind kein Projekt, sondern Routine. Wer Bestand, Rhythmus und Zuständigkeit einmal sauber regelt, muss bei der nächsten großen Meldung nur noch prüfen, nicht erst suchen.
Häufige Fragen
Wie oft sollte man Abhängigkeiten aktualisieren?
Sicherheitsupdates so bald wie möglich nach Bewertung, Routine-Updates in einem festen Rhythmus, etwa monatlich. Wichtiger als die genaue Frequenz ist, dass der Termin feststeht und jemand dafür zuständig ist.
Schützt ein aktuelles Plugin vor PHP2Shell?
Nein. PHP2Shell steckt im PHP-Interpreter selbst. Dagegen hilft nur ein PHP-Update mit Neustart aller PHP-Prozesse. Aktuelle Plugins und Pakete sind trotzdem wichtig, weil sie eigene Lücken schließen.
Was mache ich mit einem Plugin, das nicht mehr gepflegt wird?
Ersetzen oder entfernen. Ein aufgegebenes Plugin bekommt keine Korrekturen mehr, auch wenn es heute noch funktioniert. Bis zum Ersatz sollten Sie prüfen, ob die Funktion wirklich gebraucht wird, und die Entscheidung dokumentieren.
Muss das Frontend mit npm auch auf dem Server aktualisiert werden?
Oft liegen npm-Pakete nur im Build und landen als fertige Dateien auf dem Server. Eine Lücke in einem Paket kann trotzdem im ausgelieferten JavaScript stecken. Nach einem Update muss deshalb neu gebaut und neu ausgeliefert werden.