Im Herbst 2026 wurde eine TYPO3-Website gehackt, die wir im Anschluss neu aufgebaut und analysiert haben. Der Fall ist lehrreich, weil er so unspektakulär begann und so weitreichend endete — und weil er sich mit einem Wartungsvertrag mit hoher Wahrscheinlichkeit verhindern lassen hätte. Wir schildern ihn anonymisiert, weil die Lehren daraus für jeden TYPO3-Betreiber gelten.
Wie der Angriff auffiel. Besuchern der Website wurde eine gefälschte „Bestätigen Sie, dass Sie ein Mensch sind"-Prüfung angezeigt — täuschend echt nachgebaut. Die Anleitung dort forderte dazu auf, eine Tastenkombination zu drücken, die unbemerkt einen Befehl aus der Zwischenablage ausführt. Diese Masche heißt „ClickFix": Der Besucher installiert sich auf diese Weise selbst Schadsoftware. Technische Ursache auf der Website war ein eingeschleustes Stück Fremd-JavaScript, das von einer fremden Domain nachgeladen wurde — oft nur selektiv ausgespielt, etwa nur für bestimmte Besucher, weshalb solche Manipulationen den Betreibern lange nicht auffallen.
Die Angriffskette. Aus den Logs ließ sie sich sauber rekonstruieren. Alles begann mit einem ganz normalen Formular-Absenden. Zwei Sekunden später antwortete eine neu angelegte PHP-Datei auf dem Server — eine sogenannte Web-Shell, also eine versteckte Hintertür, über die der Angreifer beliebige Befehle ausführen konnte. Über diese Shell wurde dann das Schad-JavaScript in die Website eingebaut. Damit hatte der Angreifer Zugriff auf alles, was der Webserver lesen kann: Datenbank-Zugangsdaten, den zentralen Verschlüsselungsschlüssel von TYPO3 — und damit auf sämtliche personenbezogenen Daten, von Backend-Nutzern bis zu allen Formular-Einsendungen.
Die Lücke. Verantwortlich war eine kritische Sicherheitslücke in einer sehr verbreiteten Formular-Extension (TYPO3-EXT-SA-2026-022, CVSS 9.5, offiziell als „aktiv ausgenutzt" gelistet). Über ein Formularfeld ließ sich fremder Programmcode einschleusen — ganz ohne Login. Und hier kommt der entscheidende Punkt: Die Lücke war am 25. August 2026 öffentlich gemeldet und derselbe Tag ein Sicherheitsupdate bereitgestellt worden. Der Einbruch erfolgte rund sechs Wochen später. Die Website war in dieser Zeit nicht aktualisiert worden.
Sechs Wochen. Das ist der ganze Unterschied zwischen „abgesichert" und „kompromittiert".
Es war nicht nur diese eine Lücke. Bei der Bestandsaufnahme zeigte sich: Die Installation lief auf einer TYPO3-Version, die seit Ende Oktober 2024 keine kostenlosen Updates mehr bekam — ohne den kostenpflichtigen erweiterten Support (ELTS), der das aufgefangen hätte. Mehrere der rund 25 installierten Extensions hatten offene, teils kritische Sicherheitslücken. Von den etwa 27 Extension-Sicherheitsmeldungen, die 2026 bis Oktober erschienen, betrafen allein sechs genau diese Installation. Jede einzelne davon wäre durch ein reguläres Update geschlossen worden.
Warum Wartung hier der eigentliche Hebel ist. Man kann diesen Fall technisch sezieren — die fehlende Server-Konfiguration, die veraltete Extension, der End-of-Life-Core. Aber die ehrlichste Lehre ist einfacher: Niemand hat die Updates eingespielt, und niemand hat die Sicherheitsmeldungen verfolgt.
Genau das ist die Aufgabe eines Wartungsvertrags. Nicht „die Website läuft ja", sondern:
Ein Detail aus dem Fall zeigt, wie Wartung in der Praxis aussehen sollte: Die Sicherheitsmeldungen kamen 2026 nicht gleichmäßig verteilt, sondern gebündelt an wenigen Terminen. Eine Wartung, die „X Updates pro Jahr" verspricht, geht am Problem vorbei. Sinnvoller sind Reaktionszeiten nach Schweregrad — bei einer kritischen, aktiv ausgenutzten Lücke zählt nicht der nächste Quartalstermin, sondern ob innerhalb von 24 bis 48 Stunden reagiert wird. Genau so sind unsere Wartungsverträge aufgebaut.
Was wir nach dem Vorfall gemacht haben. Kurz zusammengefasst, weil es zur Haltung gehört: Wir haben nicht geflickt, sondern neu aufgebaut. Server neu aufgesetzt, der Code ausschließlich aus einer sauberen Quelle, TYPO3 auf eine unterstützte Version gehoben, alle betroffenen Extensions aktualisiert, sämtliche Zugangsdaten und der Verschlüsselungsschlüssel neu erzeugt. Datenbank und Datei-Verzeichnis haben wir gezielt nach Hintertüren durchsucht, statt sie blind zu übernehmen — denn genau dort überleben sie eine oberflächliche Reinigung. Und wir haben die datenschutzrechtliche Meldepflicht geprüft, denn bei einem Zugriff auf personenbezogene Daten ist das kein optionaler Schritt.
Zwei Dinge zum Mitnehmen.
Für Betreiber: Eine Website ist kein abgeschlossenes Projekt, sondern Software, die gepflegt werden muss — genau wie ein Auto zur Inspektion muss. Die Frage ist nicht, ob Sicherheitslücken auftauchen, sondern wie schnell darauf reagiert wird. Ein Wartungsvertrag ist keine lästige Zusatzkostenstelle, sondern die Versicherung gegen genau den Fall, den wir hier beschrieben haben — und er ist um ein Vielfaches günstiger als ein Neuaufbau nach einem Einbruch, vom Reputations- und möglichen Datenschutzschaden ganz zu schweigen.
Und ein Hinweis für alle, nicht nur für TYPO3-Betreiber: Die „ClickFix"-Masche funktioniert nur, weil Menschen der gefälschten Prüfung folgen. Ein echtes Captcha verlangt niemals, eine Tastenkombination zu drücken oder einen Befehl auszuführen. Wer dazu aufgefordert wird, sollte die Seite sofort verlassen.
Wie steht es um Ihre TYPO3-Installation — welche Version, wie lange kein Update, gibt es eine laufende Betreuung? Wenn Sie sich bei einer dieser Fragen nicht sicher sind, schauen wir uns das gerne an. Eine Ersteinschätzung ist schnell gemacht.