Kritische libheif-Schwachstelle erlaubt HEIC-Bildern Codeausführung auf Servern
Am 1. September 2026 veröffentlichte das libheif-Projekt die Version 1.23.3, um einen kritischen Heap-Pufferüberlauf in der weit verbreiteten Bildbibliothek zu schließen. Die Schwachstelle wurde vier Tage zuvor vom Wordfence Threat Intelligence Team mit Wordfence Argus entdeckt und gemeldet, und libheif-Betreuer Dirk Farin bewertete sie mit 9,8 von 10 auf der CVSS-Skala. Einfach ausgedrückt: Ein speziell gestaltetes HEIC-Bild kann vom Angreifer kontrollierte Bytes über das Ende eines Speicherpuffers hinaus schreiben, und auf einem verwundbaren Server kann dies zum Lesen geschützter Dateien aus dem Bildverarbeitungs-Worker oder zur Codeausführung mit dessen Berechtigungen führen. Betroffen sind die Versionen 1.18.0 bis 1.23.2, wenn die Bibliothek mit aktiviertem unkomprimiertem Codec erstellt wurde; die Behebung erfolgt in 1.23.3; 1.23.4 ist die aktuelle Upstream-Sicherheitsversion. Dies ist keine reine WordPress-Schwachstelle.
Um zu verstehen, warum dies für eine WordPress-Site relevant ist, hilft es zu wissen, was libheif eigentlich tut. iPhone-Besitzer erstellen HEIC-Dateien, seit iOS 11 es 2017 zum Standard-Fotoformat gemacht hat, denn HEIC speichert ein besseres Bild in etwa der Hälfte des Speicherplatzes eines JPEG. HEIC ist ein Containerformat, im Wesentlichen eine Box mit einer Packliste, die beschreibt, was darin enthalten ist und wie es kodiert wurde. Fast niemand schreibt eigenen Code zum Öffnen; die meisten Linux-Systeme verlassen sich auf libheif. WordPress selbst dekodiert keine Bilder. Wenn ein Benutzer ein Foto hochlädt, übergibt WordPress die Datei an einen Bildeditor, um Miniaturansichten zu erstellen und Metadaten zu extrahieren. Auf betroffenen Servern ruft die PHP-Erweiterung Imagick ImageMagick auf, das HEIF erkennt und die Datei an libheif weitergibt. Das bedeutet, dass eine C++-Bibliothek im PHP-Bildverarbeitungs-Worker steckt und Bytes analysiert, die mit den Berechtigungen dieses Workers aus dem Internet kamen. Dieselbe Bibliothek liegt auch unter Desktop-Bildbetrachtern, Fotogalerien, selbst gehosteten Medienservern und Thumbnail-Generatoren, sodass jede Software, die HEIC-Dateien von anderen öffnet, potenziell exponiert ist.
Sollte sich ein Website-Betreiber Sorgen machen? Ein CVSS-Wert von 9,8 liegt nahe am Maximum und besagt, dass, wenn eine Anwendung diese Bibliothek ungeschützten Bildern über das Netzwerk ohne Anmeldung aussetzt, das Worst-Case-Ergebnis eine vollständige Serverübernahme ist. Das bedeutet nicht, dass jede WordPress-Site Fremden das Hochladen von HEIC-Dateien erlaubt. Wordfences Demonstration gegen eine saubere WordPress-Installation verwendete ein normales Autor-Konto, die erste Rolle, die in einer Standard-WordPress-Site Medien hochladen darf. Moderne Systeme erschweren zudem die Ausnutzung von Speicherfehlern: ASLR verteilt, wo Code und Daten im Speicher landen, und RELRO macht einige interne Tabellen schreibgeschützt. Dennoch bewies Wordfence, dass der Fehler weiter gehen kann. Auf einem bestimmten WordPress-Setup mit Debian und glibc ermöglichte eine gestaltete HEIC-Datei den Forschern, eine geschützte Datei zu lesen und Code auszuführen. Ein engerer Test, der ein hochgeladenes Bild an einen anderen Ort kopierte, funktionierte in 29 von 30 Versuchen gegen einen Apache-Server, der bereits lief und Worker-Prozesse wiederverwendete. Das ist ein starker Beleg für echte Auswirkungen, aber kein universeller Exploit; die Nutzlast hängt vom genauen libheif-Build, der Speicherverwaltung des Servers und davon ab, dass Anfragen einen Worker im richtigen Zustand erreichen. Ein Angreifer benötigt möglicherweise eine andere Datei für eine andere Umgebung. Wenn jedoch Hunderte oder Tausende von Sites dasselbe Hosting-Image verwenden, kann die Arbeit für eine auf die anderen übertragbar sein. Hochwertige Ziele und Hosting-Flotten, die aus einem gemeinsamen Image erstellt wurden, verdienen besondere Aufmerksamkeit.
Der Befund sollte nicht abgetan werden, nur weil ein Exploit angepasst werden muss. HEIF Heist, Forschung von Hacktron, die mehrere andere libheif-Schwachstellen in funktionierende Angriffe gegen echte Bildverarbeitungsdienste umwandelte, zeigt, wie schnell Anpassung erfolgen kann. Discourse bestätigte Codeausführung durch einen betroffenen Bild-Upload, und Vercel bestätigte nicht authentifizierte Codeausführung, wenn betroffene Next.js-Anwendungen ein gestaltetes AVIF-Bild verarbeiteten. Der Wordfence-Argus-Fund ist ein neuerer, separater Fehler mit anderer Ursache und wurde später behoben; libheif 1.23.2 adressierte zwei kritische Schwachstellen aus HEIF Heist, aber diese blieb bis 1.23.3 bestehen. Hacktron gibt an, dass die Anpassung seiner Exploits an ein neues Ziel im Allgemeinen etwa ein bis zwei Tage dauerte. Mit anderen Worten: „Muss angepasst werden“ ist eher eine Geschwindigkeitsschwelle als eine Sicherheitskontrolle, und Patchen sollte Priorität haben für jede Anwendung, die HEIC- oder HEIF-Dateien von Personen akzeptiert, denen Sie nicht vertrauen.
Für WordPress-Sites im Speziellen ist der übliche Bildverarbeitungspfad nur dann exponiert, wenn alle folgenden Bedingungen gleichzeitig erfüllt sind: Der Server hat die PHP-Erweiterung Imagick, denn der andere Bildeditor von WordPress kann HEIC überhaupt nicht lesen; die ImageMagick-Installation wurde mit HEIF-Unterstützung paketiert; die libheif-Version liegt zwischen 1.18.0 und 1.23.2; und dieses libheif wurde mit aktiviertem unkomprimiertem Codec kompiliert. Diese letzte Bedingung bedeutet, dass die Versionsnummer allein nicht aussagt, ob Sie verwundbar sind. Wordfence testete am 5. September neun reale Konfigurationen, indem es jede aufforderte, eine gültige unkomprimierte HEIF-Datei zu dekodieren. Die verwundbare Gruppe umfasste das offizielle WordPress-Docker-Image (libheif 1.19.8), Debian 13 Trixie (1.19.8), Ubuntu 26.04 (1.21.2) und Fedora 44 (1.21.2). Die nicht verwundbare Gruppe umfasste Ubuntu 24.04 LTS (1.17.6), Debian 12 Bookworm (1.15.1), Alpine 3.22 (1.19.8), Alpine 3.23 (1.23.0) und AlmaLinux 10 (1.17.6). Debian 13 und Alpine 3.22 liefern beide libheif 1.19.8 aus, doch eines ist verwundbar und das andere nicht, weil eines den unkomprimierten Codec zur Build-Zeit aktiviert und das andere nicht. Das offizielle WordPress-Docker-Image war von Haus aus exponiert: Auf Debian 13 aufgebaut, enthielt es die Imagick-Erweiterung, meldete HEIC-Unterstützung, und sein libheif dekodierte das verwundbare Format, wobei alle Bedingungen erfüllt waren und kein Zutun des Betreibers nötig war. Um Ihre eigene Site zu prüfen, öffnen Sie Werkzeuge, Site-Zustand, Info, Medienverarbeitung, wo die von ImageMagick unterstützten Dateiformate aufgelistet sind. Wenn HEIC nicht aufgeführt ist, ist dieser spezielle WordPress-Imagick-Pfad nicht exponiert, obwohl andere Software auf dem Server weiterhin libheif verwenden kann. Wenn Sie noch nicht patchen können, stoppen Sie die Annahme dieser Dateien, indem Sie alle vier von WordPress akzeptierten HEIF-Typen (heic, heif, heics, heifs) aus Ihren erlaubten Upload-Typen entfernen. Das Deaktivieren der PHP-Ausführung in Ihrem Uploads-Verzeichnis ist generell ebenfalls eine gute Idee. Wenn Sie das offizielle Image verwenden, holen Sie eine aktualisierte Basis, bauen Sie Ihr Image neu, ohne sich auf eine zwischengespeicherte Schicht zu verlassen, und stellen Sie es erneut bereit.
Wie funktioniert der Fehler eigentlich? Ein Farbfoto wird als drei getrennte Bilder gespeichert: eines enthält die Helligkeit, und die anderen beiden enthalten die Farbe, eines dafür, wie blau jeder Teil des Bildes ist, und eines dafür, wie rot. Das menschliche Auge nimmt Details in der Helligkeit viel stärker wahr als Details in der Farbe, daher können die beiden Farbbilder in niedrigerer Auflösung gespeichert werden, und niemand sieht den Unterschied. Im Vokabular der Datei wird jedes davon als Ebene (plane) bezeichnet. Jede Ebene deklariert, wie viel Platz ihre Punkte benötigen, genannt Bittiefe. Acht Bit pro Punkt sind üblich und belegen ein Byte Speicher; sechzehn Bit ergeben feinere Abstufungen und belegen zwei Bytes. Das Format erlaubt es jeder Ebene, ihre eigene Tiefe zu deklarieren, eine vernünftige Funktion, da dasselbe Format wissenschaftliche und Sensorbilder trägt, bei denen die Teile wirklich unterschiedliche Präzision haben. Ein Programm, das ein Bild liest, fordert vom System einen Speicherblock an, der groß genug ist, um es zu halten, genannt Puffer. Wenn das Programm mehr Daten schreibt, als der Puffer fassen kann, läuft das Extra in den Speicher jenseits des Puffers über, der andere Daten oder Buchhaltungsinformationen des Programms enthalten kann. Das ist ein Pufferüberlauf, und wenn ein Angreifer kontrolliert, was geschrieben wird, kann er das Programm möglicherweise dazu bringen, Code seiner Wahl auszuführen. In libheif 1.23.2 wird der Puffer jeder Ebene anhand der von dieser Ebene deklarierten Tiefe dimensioniert, was korrekt ist. Das Problem liegt in der Art, wie das Bild hineingeschrieben wird. Die beiden Farbebenen werden in der Datei miteinander verwoben gespeichert, ein Punkt von jeder, abwechselnd über die Zeile, sodass eine einzige Schleife beide Puffer gleichzeitig füllt. Diese Schleife schaut nur einmal nach, wie breit ein Punkt ist, und zwar von der Farbebene, die in der Datei zuerst aufgeführt ist. Wenn sechzehn-Bit-Blau zuerst aufgeführt ist, nimmt die Schleife zwei Bytes als Breite und schreibt Zwei-Byte-Punkte in beide Puffer. Der Puffer von Blau kann sie aufnehmen, aber der Puffer von Rot ist für Ein-Byte-Punkte dimensioniert, sodass jeder hineingeschriebene Punkt doppelt so groß ist, wie er sein sollte, und doppelt so weit entfernt landet. Jede Zeile läuft in die darunterliegende Zeile über, und die letzte Zeile läuft über das Ende des Puffers hinaus in Speicher, der etwas anderem gehört. Die überlaufenden Bytes stammen aus der Bilddatei, also wählt derjenige, der die Datei erstellt hat, was dort geschrieben wird, und die Menge des Überlaufs wächst mit den deklarierten Abmessungen des Bildes. In den Worten von Betreuer Dirk Farin: „Sowohl die geschriebenen Bytes als auch die Überlauflänge werden von der Datei kontrolliert.“ Der Fehler ist im Datensatz sichtbar, den libheif für jede Ebene führt: zwei Zeiger, zwei Zeilenlängen, aber nur ein Feld bytes_per_component_sample, sodass der Code annimmt, dass beide Farbebenen dieselbe Tiefe verwenden, obwohl die Datei deklarieren darf, dass sie es nicht tun. Direkt über dieser Schleife befindet sich ein Kommentar, der einen anderen Out-of-Bounds-Schreibvorgang in derselben Funktion beschreibt, der einige Monate zuvor behoben wurde, sodass derselbe Code bereits einmal gepatcht worden war, weil er über das Ende einer Farbebene hinausschrieb.
Wordfence Argus entdeckte die Schwachstelle am 28. August 2026 während einer Sicherheitsbewertung von WordPress 7.1. Das Team reproduzierte sie gegen offizielles libheif 1.23.2 mit einem Sanitizer-Build und einer passenden Kontrolldatei, bestätigte einen zweiten betroffenen Build, demonstrierte die Auswirkungen auf einer sauberen WordPress-Installation und meldete sie dem libheif-Betreuer über die private Schwachstellenmeldung von GitHub. Am 31. August committete der Betreuer einen Fix, und am 1. September wurde libheif 1.23.3 veröffentlicht und die Sicherheitsempfehlung publiziert. Nachfolgende Forschung am 2. September maß die Zuverlässigkeit über Versionen und Build-Konfigurationen hinweg. Für Website-Betreiber auf verwaltetem WordPress-Hosting wie AEU Hosting besteht der praktische Schritt darin, Ihren Anbieter direkt zu fragen, ob das libheif des Servers gepatcht ist und ob HEIC-Uploads akzeptiert werden, da ein verwalteter Dienst in der Lage sein sollte, Systembibliotheken zu aktualisieren und Container in Ihrem Namen neu zu erstellen. Dieselbe Frage gilt überall dort, wo libheif verwendet wird: Dekodiert diese Software HEIC-Dateien, die von jemand anderem stammen? Wenn Sie Dateien aus nicht vertrauenswürdigen Quellen verarbeiten, sei es ein Foto-Sharing-Dienst, eine Dokumenten-Pipeline, eine Chat-Anwendung, die Vorschauen generiert, oder ein selbst gehosteter Medienserver, setzen Sie dies auf Ihrer Patch-Liste nach oben. Prüfen Sie sowohl die installierte libheif-Version als auch, ob sie mit aktiviertem unkomprimiertem Codec erstellt wurde, installieren Sie das gepatchte Paket Ihres Anbieters, isolieren oder sandboxen Sie die Bildverarbeitung wo möglich und deaktivieren Sie die HEIF-Unterstützung, wenn Sie sie nicht benötigen. Die tiefere Lektion ist, dass die Schwachstellen, die WordPress-Sites schaden, nicht immer in WordPress selbst liegen; einige liegen mehrere Ebenen tiefer in gemeinsam genutzten Bibliotheken, erreicht durch eine so alltägliche Funktion wie das Hochladen eines Urlaubsfotos.