Wie spielt man ein TYPO3 Core-Update ein?

Kurz: Ein Core-Update hebt TYPO3 innerhalb derselben LTS-Version an, etwa von 13.4.34 auf 13.4.35. Es bringt Fehlerbehebungen und Sicherheitsupdates, aber keine neuen Funktionen und keine Brüche. In einer Composer-Installation sind es im Kern drei Schritte: Pakete aktualisieren, Datenbank abgleichen, Caches leeren. Den Upgrade-Wizard brauchen Sie dafür fast nie – er migriert Daten beim Wechsel auf eine neue Hauptversion oder beim Major-Update einer Extension. Entscheidend ist das Tempo: In unseren Projekten kommt jedes Core-Release automatisch als Merge Request, Sicherheitsreleases sind im Median noch am Tag der Veröffentlichung übernommen.

Core-Update, Upgrade, Extension-Update

Was oft „Minor-Update“ heißt, ist bei TYPO3 ein Patch-Update: Nach der LTS-Version ändert sich nur noch die letzte Stelle. Die Minor-Versionen 13.0 bis 13.3 waren Sprint-Releases vor der LTS-Version 13.4.

Wie oft kommen Core-Updates?

TYPO3 13.4 ist seit dem 15.10.2024 veröffentlicht. Bis September 2026 sind 36 Releases erschienen, 17 davon in den letzten zwölf Monaten, darunter 4 Sicherheitsreleases. 32 der 36 Releases kamen an einem Dienstag. Das macht Updates planbar: Wer dienstags die Ankündigungen prüft, verpasst kaum etwas.

Zu jedem Sicherheitsrelease veröffentlicht das TYPO3 Security Team ein Security Advisory mit der betroffenen Komponente und dem Schweregrad. Kostenlose Updates bekommen derzeit TYPO3 14.3 und 13.4, ältere Versionen nur noch über ELTS – mehr dazu unter Wie lange bekommt TYPO3 Sicherheitsupdates?

Ein Core-Update Schritt für Schritt

Für Composer-Installationen, so wie wir es in unseren Projekten machen:

1. Ankündigung lesen. Bei einem Sicherheitsrelease das Advisory: Welche Komponente ist betroffen, gibt es Hinweise zur Konfiguration?

2. Aktualisieren, nicht auf dem Live-Server. Lokal oder in einem eigenen Branch:

   composer update --with-all-dependencies "typo3/*"

   Die Anführungszeichen verhindern, dass die Shell das Sternchen auflöst; --with-all-dependencies hebt auch die Abhängigkeiten des Core an, etwa Symfony-Komponenten. Alle typo3/cms-*-Pakete landen dabei auf derselben Version. Die neue composer.lock wird committet.

3. Testen. Startseite, je eine Seite pro Inhaltstyp, Formulare mit echtem Versand, Suche, Anmeldung im Backend. Ein Patch-Update bricht selten etwas, geprüft wird trotzdem vor jedem Deploy.

4. Deployen, in dieser Reihenfolge:

   • Datenbank sichern.
   • Den neuen Stand mit composer install bereitstellen, aber noch nicht aktiv schalten.
   • Datenbank abgleichen: vendor/bin/typo3 extension:setup legt fehlende Tabellen und Felder an. Viele Projekte nutzen dafür database:updateschema aus helhum/typo3-console.
   • Auf den neuen Stand umschalten.
   • vendor/bin/typo3 cache:flush, danach vendor/bin/typo3 cache:warmup.

   So läuft der neue Code nie gegen eine Datenbank, der Felder fehlen. Ein Patch-Update ändert die Datenbankstruktur nur selten – der Abgleich kostet trotzdem nur Sekunden und gehört in jedes Deploy.

5. Nacharbeiten. vendor/bin/typo3 upgrade:list sollte nach einem Patch-Update leer sein. Den Referenzindex (vendor/bin/typo3 referenceindex:update) empfiehlt die TYPO3-Dokumentation nach jedem Update neu aufzubauen; auf großen Seiten dauert das und läuft besser nachts per Scheduler.

Ohne Composer, im klassischen Modus, tauschen Sie statt Schritt 2 den TYPO3-Quellcode aus, meist über den symbolischen Link typo3_src. Der Rest bleibt gleich.

Der Upgrade-Wizard: wann und wie

Zwischen zwei Hauptversionen ändert sich nicht nur der Code, sondern auch, wie TYPO3 Daten speichert. Der Upgrade-Wizard migriert vorhandene Datensätze einmalig in die neue Form. Ein Beispiel aus TYPO3 13: Plugins bekommen einen eigenen Inhaltstyp (CType) statt eines Eintrags im Feld list_type, und der Wizard schreibt die vorhandenen Inhaltselemente um.

Sie finden ihn im Backend-Modul „Upgrade“ oder auf der Kommandozeile:

vendor/bin/typo3 upgrade:list    # was ist noch offen?
vendor/bin/typo3 upgrade:run     # alle offenen Wizards ausführen

Mit einem Namen führt upgrade:run nur diesen Wizard aus. Jeder Wizard prüft zuerst, ob es für ihn etwas zu tun gibt, und gilt danach als erledigt. upgrade:mark:undone setzt ihn zurück.

Was sich in unseren Upgrades bewährt hat:

• Vorher einen Datenbank-Snapshot. Wizards ändern Daten und lassen sich nicht rückgängig machen. Lokal genügt ein Snapshot der Entwicklungsumgebung, auf Staging und Live eine Sicherung unmittelbar davor.
• Alle Wizards der alten Version abschließen, bevor die nächste kommt. Die Wizards von TYPO3 13 setzen eine vollständig migrierte Datenbank von 12 voraus. Wer mehrere Versionen überspringt, durchläuft jede Hauptversion einzeln – welche Schritte das sind, zeigt die Übersicht der Upgrade-Pfade.
• Nach jedem Major-Update einer Extension upgrade:list aufrufen. Mit Version 3 hat mindshape/mindshape-cookie-consent sein Plugin auf einen eigenen Inhaltstyp umgestellt. Bis der mitgelieferte Wizard gelaufen war, brach das Frontend mit Fehler 500 ab.
• Optionale Wizards bewusst entscheiden. Beim Schritt von TYPO3 9 auf 10 boten vier Wizards an, alte Extensions nachzuinstallieren, darunter EXT:rsaauth, seit TYPO3 9.1 veraltet. Abgelehnt gilt ein Wizard ebenfalls als erledigt.
• Eigene Daten brauchen eigene Wizards. Nicht jede Änderung kennt der Core. Beispielprojekt: Nach dem Upgrade auf 12 blieben übersetzte Menüs vom Typ „Menü ausgewählter Seiten“ in allen Fremdsprachen leer. Die Ursache war eine Core-Änderung aus TYPO3 10: Das Menü fragt seither nur Seiten der Standardsprache ab und übersetzt sie danach, die übersetzten Inhaltselemente verwiesen aber auf die übersetzten Seiten. Ein eigener Wizard hat die Verweise umgeschrieben, aufgefallen ist es beim Test vor dem Livegang. Für eigene Plugins bringt TYPO3 13.4 die Basisklasse AbstractListTypeToCTypeUpdate mit, für Ihre Entwickler.

Was beim Upgrade auf eine neue Hauptversion sonst noch zu tun ist, beschreibt die Seite Upgrade von TYPO3 12 auf 13; was schiefgehen kann, die Seite Probleme nach dem TYPO3-Upgrade.

Sicherheitsupdates automatisch

In unseren TYPO3-Projekten prüft Renovate laufend, ob es neue Paketversionen gibt. Für den Core heißt das:

• Erscheint ein Core-Release, öffnet Renovate einen Merge Request, der alle typo3/cms-*-Pakete gemeinsam anhebt, etwa „update typo3 cms from 13.4.34 to 13.4.35“.
• Die CI-Pipeline baut und testet ihn, ein Entwickler prüft und übernimmt ihn. Automatisch übernommen wird der Core bei uns nicht.
• Major-Updates des Core oder einer Extension kommen als eigener Merge Request und warten, bis das Upgrade geplant ist.

So schnell geht das in der Praxis – gemessen in zehn unserer Projekte über zwölf Monate, bis zur Übernahme in den Hauptzweig des Projekts (nicht bis zum Deploy):

Gezählt ist jedes Sicherheitsrelease, auch wenn ein Projekt es übersprungen und gleich eine spätere Version übernommen hat.

Langsamer wird es, wenn nicht Sie den Takt bestimmen. Distributionen wie der Government Site Builder (GSB 11) legen in jeder Version fest, mit welcher TYPO3-Version sie laufen, bis auf die letzte Stelle: Eine Version von itzbund/gsb-core verlangt typo3/cms-core in genau 13.4.34. Ein Sicherheitsrelease lässt sich erst einspielen, wenn die Distribution nachzieht – in unserem GSB-Projekt waren das zuletzt zwei Wochen und mehr. Wer eine solche Distribution nutzt, sollte bei jedem Advisory prüfen, ob die Lücke die eigene Installation betrifft und ob es bis zum Update eine Abhilfe über die Konfiguration gibt.

Composer blockiert unsichere Pakete

Seit Composer 2.9 (November 2025) verweigern composer update und composer require Paketversionen mit bekannten Sicherheitslücken. Das ersetzt das Paket roave/security-advisories, das in unseren Projekten deshalb entfallen ist.

Eine Stolperfalle hat das: Bei einem Upgrade über mehrere Hauptversionen braucht jeder Zwischenschritt alte Pakete, und die haben oft bekannte Lücken. Beim Schritt von TYPO3 9.5 auf 10.4 verweigerte Composer typo3/html-sanitizer und enshrined/svg-sanitize. Für einen solchen Zwischenschritt lässt sich die Sperre einmalig abschalten (--no-security-blocking, in neueren Composer-Versionen --no-blocking). Dauerhafte Ausnahmen in der composer.json sollten daraus nicht werden, sonst greift die Sperre auch später nicht.

composer audit prüft zusätzlich die installierten Pakete gegen die bekannten Lücken. Als Schritt in der CI-Pipeline meldet es eine Lücke auch dann, wenn gerade niemand aktualisiert.

Zwei-Faktor-Anmeldung gleich mit einschalten

Ein Update schließt Lücken im Code, gegen ein gestohlenes Passwort hilft es nicht. Seit TYPO3 11.1 bringt der Core eine Zwei-Faktor-Anmeldung mit: Einmalcodes aus einer Authenticator-App (TOTP) und Wiederherstellungscodes als Rückfallebene. Zur Pflicht wird sie mit einer Zeile, für Ihre Entwickler:

$GLOBALS['TYPO3_CONF_VARS']['BE']['requireMfa'] = 1;

1 verlangt sie von allen Backend-Benutzern, 3 nur von Administratoren, 2 nur von allen anderen, 4 nur von System-Maintainern; 0 ist die Voreinstellung und lässt die Wahl. Für einzelne Benutzer oder Gruppen überstimmt die Benutzer-TSconfig-Option auth.mfa.required die globale Einstellung. Unsere Regel: Zwei-Faktor-Anmeldung für alle, mindestens aber für Administratoren.

Updates im Blick behalten

Core-Updates, Sicherheitsreleases und das Support-Ende Ihrer Version behalten wir im TYPO3 Support für Sie im Blick – oder schreiben Sie uns über das Formular unten.

Stand: 24.9.2026 · Quellen: TYPO3 Explained: Patch/Bugfix update, TYPO3 Explained: Upgrade-Wizards, TYPO3 Explained: Plugins von list_type auf CType migrieren, TYPO3 Explained: Konsolenbefehle, TYPO3 Explained: Multi-Faktor-Authentifizierung, TYPO3 Security Advisories, get.typo3.org, Composer 2.9: Automatic security blocking, Renovate