HEIF Heist: Eine Lücke im Bild-Decoder erreicht Slack, Meta, GitHub und Next.js

Marcus Chen Staff Engineer (Backend & Cloud), YuSMP Group · Anwendungs- und Cloud-Sicherheit für Produktteams in den USA und der EU

Kurz gesagt

Was hat Hacktron veröffentlicht?

Am 18. September 2026 hat das Sicherheitsforschungsunternehmen Hacktron HEIF Heist veröffentlicht, das Ergebnis einer monatelangen Untersuchung, wie moderne Anwendungen Bilder dekodieren. Das Team – Harsh Jaiswal, Mohan SRK, Rahul Maini und Sudhanshu Rajbhar – spielt dabei auf einen bekannten xkcd-Comic an: ein riesiger Software-Turm, der auf einem kleinen, obskuren Baustein ruht, den kaum jemand pflegt. Hier ist dieser Baustein libheif (mit dem HEVC-Decoder libde265), die De-facto-Bibliothek für HEIF, HEIC und AVIF – die Formate, die Smartphones und Browser heute standardmäßig erzeugen.

Der Kernfehler ist klassisch und hardwarenah: Beim Verarbeiten eines Grid-Bildes läuft eine einzige Berechnung mit Breite oder Höhe über, dadurch wird ein zu kleiner Puffer angelegt, über dessen Ende der Decoder hinausschreibt – ein Heap-Pufferüberlauf. Darauf bauten die Forscher funktionierende Exploits, betonten aber, dass volle Codeausführung für Schaden gar nicht nötig ist. Selbst wenn Remote Code Execution nicht sofort gelingt, erlauben die Angriffsprimitive laut Hacktron womöglich das Auslesen beliebigen Heap-Speichers – ein Angreifer kann also benachbarten Speicher lesen, in dem Tokens, Schlüssel oder Daten anderer Nutzer liegen können.

Wucht bekam die Veröffentlichung durch die Liste der Ziele. Hacktron demonstrierte Remote Code Execution bei Slack, in Metas Kernprodukten über Bild-Uploads, eine RCE mit Authentifizierung bei GitHub Enterprise (CVE-2026-19118), eine RCE mit Authentifizierung in Discourse und eine RCE ohne Authentifizierung in Next.js über die Funktion AVIF Image Optimization. Außerdem verkettete das Team die Bildlücke mit einer Schwäche im Single Sign-on, kompromittierte so Mitarbeiterkonten bei OpenAI und gelangte an interne Code-Repositories – nach eigenen Angaben in weniger als 72 Stunden. Fixes stecken in libheif v1.23.2 und der aktuellen libde265, dazu kommen produktspezifische Patches der betroffenen Hersteller.

Warum steckt eine Bildbibliothek überall?

HEIF Heist trifft so viele unabhängige Produkte, weil der moderne Abhängigkeitsgraph so aussieht. Kaum eine Anwendung spricht libheif direkt an. Teams greifen zu komfortablen Bildwerkzeugen – ImageMagick für Konvertierungen, libvips für schnelle Vorschaubilder, Sharp für Node.js-Pipelines –, und diese binden libheif und libde265 stillschweigend ein, um neuere Formate zu unterstützen. Der native Decoder läuft mehrere Schichten unter dem Code, den ein Entwickler tatsächlich geschrieben hat, und meist unter der Sprache, auf deren Speichersicherheit er sich verlassen hat.

Deshalb übersieht ein normales Paket-Audit das Problem. Ein JavaScript- oder Python-Lockfile zeigt stolz „sharp“ oder „imagemagick“, nicht aber die C-Bibliothek, die darunter das riskante Parsing übernimmt. Der verwundbare Code ist real, er ist von jedem Endpunkt aus erreichbar, der ein Bild annimmt – und bleibt für die Abhängigkeits-Tools unsichtbar, denen die meisten Teams vertrauen. Es ist derselbe blinde Fleck bei transitiven nativen Abhängigkeiten, der die Branche schon mit libwebp und libxml2 getroffen hat: ein einzelner obskurer Parser unter einem Berg von Anwendungen.

Praktisch heißt das: Absichern lässt sich das nur mit Einblick in den Build, nicht nur in den Quellcode. Teams, die SBOM-Erzeugung (Software Bill of Materials) und das Scannen nativer Abhängigkeiten bereits in ihrer Cloud- und DevOps-Pipeline betreiben, beantworten die Frage „Wo liefern wir libheif aus, und in welcher Version?“ in Minuten. Alle anderen raten, welche ihrer Dienste das Bild eines Angreifers mit verwundbarem Code dekodieren – genau die Frage, die im Ernstfall innerhalb von 24 Stunden beantwortet sein muss.

Was bedeutet das für Teams im DACH-Raum?

Die erste Lehre: Ein Bild-Upload ist eine Grenze zur Codeausführung, keine Speicherfunktion. Überall, wo Nutzer, Partner oder eine automatisierte Integration Ihrem Backend ein Bild übergeben – Avatare, Ausweis-Scans im KYC-Prozess, Chat-Anhänge, Produktfotos, E-Mail-zu-Ticket-Pipelines –, erreichen vom Angreifer kontrollierte Bytes einen nativen Parser. Das ändert das Design der Funktion: Bilder gehören in einen isolierten Kontext mit minimalen Rechten dekodiert, nicht in denselben Prozess, der Ihre Datenbank-Zugangsdaten hält.

Die zweite Lehre betrifft das Tempo der Ausnutzung. Wenn KI-Assistenten die Exploit-Entwicklung auf Tage verkürzen, gilt die alte Annahme nicht mehr, Speicherfehler seien „theoretisch“, bis jemand einen Monat investiert. Für regulierte Branchen verschärft das bestehende Pflichten: Mit den seit 11. September 2026 geltenden Meldepflichten des Cyber Resilience Act und der 72-Stunden-Frist der DSGVO startet eine bestätigt ausgenutzte Lücke in einem Produkt für den EU-Markt eine schnelle regulatorische Uhr.

Die dritte Lehre: Das ist ein Lieferkettenproblem, das sich nur mit Inventar beherrschen lässt. Was Sie nicht sehen, können Sie nicht patchen, und libheif ist genau die Art Komponente, die sich versteckt. Ob Sie selbst entwickeln oder mit einem Team individuelle Software bauen: Die dauerhafte Lösung ist ein Prozess, der native Abhängigkeiten in jedem Container und jedem Build-Artefakt fortlaufend erfasst – damit die nächste Lücke dieser Art ein Patch am selben Tag ist und keine wochenlange Schnitzeljagd.

Was ist jetzt zu tun?

1. Decoder überall aktualisieren. Wechseln Sie auf libheif v1.23.2 oder neuer und die aktuelle libde265 – nicht nur in den Betriebssystempaketen, sondern auch in jeder gebündelten oder containerisierten Kopie von ImageMagick, libvips oder Sharp. Images neu bauen und ausrollen: Ein gepatchtes Host-Paket hilft keinem Container, der seine eigene Kopie mitbringt.
2. Hersteller-Advisories einspielen. Wenn Sie GitHub Enterprise, Discourse oder selbst gehostete Anwendungen mit Next.js-Bildoptimierung betreiben, aktualisieren Sie auf die im jeweiligen Advisory genannten Versionen. Der Next.js-Pfad erfordert keine Authentifizierung – aus dem Internet erreichbare Instanzen haben Vorrang.
3. Bilddekodierung inventarisieren. Listen Sie jeden Endpunkt und jeden Hintergrundjob auf, der HEIF-, HEIC- oder AVIF-Eingaben liest, und erzeugen Sie eine SBOM, die native Bibliotheken zeigt, nicht nur Sprachpakete. Sie müssen wissen, welche Dienste mit einem Bild des Angreifers erreichbar sind.
4. Abschalten, was nicht gebraucht wird. Muss ein Dienst nie HEIF oder AVIF annehmen, deaktivieren Sie die Dekodierung für Uploads. Eingeschränkte Eingabeformate verkleinern die Angriffsfläche sofort, noch bevor ein Patch ausgerollt ist.
5. Bildverarbeitung in eine Sandbox verlagern. Dekodieren Sie in einer gehärteten, kurzlebigen Sandbox mit minimalen Rechten – separater Prozess, Container oder Worker ohne Geheimnisse und ohne Netzwerk –, damit ein Decoder-Absturz eingedämmt bleibt und nicht zur Codeausführung in Ihrer Hauptanwendung wird.

Häufige Fragen

Quellen

HEIF Heist — Veröffentlichung von Hacktron
CyberScoop — Researchers use AI to find widespread software decoder flaw
Tom’s Hardware — Hackers breach OpenAI using Claude tools via image-parser flaw