---
title: "Ein Fehler in einer Bibliothek, ein KI-Exploit und warum das für TYPO3 wichtig ist"
canonical: "https://dmitry-dulepov.com/de/ein-fehler-in-einer-bibliothek-ein-ki-exploit-und-warum-das-fuer-typo3-wichtig-ist/"
language: "de-CH"
content_type: article
---

# Ein Fehler in einer Bibliothek, ein KI-Exploit und warum das für TYPO3 wichtig ist

Ein manipuliertes Foto, eine Bilddatenbank, an die niemand gedacht hatte, und ein KI-Agent, der den Exploit geschrieben hat. Die Kette, die bis ins Innere von OpenAI reichte, verläuft durch Software, auf die sich auch viele TYPO3-Websites stillschweigend verlassen.

Im September 2026 [veröffentlichte](https://www.hacktron.ai/blog/hacking-openai) das Sicherheitsforschungsunternehmen [Hacktron einen Bericht](https://www.hacktron.ai/blog/hacking-openai), in dem beschrieben wurde, wie es eine Remote-Code-Ausführung auf der Infrastruktur von OpenAI erlangte. Der Einstiegspunkt war fast schon banal: Die Forscher luden ein Bild in ein Forum hoch. Was diese Geschichte lesenswert macht – und Maßnahmen erforderlich macht –, ist die Frage, *wo* sich der Fehler tatsächlich befand und wie er ausgenutzt wurde.

Wenn Ihre TYPO3-Website das Hochladen von Bildern zulässt und diese mit ImageMagick oder GraphicsMagick verarbeitet, sind Sie von derselben Art von Sicherheitslücke betroffen. Hier erfahren Sie, was genau passiert ist, warum die übliche Denkweise „Es liegt an ImageMagick“ falsch ist und was Sie dagegen tun können.

## Wie es dazu kam

OpenAI betreibt, wie Tausende anderer Organisationen auch, ein [Discourse-](https://www.discourse.org/) Community [-Forum](https://www.discourse.org/). Discourse ermöglicht es Nutzern, Bilder hochzuladen. Um die Bildabmessungen auszulesen, verwendet es normalerweise eine schlanke Ruby-Bibliothek namens FastImage. Da FastImage jedoch das HEIC/HEIF-Fotoformat von Apple nicht versteht, hat Discourse diese Dateien laut Hacktrons Darstellung stattdessen an den Befehl `„magick“` von ImageMagick weitergeleitet.

Diese Weiterleitung ist schon die ganze Geschichte. ImageMagick dekodiert HEIC nicht selbst. Es delegiert diese Aufgabe an eine separate Bibliothek namens **libheif**. Und die auf dem Server installierte Version von libheif – die aus dem Basis-Betriebssystem-Image bezogen wurde – enthielt einen Heap-Pufferüberlauf, der allein durch das Parsen einer bösartigen HEIC-Datei ausgelöst werden konnte.

Von da an folgt die klassische Kette der Speicherbeschädigung: Ein Pufferüberlauf, der Lese- und Schreibzugriffe außerhalb des zulässigen Bereichs ermöglicht, führt Schritt für Schritt zur Übernahme der Prozesskontrolle. Der Angreifer lädt ein Bild hoch; der Server versucht, ein Miniaturbild davon zu erstellen; das Bild führt Code aus. Hacktron berichtete, dass es den dadurch gewonnenen Zugangspunkt nutzte, um über kompromittierte Mitarbeiterkonten auf interne Repositorys zuzugreifen.

**Die Schwachstelle lag nie in ImageMagick. ImageMagick war lediglich die „Vordertür“, die zu der Bibliothek mit der eigentlichen Sicherheitslücke führte.**

## Was Ihnen Sorgen bereiten sollte: Es war kein Fehler von ImageMagick.

Das ist der Punkt, den viele falsch verstehen, daher lohnt es sich, dies klar zu sagen: ImageMagick und GraphicsMagick sind *Koordinatoren*. Für alles, was über die einfachsten Formate hinausgeht, greifen sie auf spezialisierte Bibliotheken zurück – libheif für HEIC/AVIF, Ghostscript für PDF und EPS, einen Renderer für SVG und so weiter. Wenn eine dieser delegierten Bibliotheken einen Fehler in Bezug auf die Speichersicherheit aufweist, übernimmt das Tool, das sie aufgerufen hat, diese Schwachstelle vollständig.

Daraus ergeben sich zwei Konsequenzen, die beide für Ihre Sicherheitsmaßnahmen von Bedeutung sind:

- **Ein Update von ImageMagick behebt dieses Problem nicht.** Der benötigte Patch befindet sich in libheif (und dessen Codecs), die über Ihr Betriebssystem bereitgestellt werden, nicht im Bildbearbeitungsprogramm selbst.
- **Auch ein Wechsel zu GraphicsMagick behebt das Problem nicht.** GraphicsMagick ist ein Fork von ImageMagick mit derselben Architektur und – im Fall von HEIC – derselben zugrunde liegenden Delegate-Bibliothek. Es gilt als konservativer – es enthält standardmäßig weniger exotische Decoder und hat die berüchtigten „ImageTragick“-Schwachstellen von 2016 umgangen –, aber bei dieser Art von Fehlern steht es genau auf dem gleichen Stand. Außerdem fehlt ihm `die „policy.xml“` von ImageMagick, sodass es tatsächlich schwieriger ist, ihn per Konfiguration abzusichern.

Hacktron verfolgte anschließend dieselbe „libheif“-Sicherheitslücke über eine lange Liste bekannter Plattformen und Frameworks hinweg – eine Folgeuntersuchung, die sie „HEIF Heist“ nannten. Der Punkt ist nicht, dass ein einzelnes Forum Pech hatte. Der Punkt ist, dass eine einzige anfällige C-Bibliothek unbemerkt unter einer enormen Menge an Software schlummert, die von Nutzern hochgeladene Bilder akzeptiert.

## Der KI-Aspekt

Hier kommt die Wendung, die diese Geschichte zu mehr als nur einer weiteren CVE-Meldung macht. Hacktron ist ein auf KI spezialisierter Sicherheitsdienstleister, und der Exploit wurde mit Hilfe eines großen Sprachmodells entwickelt, das als autonomer Agent fungierte.

Ihren Angaben zufolge stellte ASLR – Address Space Layout Randomization, die Standardabwehr, die den Speicher verstreut, sodass ein Angreifer nicht vorhersagen kann, wo sich Daten befinden – die interessante Hürde dar. Zunächst entwickelten sie einen funktionierenden Exploit bei deaktiviertem ASLR. Diesen Exploit so zu gestalten, dass er gegen eine Standardkonfiguration mit *aktiviertem* ASLR zuverlässig funktioniert, ist eine wirklich schwierige und knifflige Forschungsaufgabe. Hacktron berichtete, dass eine Modellgeneration dieses Ziel nicht zuverlässig erreichen konnte, während die nächste – die veröffentlicht wurde, während sie noch daran arbeiteten – den Exploit innerhalb weniger Stunden knackte.

Das sollte man mit der gebotenen Vorsicht lesen: Es handelt sich um einen Anbieter, der eine positive Geschichte über seine eigenen Tools erzählt, und die detaillierten Behauptungen stammen von ihm selbst und wurden nicht unabhängig überprüft. Aber die Richtung, in die die Entwicklung geht, ist real und es lohnt sich, sich damit auseinanderzusetzen. Die Entwicklung von Exploits gegen Speicherbeschädigungsfehler war schon immer eine spezialisierte, arbeitsintensive Aufgabe – genau das, was viele theoretisch ausnutzbare Fehler davon abhielt, zu praktischen Angriffen zu werden. Wenn KI-Agenten diesen Aufwand weiter reduzieren, wird die Lücke zwischen „ein Fehler existiert“ und „ein Fehler wird gegen Sie ausgenutzt“ immer kleiner. Die wenig glamouröse Arbeit des zeitnahen Patchens ist dann nicht mehr optional.

## Warum das bei TYPO3 landet

TYPO3 funktioniert strukturell genauso wie Discourse. Es akzeptiert Dateien über das Backend und auf vielen Websites auch über Frontend-Formulare. Es verarbeitet Bilder – Größenanpassung, Zuschneiden, Miniaturansichten – über einen externen Prozessor, den man unter `„GFX“` in den Systemeinstellungen konfiguriert, wobei als `Prozessor` „ImageMagick“ oder „GraphicsMagick“ eingestellt ist und der `\`processor_path\`` auf die Binärdatei verweist. Jedes hochgeladene Bild, das skaliert wird, durchläuft diese Pipeline, die dieselben delegierten Bibliotheken nutzt.

Einige Faktoren bestimmen, wie anfällig eine bestimmte Website tatsächlich ist:

- **Welche Formate Sie tatsächlich akzeptieren und verarbeiten.** Einfache JPEG-/PNG-/GIF-/WebP-Dateien durchlaufen relativ erprobte Decoder. Das Risiko steigt stark bei exotischen Dateiformaten – HEIC/AVIF, JPEG XL und insbesondere PDF, EPS und SVG –, deren Delegaten (Ghostscript, SVG-Renderer) seit langem für die Ausführung von Remote-Code bekannt sind.
- **Wer hochladen darf.** Wenn Uploads auf vertrauenswürdige Backend-Redakteure beschränkt sind, ist die Angriffsfläche gering. Wenn ein anonymes Frontend-Formular Bilder akzeptiert – Avatare, Kontaktformulare, Kommentare –, befinden Sie sich in derselben Lage wie Discourse.
- **Unter welchem Benutzer der Worker läuft.** Wenn Ihr PHP-FPM-Pool unter demselben Benutzer läuft, dem die Dateien der Website gehören und der die Datenbankzugangsdaten besitzt, bedeutet die Codeausführung im Bildparser eine vollständige Kompromittierung dieser Website.

**Eine berechtigte Einschränkung:** Standardmäßig übergibt eine unmodifizierte TYPO3-Website HEIC-Dateien nicht unbedingt auf dieselbe Weise an ihren Prozessor wie Discourse – der genaue HEIC-Angriffsvektor hängt von Ihren Formaten und Ihrer Konfiguration ab. Aber das zugrunde liegende Muster (nicht vertrauenswürdige Datei → externer Decoder → speichersichere C-Bibliothek) entspricht genau der Bildverarbeitungs-Pipeline von TYPO3, und die von ihr genutzten Delegate-Bibliotheken sind dieselben, die hier unter die Lupe genommen werden. Betrachten Sie dies als eine Risikoklasse und nicht als einzelne CVE.

## Was man konkret tun sollte

Die Behebung ist langweilig – und das ist die gute Nachricht. In grober Reihenfolge nach Auswirkung:

1. **Installieren Sie die Patches für die Delegate-Bibliotheken über den Sicherheitskanal Ihres Betriebssystems – nicht über ImageMagick.** Der Fehler lag in `libheif` und dessen Codecs (`libaom`, `libde265`). Unter Debian/Ubuntu bedeutet das, automatische Sicherheitsupdates aktiviert zu lassen oder sie umgehend manuell zu installieren. Überprüfen Sie die installierte Version mit `\`dpkg -l | grep libheif`\`.
2. **Wenn Sie in Docker arbeiten, erstellen Sie das Image neu – starten Sie es nicht einfach neu.** Das war das eigentliche Problem bei Discourse: eine anfällige libheif, die in einem Container-Image eingefroren war. Bei einem einfachen Neustart bleibt die alte, zwischengespeicherte Ebene erhalten. Erstellen Sie das Image von einer frischen Basis aus neu, damit die gepatchte Bibliothek integriert wird.
3. **Schränken Sie die Formate in**`der Datei „policy.xml“`**von ImageMagick ein .** Deaktivieren Sie alles, was Sie nicht benötigen – `PDF`, `PS`, `EPS`, `MVG`, `MSL` sowie HEIC/AVIF/JXL, falls Ihre Website diese Formate niemals verarbeitet. Dadurch werden ganze Kategorien von Delegaten entfernt, bevor eine vom Angreifer bereitgestellte Datei diese erreichen kann. (GraphicsMagick-Nutzer: Diese Einstellungsmöglichkeit steht euch nicht zur Verfügung, daher solltet ihr die nächsten beiden Maßnahmen umso stärker nutzen.)
4. **Schränken Sie ein, wer Dateien hochladen darf, und überprüfen Sie die tatsächlichen Dateitypen** – anhand der tatsächlichen MIME-Signatur, nicht anhand der Dateiendung –, insbesondere auf allen Upload-Pfaden, die für anonyme Nutzer erreichbar sind.
5. **Isolieren Sie die Verarbeitung.** Betreiben Sie jede Website unter einem eigenen, nicht privilegierten Benutzer und einem eigenen PHP-FPM-Pool, sodass die Codeausführung im Bildparser einer Website keine andere Website erreichen oder zu Root-Rechten eskalieren kann. Dadurch wird aus „ein Fehler = der gesamte Server“ „ein Fehler = eine Website“ – die wertvollste strukturelle Schutzmaßnahme, die Sie ergreifen können.

Nichts davon ist eine einmalige Aufgabe. Im Laufe des Jahres 2026 tauchten immer wieder neue Schwachstellen in libheif auf; allein im Sommer wurden mehrere Sicherheitsupdates veröffentlicht. Das realistische Ziel lautet nicht „für immer gepatcht“, sondern „schnell gepatcht und eingedämmt, wenn eine neue Schwachstelle auftaucht, bevor der Patch verfügbar ist“. Zeitnahe Updates schließen die bekannten Lücken; die Isolierung begrenzt den Wirkungsradius derjenigen, die noch niemand entdeckt hat.

## Wie mein eigenes System damit umgeht

Ich betreibe den Webserver, und jede Website erhält einen **eigenen Linux-Benutzer ohne Sonderrechte mit einem eigenen PHP-FPM-Pool**. Das ist in der Praxis der Isolationspunkt: Sollte ein manipuliertes Image jemals Code in der Verarbeitungspipeline einer Website ausführen, läuft es als Benutzer dieser Website und nicht weiter. Es kann diese eine Website ruinieren – ihre Dateien, ihre Datenbank-Anmeldedaten –, aber es kann weder die benachbarte Website erreichen noch ohne eine zweite, separate Sicherheitslücke Root-Rechte erlangen. „Ein Fehler = eine Website“, nicht „ein Fehler = der gesamte Server“.

Was das Patchen angeht, setze ich auf unbeaufsichtigte Sicherheitsupdates, die ausschließlich auf den `-security-Bereich` beschränkt sind, wobei automatische Neustarts deaktiviert sind. Gewöhnliche Feature-Updates wende ich nach einem kurzen Blick immer noch manuell an, aber die Sicherheitskorrekturen – jene, die für genau diese Bedrohung von Bedeutung sind – installieren sich über Nacht von selbst. Als ich während des Schreibens dieses Artikels tatsächlich die Protokolle überprüfte, stellte ich fest, dass der Rechner erst wenige Tage zuvor automatisch `libaom` installiert hatte: den AV1-Codec, den libheif zum Dekodieren von AVIF verwendet. Die Pipeline hatte still und leise genau die Bilddekodierungskette gepatcht, um die es in dieser ganzen Geschichte geht, ohne dass ich etwas daran verändert hatte.

Die ursprüngliche Studie stammt von Hacktron: [„Hacking OpenAI](https://www.hacktron.ai/blog/hacking-openai)“.