TYPO3-Sicherheit: Schwachstellen, Updates und Extensions im Vergleich

Wer die Frage stellt, welches CMS „sicher" sei, stellt die falsche Frage. Das gilt für TYPO3, für WordPress, für Joomla, für jede proprietäre Lösung: Schwachstellen gehören zum Betrieb jeder aktiv genutzten Software-Plattform. Was sich unterscheidet, ist der Umgang: wie schnell eine Schwachstelle öffentlich kommuniziert wird, wie verlässlich Patches erscheinen und wie konsequent Betreiber aktualisieren.

TYPO3 verfolgt hier einen strukturierten Ansatz, den Sie als Betreiber kennen sollten, da er direkte Konsequenzen für Ihren Update-Rhythmus hat.

Wie TYPO3 Schwachstellen kommuniziert und behebt

Das TYPO3 Security Team veröffentlicht alle Sicherheitsmeldungen öffentlich unter news.typo3.com/security. Jede Meldung enthält CVE-Nummern, eine klare Schweregrad-Einstufung und konkrete Handlungsempfehlungen — dazu den betroffenen Versionsbereich, den Stand des Patches und, wo nötig, einen Workaround für Systeme, bei denen ein sofortiges Update nicht möglich ist.

Die Grundlage dafür ist der LTS-Zyklus (Long Term Support): Aktuelle LTS-Versionen erhalten Security-Updates über mehrere Jahre, was Planungssicherheit für Betreiber schafft. Sofern Sie Ihr System auf einer aktuellen LTS-Version betreiben, haben Sie einen definierten Zeitraum, in dem Patches geliefert werden — nicht als Versprechen, sondern als technische Zusage der TYPO3 Association. Das setzt voraus, dass Sie verfügbare Updates auch tatsächlich einspielen.

Advisories beobachten lohnt sich

Die vollständige Liste der Security-Advisories ist unter typo3.org/help/security-advisories einsehbar. Ein Blick darauf ohne konkreten Anlass zeigt das Muster deutlich: Core-Schwachstellen in TYPO3 sind selten, aber regelmäßig. Extensions sind das deutlich häufigere Thema.

WordPress im Vergleich: eine andere Risikostruktur

Ein direkter CMS-Vergleich ist methodisch heikel, da Plattformgröße und Verbreitung stark abweichen. Was sich beobachten lässt: Das WordPress-Plugin-Ökosystem ist erheblich größer als das TYPO3-Extension-Ökosystem — zehntausende aktive Plugins gegenüber einigen hundert nennenswerten TYPO3-Extensions. Aus dieser Größe folgt strukturell eine höhere Angriffsfläche.

Auswertungen von CVE-Datenbanken zeigen, dass ein erheblicher Teil der WordPress-Schwachstellen nicht den Core betrifft, sondern Plugins. Viele davon laufen ohne regelmäßige Pflege, ohne aktives Maintainer-Team, ohne klare Kommunikation bei bekannten Lücken. Wer ein Plugin installiert, weil es kostenlos verfügbar ist und den gewünschten Effekt erzielt, prüft selten, ob die letzte Veröffentlichung zwei Jahre zurückliegt.

Keine Wertung — eine Konsequenz der Plattformgröße: Mehr Reichweite bringt mehr Installationen, mehr Installationen bringen mehr Angriffsfläche. TYPO3 hat ein kleineres, etwas stärker kuratiertes Ökosystem. Risiken bleiben — sie haben nur eine andere Struktur.

Extensions: das unterschätzte Hauptrisiko

Auch bei TYPO3 liegt das eigentliche Sicherheitsrisiko nicht im Core, sondern in Drittanbieter-Extensions. Das zeigt sich an konkreten, dokumentierten Fällen.

Die DCE-Extension als Fallbeispiel

Die DCE-Extension (Dynamic Content Elements) ist eine verbreitete TYPO3-Erweiterung für flexibel konfigurierbaren Content. Sie hatte in der Vergangenheit zwei dokumentierte kritische Schwachstellen:

• CVE-2014-8328 (Information Disclosure): Angreifer konnten unter bestimmten Bedingungen interne Systeminformationen auslesen.
• CVE-2021-31777 (SQL Injection): Eine schwerwiegendere Schwachstelle, die unter Umständen direkten Datenbankzugriff ermöglichte.

Beide wurden gepatcht. Das Problem liegt nicht im Patch selbst, sondern in der Zeitspanne zwischen Bekanntwerden und tatsächlichem Einspielen beim Betreiber. Wer DCE 2021 nicht zeitnah aktualisiert hat, war exponiert. Wer es heute noch in einer veralteten Version betreibt, ist es möglicherweise noch.

Das gilt nicht spezifisch für DCE. Es gilt für jede Extension, die produktiv läuft und nicht aktiv beobachtet wird.

Extension-Risikomanagement: konkrete Maßnahmen

Die praktische Konsequenz ist klar: so wenig Drittanbieter-Extensions wie nötig, und bei denen, die im Einsatz sind, konsequente Beobachtung.

Das lässt sich in konkrete Maßnahmen fassen:

Extension-Inventar kennen. Welche Extensions sind installiert, welche aktiv genutzt, welche veraltet? Nicht benötigte Extensions sollten deinstalliert werden, denn eine ungenutzte, aber installierte Extension ist ein Risiko ohne Gegenwert.

Community-Aktivität prüfen. Wird die Extension gepflegt? Wann war der letzte Release? Gibt es ein öffentliches Repository mit erkennbarer Aktivität? Extensions ohne aktives Maintainer-Team sind langfristig ein Risiko, unabhängig davon, ob heute schon eine Schwachstelle bekannt ist.

Advisories gezielt verfolgen. news.typo3.com/security listet nicht nur Core-Meldungen, sondern auch Extension-Schwachstellen. Wer dort regelmäßig nachschaut oder entsprechende Benachrichtigungen eingerichtet hat, erfährt von Lücken, bevor sie ausgenutzt werden.

Das ist kein einmaliger Aufwand, sondern ein Monitoring-Rhythmus, der eingerichtet und dann konsequent gehalten werden muss.

Update-Disziplin als entscheidender Faktor

Kein CMS-Betreiber kann Schwachstellen vollständig verhindern. Weder TYPO3-Core noch Extensions sind davon ausgenommen, und das wird sich nicht ändern. Was sich beeinflussen lässt, ist die Expositionszeit: der Zeitraum zwischen dem Bekanntwerden einer Schwachstelle und dem Einspielen des Patches.

TYPO3 erleichtert das durch seinen LTS-Zyklus, durch klare Versionierung und durch öffentliche Advisories mit konkreten Handlungsempfehlungen. Das Werkzeug ist vorhanden. Ob es genutzt wird, liegt beim Betreiber — in den meisten Fällen zusammen mit der Agentur, die den technischen Betrieb verantwortet. Eine Agentur, die keinen definierten Update-Prozess für Kundensysteme betreibt, überträgt das Risikomanagement stillschweigend auf den Kunden, der davon in der Regel nichts weiß.

Eine Einschränkung, die nicht wegzureden ist: Auch ein konsequent gewartetes TYPO3-System mit minimaler Extension-Basis kann kompromittiert werden — durch Zero-Days, durch Konfigurationsfehler, durch Schwächen im Hosting oder im Deployment-Prozess. Der Unterschied zu einem ungepflegten System liegt nicht darin, ob ein Vorfall passiert, sondern in der Häufigkeit und im Schadenspotenzial, wenn er passiert.

Sicherheit ist kein Produktversprechen und kein festes Merkmal eines CMS. Es ist ein Prozess.