22 Sicherheitslücken auf einen Streich: Composer-Abhängigkeiten sicher aktuell halten

Christopher Zechendorf

20.07.2026

Share:

Ein Security-Scan meldete 22 CVEs in den Composer-Abhängigkeiten einer TYPO3-Website. Wie wir sie in einem koordinierten Lockfile-Refresh geschlossen haben.

Die Herausforderung

An einem ganz normalen Morgen meldete unser täglicher, automatisierter Sicherheits-Scan für eine von uns betreute TYPO3-Website auf einen Schlag 22 bekannte Schwachstellen (CVEs) – und zwar nicht im selbst entwickelten Code, sondern in den quelloffenen Bibliotheken, auf denen die Seite aufbaut.

Das ist keine Ausnahme, sondern der Normalfall moderner Webentwicklung: Eine TYPO3-Anwendung besteht zu einem grossen Teil aus Dritt-Komponenten, die über den Paketmanager Composer eingebunden werden – vom TYPO3-Core selbst über HTTP-Clients bis zu spezialisierten Sicherheits-Bibliotheken. In genau diesen Komponenten werden fortlaufend neue Sicherheitslücken entdeckt und – verantwortungsvoll – veröffentlicht. Eine Website, die einmal live gegangen ist und danach „eingefroren” bleibt, sammelt deshalb mit jedem Tag stillschweigend Risiko an, ohne dass sich an ihrem sichtbaren Verhalten irgendetwas ändert.

Der erste Reflex bei 22 Meldungen ist oft Hektik: jede Lücke einzeln nachschlagen, einzeln patchen, einzeln testen. Das ist langsam, fehleranfällig und bringt den Abhängigkeitsbaum leicht in einen inkonsistenten Zustand. Wir gehen anders vor.

Unsere Lösung

1. Lücken finden, bevor sie zum Problem werden

Am Anfang steht nicht der Fix, sondern die Sichtbarkeit. Für die von uns betreuten Projekte läuft täglich ein automatisierter Sicherheits-Scan, der die tatsächlich installierten Paketversionen mit den offiziellen Schwachstellen-Datenbanken abgleicht. So landet eine neu veröffentlichte Lücke bei uns auf dem Tisch, bevor sie in freier Wildbahn ausgenutzt werden kann – inklusive Einordnung, welche Pakete betroffen sind und welche Zielversion das Problem behebt.

2. Ein koordinierter Lockfile-Refresh statt Einzelfixes

Der entscheidende Punkt: In sauber gepflegten Projekten sind die Versions-Vorgaben (die sogenannten Constraints in der composer.json) bereits so gesetzt, dass die abgesicherten Patch-Versionen erlaubt sind – im konkreten Fall etwa ^13.4 für alle TYPO3-Pakete. Es musste also keine einzige Versionsvorgabe angefasst werden. Der Fix bestand darin, die bereits erlaubten, gepatchten Versionen tatsächlich zu ziehen – ein reiner Refresh der composer.lock:

composer update "typo3/cms-*" guzzlehttp/guzzle guzzlehttp/psr7 typo3/html-sanitizer --with-dependencies

Weil alle betroffenen Pakete in einem einzigen Lauf aktualisiert werden, bleibt der Abhängigkeitsbaum in sich konsistent – kein Flickenteppich aus 22 halb zusammenpassenden Einzelständen. Die composer.json bleibt dabei unangetastet; geändert wird ausschliesslich die Lock-Datei, die exakt festhält, welche Version wovon installiert ist.

3. Was konkret aktualisiert wurde

In diesem einen Lauf wurden alle 22 gemeldeten Schwachstellen geschlossen:

• TYPO3-Core von 13.4.30 auf 13.4.32 – dieser Patch bündelt gleich mehrere offizielle TYPO3 Security Advisories (TYPO3-CORE-SA-2026-006 bis -019).
• Guzzle (HTTP-Client) von 7.10.5 auf 7.14.1 und das zugehörige PSR-7-Paket auf 2.12.5.
• Den HTML-Sanitizer von TYPO3 auf 2.3.2 – die Komponente, die Redaktions-Eingaben von schädlichem Markup befreit.

Für die Redaktion und die Besucherinnen und Besucher der Seite war davon nichts zu spüren: keine Änderung an Inhalten, Funktionen oder Darstellung – nur intern deutlich sicherere Fundamente.

4. Verifikation statt Vertrauen

Ein Update gilt bei uns erst dann als erledigt, wenn nachweisbar ist, dass es wirkt. Der aktualisierte Stand wurde in einem sauberen PHP-8.4-Container gebaut und geprüft:

• composer audit meldete anschliessend keine offenen Sicherheitshinweise mehr – alle 22 CVEs waren nachweislich ausgeräumt.
• composer validate bestätigte, dass Constraint-Datei und Lock-Datei zueinander passen.
• Der Diff berührte ausschliesslich die composer.lock – ein starkes Signal dafür, dass wirklich nur Versionen bewegt und keine Vorgaben verändert wurden.
• Nach dem Deploy folgte ein Smoke-Test der Live-Seite: Frontend und Backend luden fehlerfrei, die Caches wurden im Zuge des Deployments geleert.

5. Regelmässige Minor-Upgrades als Wartungsroutine

Der grösste Hebel gegen solche Sammelmeldungen ist, sie gar nicht erst gross werden zu lassen. Deshalb ist die Dependency-Pflege bei uns kein Feuerwehreinsatz, sondern Routine: Über mehrere Kundenprojekte hinweg heben wir TYPO3 planmässig auf die jeweils aktuelle Patch-Version im 13.4-LTS-Zweig (zuletzt auf 13.4.33) an. Wer regelmässig kleine, sichere Schritte geht, muss selten einen grossen, riskanten Sprung machen.

Das Ergebnis

Alle 22 gemeldeten Schwachstellen wurden in einem einzigen, koordinierten Durchlauf geschlossen – ohne Änderung an Inhalten oder Funktionen, mit einem sauber begrenzten Diff und einem grünen Smoke-Test nach dem Deploy. Aus einer potenziell hektischen 22-fach-Baustelle wurde ein ruhiger, nachvollziehbarer und vollständig verifizierter Wartungsvorgang.

Fazit

Sicherheit ist kein Zustand, den man einmal herstellt, sondern ein Prozess. Die Meldung von 22 CVEs an einem Tag klingt dramatisch – ist aber vollkommen beherrschbar, wenn drei Dinge zusammenkommen: kontinuierliche Überwachung, die Lücken früh sichtbar macht; sauber gepflegte Versionsvorgaben, die einen ruhigen Lockfile-Refresh statt hektischer Einzelfixes erlauben; und regelmässige Minor-Upgrades, die den Rückstand gar nicht erst entstehen lassen. So bleibt eine Website dauerhaft auf einem abgesicherten Fundament – unsichtbar für die Nutzer, aber entscheidend für den sicheren Betrieb.

Betreiben Sie eine TYPO3- oder PHP-Website und sind unsicher, wie es um die Aktualität Ihrer Abhängigkeiten steht? Sprechen Sie uns an – wir richten die kontinuierliche Überwachung ein und halten Ihre Seite planmässig auf einem sicheren Stand.