![\"Pixelsmash](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2026\/06\/21161456\/Pixelsmash-863x300-1.png\"){kind=tracking}
<\/p>\n<\/p>\n
JFrog Security Research hat vor Kurzem eine kritische Schwachstelle in FFmpeg \u2013 dem weltweit am h\u00e4ufigsten eingesetzten Framework zur Verarbeitung von Mediendateien \u2013 entdeckt und offengelegt. Die entdeckte Schwachstelle, die wir PixelSmash<\/strong> genannt haben, tr\u00e4gt das K\u00fcrzel CVE-2026-8461<\/strong>\u00a0\u2013 ein Heap-Out-of-Bounds-Write im MagicYUV-Decoder (CVSS 8,8 Hoch). Wir haben die Schwachstelle von einem einfachen Absturz bis hin zu einer zuverl\u00e4ssigen Remote Code Execution eskaliert. Daf\u00fcr gen\u00fcgte bereits die Verarbeitung einer einzigen sch\u00e4dlichen Mediendatei.<\/p>\n Der Out-of-Bounds-Write reicht aus, um jede Anwendung, die FFmpeg nutzt<\/strong>, zum Absturz zu bringen\u00a0\u2013 von Desktop-Videoplayern wie Kodi und mpv \u00fcber Thumbnail-Generatoren in Linux-Dateimanagern bis hin zu Cloud-Transcoding-Pipelines und selbst gehosteten Medienservern. Wir konnten den vollst\u00e4ndigen Exploit der Schwachstelle demonstriert, indem wir auf zwei unabh\u00e4ngigen Zielsystemen Remote Code Execution erm\u00f6glichten: auf einem Jellyfin<\/strong>-Medienserver (\u00fcber einen automatischen Library-Scan) und auf einer Nextcloud<\/strong>-Instanz (\u00fcber den Videovorschau-Anbieter). In beiden F\u00e4llen gen\u00fcgte das Hochladen einer pr\u00e4parierten 50-KB-AVI-Datei.<\/p>\n FFmpeg-Nutzern wird empfohlen, so schnell wie m\u00f6glich auf die gefixte Version upzugraden. Wird der MagicYUV-Decoder nicht ben\u00f6tigt, kann er bereits w\u00e4hrend des Builds deaktiviert werden (siehe Abschnitt \u201eWorkarounds\u201c weiter unten).<\/strong><\/p>\n FFmpeg ist in praktisch jeder Anwendung zur Medienverarbeitung auf allen Plattformen integriert oder mit dieser verkn\u00fcpft\u00a0\u2013 entsprechend gro\u00df sind die potenziellen Auswirkungen der Schwachstelle. Wir konnten unter anderem Abst\u00fcrze bei Kodi, mpv, ffmpegthumbnailer (verwendet von GNOME, KDE und XFCE), Jellyfin, Emby, Nextcloud, Immich, PhotoPrism und OBS Studio best\u00e4tigen. Bei Jellyfin konnten wir eine vollst\u00e4ndige Remote Code Execution demonstrieren.<\/p>\n PixelSmash ist eine Schwachstelle in der Software-Lieferkette: Ein einziger Bug in einem einzigen Codec-Decoder innerhalb von FFmpeg\u00a0\u2013 einer grundlegenden Abh\u00e4ngigkeit, die in Hunderten von Downstream-Projekten eingebettet ist\u00a0\u2013 breitet sich kaskadenartig auf jede Anwendung aus, die libavcodec<\/strong> einbindet. Keines der betroffenen Projekte (Jellyfin, mpv, Nextcloud, Immich, OBS, vLLM und viele andere) hat diesen Bug selbst eingef\u00fchrt. Sie haben ihn unbemerkt \u00fcber ihre Abh\u00e4ngigkeit von FFmpeg \u00fcbernommen und verf\u00fcgen in der Regel \u00fcber keine Mechanismen, um ihn selbst zu erkennen oder zu beheben.<\/p>\n In diesem technischen Blogbeitrag erkl\u00e4ren wir die Ursache der Schwachstelle, gehen den Exploit vom Absturz bis zur Codeausf\u00fchrung Schritt f\u00fcr Schritt durch und demonstrieren eine reale Remote Code Execution auf einem Jellyfin-Medienserver\u00a0\u2013 vom Upload einer einzelnen Videodatei bis hin zu einer Reverse Shell.<\/p>\n Wir m\u00f6chten uns bei den Sicherheitsteams von FFmpeg und Jellyfin f\u00fcr ihre schnelle Reaktion bei der Behebung dieser Probleme bedanken.<\/p>\n Um PixelSmash auszunutzen, muss ein Angreifer eine manipulierte Mediendatei (AVI-, MKV- oder MOV-Container) an eine beliebige Anwendung \u00fcbermitteln, die Videos mit FFmpegs libavcodec decodiert. Dazu geh\u00f6ren:<\/p>\n Abgesehen von der M\u00f6glichkeit, eine Mediendatei zu \u00fcbermitteln, sind keine Authentifizierung, speziellen Berechtigungen oder ein vorheriger Zugriff auf das Zielsystem erforderlich, \u00a0\u2013 die Standard-Angriffsfl\u00e4che bei jeder Anwendung zur Medienverarbeitung.<\/p>\n Um festzustellen, ob Ihr System den anf\u00e4lligen MagicYUV-Decoder enth\u00e4lt, f\u00fchren Sie den folgenden Befehl aus:<\/p>\n Wenn die Ausgabe VFS..D magicyuv enth\u00e4lt, ist Ihr FFmpeg-Build von der Schwachstelle betroffen. Der MagicYUV-Decoder ist in allen Upstream-FFmpeg-Builds und allen von uns getesteten Distributionspaket (Ubuntu, Debian, Fedora, Arch, Alpine) vor Version 9.0 standardm\u00e4\u00dfig aktiviert<\/strong>.<\/p>\n Falls ein sofortiges Upgrade von FFmpeg nicht m\u00f6glich ist:<\/p>\n Option 1\u00a0\u2013 Erstellen Sie FFmpeg neu und deaktivieren Sie dabei den anf\u00e4lligen Decoder:<\/strong><\/p>\n <\/p>\n Option 2\u00a0\u2013 Minimalen Patch anwenden (7 Zeilen werden zu libavcodec\/magicyuv.c hinzugef\u00fcgt):<\/p>\n <\/p>\n Dadurch werden fehlerhafte slice_height-Werte zur\u00fcckgewiesen, die den Out-of-Bounds-Write triggern. Der Referenz-MagicYUV-Encoder gibt immer korrekt ausgerichtete Slice-H\u00f6hen aus, sodass dadurch ausschlie\u00dflich b\u00f6sartige Eingaben blockiert werden.<\/p>\n FFmpeg ist die Basis f\u00fcr die Medienverarbeitung im gesamten Software-\u00d6kosystem. Es ist in praktisch jede Anwendung, die Videos verarbeitet, eingebunden oder mit ihr geb\u00fcndelt\u00a0\u2013 von Desktop-Playern (mpv, VLC) \u00fcber selbst gehostete Medienserver (Jellyfin, Plex, Emby) und Cloud-Transcoding-Pipelines (AWS MediaConvert, Cloudflare Stream) bis hin zu Linux-Desktop-Umgebungen (GNOME, KDE nutzen XFCE nutzen es f\u00fcr Video-Thumbnails).<\/p>\n Die FFmpeg-Library libavcodec<\/strong> enth\u00e4lt Decoder f\u00fcr Hunderte Video- und Audio-Codecs. Jeder dieser Decoder parst Bitstream-Daten, die von Angreifern kontrolliert werden k\u00f6nnen, und schreibt die decodierten Pixel in den dem Heap zugewiesenen Frame-Buffer. Ein Bug in einem beliebigen Decoder kann daher von jeder Anwendung genutzt werden, die das entsprechende Medienformat verarbeitet. Deshalb geh\u00f6ren Codec-Fehler zu den potenziell folgenreichsten Schwachstellenklassen im Software-\u00d6kosystem.<\/p>\n MagicYUV<\/strong> ist ein verlustfreier Video-Codec, der f\u00fcr leistungsstarke Workflows in der Videobearbeitung entwickelt wurde. Obwohl er weniger bekannt ist als H.264 oder VP9, ist sein Decoder in jedem standardm\u00e4\u00dfigen FFmpeg-Build kompiliert und f\u00fcr AVI-, MKV- und MOV-Container registriert. Jede Anwendung, die eine Videodatei \u00f6ffnen kann, kann daher den MagicYUV-Decoder ausl\u00f6sen.<\/p>\n Bei der Videokompression ist ein Slice ein klar abgegrenzter, horizontal unterteilter Bereich eines einzelnen Videoframes, der unabh\u00e4ngig vom restlichen Frames decodiert werden kann.<\/p>\n Digitale Videos speichern Bilder nur selten im klassischen RGB-Farbraum (Rot, Gr\u00fcn, Blau). Stattdessen kommt der YUV-Farbraum zum Einsatz, bei dem ein Bild in separate Ebenen oder \u201ePlanes\u201c aufgeteilt wird:<\/p>\n Die Schwachstelle ist ein Heap-Puffer\u00fcberlauf um eine Zeile bei der Verarbeitung von Slices im MagicYUV-Decoder. Der Grund ist, dass der Frame-Allocator und der Decoder die H\u00f6he der Chroma-Ebenen unterschiedlich berechnen.<\/p>\n MagicYUV codiert Videos in horizontalen Slices. Bei unterabgetasteten Pixelformaten wie YUV420P (bei denen die Chroma-Ebenen nur die H\u00e4lfte der vertikalen Aufl\u00f6sung der Luma-Ebene aufweisen) muss der Decoder die Slice-H\u00f6hen von Luma-Zeilen mithilfe von aufgerundeten Rechts-Shifts in Chroma-Zeilen umrechnen.<\/p>\n Das Problem: Wenn slice_height ungerade ist, f\u00fcgt der aufgerundete Shift (AV_CEIL_RSHIFT) eine zus\u00e4tzliche Zeile pro Slice hinzu. \u00dcber mehrere Slices hinweg summieren sich diese zus\u00e4tzlichen Zeilen, bis sie \u00fcber das Ende des f\u00fcr die Chroma-Ebene vorgesehenen Puffers hinausreichen.<\/p>\n Das Problem l\u00e4sst sich in folgende Schritte unterteilen:<\/p>\n 1. Der Frame-Allocator berechnet, wie hoch der Puffer f\u00fcr die Chroma-Ebene sein sollte. In update_frame_pool (get_buffer.c) wird die Frame-H\u00f6he zun\u00e4chst auf 32 ausgerichtet und anschlie\u00dfend f\u00fcr Chroma halbiert:<\/p>\n Der Puffer der Chroma-Ebene ist f\u00fcr 16 Zeilen ausgelegt.<\/p>\n 2. Der Decoder liest slice_height direkt aus dem vom Angreifer kontrollierten Bitstream (magicyuv.c:550 aus):<\/p>\n Mit unserem gezielt gew\u00e4hlten Wert slice_height = 31 und coded_height = 32 berechnet der Decoder Folgendes:<\/p>\n 3. F\u00fcr den zweiten (letzten) Slice berechnet der Decoder den Ziel-Pointer folgenderma\u00dfen:<\/p>\n Der Chroma-Puffer umfasst die Zeilen 0\u201315 (16 Zeilen). Der Decoder schreibt jedoch in Zeile 16\u00a0\u2013 also eine ganze Zeile \u00fcber das Ende des zugewiesenen Bereichs hinaus.<\/p>\n 4. Der OOB-Write wird ausgel\u00f6st. Im Raw-Modus kopiert der Decoder die vom Angreifer kontrollierten Bytes direkt:<\/p>\n <\/p>\n Bei width = 640 (bei unserer coded_width = 1280, f\u00fcr Chroma halbiert) werden dadurch 640 vollst\u00e4ndig vom Angreifer kontrollierte Bytes in den Heap-Block geschrieben, der unmittelbar auf den Puffer der Chroma-Ebene folgt.<\/p>\n Die bestehende slice_height-Validierung in magicyuv.c:566 pr\u00fcft nur den Interlaced-Codepfad. Der von uns ausgenutzte Non-Interlaced-Pfad dagegen enth\u00e4lt keinerlei Pr\u00fcfung der Ausrichtung:<\/p>\n <\/p>\n Der ASAN-Bericht vom Upstream-Master best\u00e4tigt den Overflow eindeutig:<\/p>\n <\/p>\n Diagramm 1\u00a0\u2013 Heap-Layout<\/em><\/p>\n Ein Heap-Overflow ist nur von Nutzen, wenn der Angreifer etwas Relevantes \u00fcberschreiben kann. Im Heap-Layout von FFmpeg ist das die AVBuffer-Struktur\u00a0\u2013 das referenzgez\u00e4hlte Objekt zur Pufferverwaltung, das FFmpeg unmittelbar nach den Pixeldaten jeder Ebene zuweist.<\/p>\n Sobald FFmpeg die Decodierung eines Frames abgeschlossen hat, ruft es av_frame_unref auf, das f\u00fcr jede Ebene die zugeh\u00f6rige Buffer-Referenz durchl\u00e4uft und av_buffer_unref aufruft. Innerhalb von av_buffer_unref (libavutil\/buffer.c:133) geschieht Folgendes, sobald der Refcount null erreicht:<\/p>\n <\/p>\n Dabei handelt es sich um einen indirekten Aufruf \u00fcber einen im Heap gespeicherten Funktionszeiger. Wenn wir buf->free mit der Adresse von system()-aus der libc und buf->opaque mit einem Zeiger auf einen Shell-Command-String \u00fcberschreiben k\u00f6nnen, wird aus dem indirekten Aufruf:<\/p>\n <\/p>\n Unser OOB-Write von 640 Byte trifft direkt auf die AVBuffer struct der Cb-Chroma-Ebene. Das Heap-Layout im OOB-Bereich sieht wie folgt aus (erfasst via GDB auf der in Jellyfin geb\u00fcndelten Version jellyfin-ffmpeg 7.1.3):<\/p>\n <\/p>\n <\/p>\n Der Exploit platziert einen NUL-terminierten Shell-Befehl am OOB-Offset 0 (in einem 88 Byte gro\u00dfen Nullbereich, der frei von glibc-Metadaten ist) und \u00fcberschreibt anschlie\u00dfend:<\/p>\n Wenn av_buffer_unref w\u00e4hrend der normalen Frame-Bereinigung ausgef\u00fchrt wird, wird aus dem indirekten Aufruf system(“attacker_command”). Der neu gestartete Shell-Prozess (“Shell Child”) f\u00fchrt den Befehl aus, bevor der \u00fcbergeordnete FFmpeg-Prozess (“Parent Shell”) aufgrund der nachfolgenden Heap-Korruption abst\u00fcrzt\u00a0\u2013 der Befehl wurde zu diesem Zeitpunkt bereits ausgef\u00fchrt.<\/p>\n Die zentrale Herausforderung besteht darin, dass die malloc-Chunk-Header von glibc innerhalb des OOB-Bereichs exakt erhalten bleiben m\u00fcssen. Andernfalls erkennen free()-Aufrufe bei anderen Speicherzuweisungen eine Besch\u00e4digung und brechen den Prozess ab, bevor unser manipuliertes av_buffer_unref ausgef\u00fchrt wird. Unser Exploit codiert die im Heap des Zielsystems beobachteten exakten Chunk-Metadaten in den OOB-Payload und verwendet daf\u00fcr Left-Prediction-Codierung, die dem Dekompressionsalgorithmus von MagicYUV entspricht.<\/p>\n Diagramm 2\u00a0\u2013 Exploit-Ablauf<\/em><\/p>\n Der Heap-OOB-Write ist nicht nur ein Denial of Service. Wir haben ihn zu einer zuverl\u00e4ssigen Ausf\u00fchrung beliebiger Befehle gegen die mit Jellyfin geb\u00fcndelte FFmpeg-Version 7.1.3 ausgeweitet.<\/p>\n Wichtige Einschr\u00e4nkung: F\u00fcr diese Demonstration war ASLR deaktiviert. Unser Exploit erfordert hartkodierte Adressen f\u00fcr system() und den OOB-Command-String. Das bedeutet, dass er nur dann deterministisch funktioniert, wenn ASLR deaktiviert ist (setarch x86_64 -R) . In einer standardm\u00e4\u00dfigen Linux-Konfiguration mit aktiviertem ASLR werden die Adressen bei jeder Ausf\u00fchrung randomisiert, sodass der Exploit nicht zuverl\u00e4ssig funktioniert. Wir haben jedoch eine separate Sicherheitsl\u00fccke im FlashSV-Decoder von FFmpeg (libavcodec\/flashsv.c) identifiziert\u00a0\u2013 die Offenlegung eines nicht initialisierten Heap-Speichers. Diese Schwachstelle ist seit Juli 2022 im Upstream-FFmpeg vorhanden und zum Zeitpunkt der Ver\u00f6ffentlichung noch nicht behoben worden. Sie l\u00e4sst sich allerdings nur ausnutzen, wenn bestimmte Umgebungsoptionen f\u00fcr FFmpeg verwendet werden (z.\u00a0B. -threads 1)\u00a0\u2013 daher wird ihr Schweregrad lediglich als \u201einformativ\u201c eingestuft. Grunds\u00e4tzlich k\u00f6nnte ein \u00e4hnliches Informationsleck, das k\u00fcnftig entdeckt wird, mit dem MagicYUV-OOB-Write kombiniert werden, um ASLR zu umgehen und auch bei vollst\u00e4ndig aktivierten Schutzma\u00dfnahmen eine RCE zu erm\u00f6glichen. Eine solche Verkettung erfordert jedoch weitere Untersuchungen und wurde bislang nicht demonstriert. Der MagicYUV-OOB-Write allein (ohne ASLR-Umgehung) reicht bei allen getesteten Zielen f\u00fcr einen zuverl\u00e4ssigen DoS aus.<\/p>\n F\u00fcr die Eskalation des Exploits mussten wir drei technische Herausforderungen l\u00f6sen:<\/p>\n Um die Auswirkungen in der Praxis zu demonstrieren, haben wir eine vollst\u00e4ndige Remote Code Execution auf einem Jellyfin-Medienserver der Version 10.11.9\u00a0\u2013 dem zweitbeliebtesten selbst gehosteten Medienserver (nach Plex)\u00a0\u2013 \u00fcber dessen regul\u00e4re Medienbibliothek-Scan-Pipeline erreicht.<\/p>\n Angriffspfad: Download einer pr\u00e4parierten MagicYUV-AVI-Datei in die Medienbibliothek -> Jellyfin startet automatisch ffprobe, um Metadaten auszulesen -> der OOB-Write wird ausgel\u00f6st -> AVBuffer.free wird so manipuliert, dass auf system() verwiesen wird -> ein beliebiger Befehl wird als Jellyfin-Servicenutzer (uid 115) ausgef\u00fchrt.<\/p>\n Das Heap-Layout des OOB-Bereichs h\u00e4ngt von den genauen ffprobe-Kommandozeilenargumenten und der L\u00e4nge des Eingabedateipfads ab. Das haben wir im Zuge von drei vollst\u00e4ndigen Rekalibrierungszyklen festgestellt:<\/p>\n <\/p>\n Unsere abschlie\u00dfende Kalibrierung ist auf einen 60 Zeichen langen Dateipfad ausgelegt (entsprechend der standardm\u00e4\u00dfigen Struktur der Jellyfin-Medienbibliothek). Die Exploit-AVI-Datei:<\/p>\n Die gesamte Exploit-Payload wird zu einer einzigen AVI-Datei mit 50 KB (alternativ kann es auch ein MKV- oder MOV-Container sein).<\/p>\n Wir haben einen Listener auf dem Rechner des Angreifers eingerichtet und einen Scan der Jellyfin-Library ausgel\u00f6st (f\u00fcr diese Demonstration war ASLR deaktiviert war\u00a0\u2013 siehe dazu die Erl\u00e4uterungen zu ASLR weiter oben). Wenige Sekunden nachdem ffprobe von Jellyfin die hochgeladene Datei verarbeitet hatte, erhielten wir eine Reverse Shell, die mit den Rechten des Jellyfin-Servicenutzers ausgef\u00fchrt wurde:<\/p>\nWer ist von PixelSmash betroffen?<\/h2>\n
Voraussetzungen f\u00fcr einen Angriff<\/h3>\n
\n
erkennen<\/h3>\n
ffmpeg -decoders 2>\/dev\/null | grep magicyuv\r\n<\/code><\/pre>\nWorkarounds<\/h3>\n
.\/configure --disable-decoder=magicyuv [your other flags]<\r\nmake && make install<\/code><\/pre>\n\r\n if (s->slice_height <= 0 || s->slice_height > INT_MAX - avctx->coded_height) {\r\n av_log(avctx, AV_LOG_ERROR, \"invalid slice height: %d\\n\", s->slice_height);\r\n return AVERROR_INVALIDDATA;\r\n }\r\n+ if ((s->slice_height >> s->vshift[1]) <= s->interlaced) {\r\n+ av_log(avctx, AV_LOG_ERROR, \"impossible slice height\\n\");\r\n+ return AVERROR_INVALIDDATA;\r\n+ }\r\n+ if ((avctx->coded_height % s->slice_height) && ((avctx->coded_height % + s->slice_height) >> s->vshift[1]) <= s->interlaced) {\r\n+ av_log(avctx, AV_LOG_ERROR, \"impossible height\\n\");\r\n+ return AVERROR_INVALIDDATA;\r\n<\/code><\/pre>\nEin genauerer Blick auf die PixelSmash-Schwachstelle<\/h2>\n
FFmpeg und Medien-Codecs\u00a0\u2013 eine universelle Angriffsfl\u00e4che<\/h3>\n
CVE-2026-8461\u00a0\u2013 Heap-Out-of-Bounds-Write im MagicYUV-Decoder<\/h2>\n
Hintergrund<\/h3>\n
\n
Die Ursache: eine Inkonsistenz bei der Rundung<\/h3>\n
allocated chroma rows = AV_CEIL_RSHIFT(FFALIGN(32, 32), 1) = 16\r\n<\/code><\/pre>\ns->slice_height = bytestream2_get_le32u(&gb);\r\n<\/code><\/pre>\n\/\/ magicyuv.c:559 - number of slices\r\ns->nb_slices = (32 + 31 - 1) \/ 31 = 2;\r\n\r\n\/\/ magicyuv.c:275 - chroma rows per slice (ceiling-rounded)\r\nint sheight = AV_CEIL_RSHIFT(31, 1) = 16;\r\n<\/code><\/pre>\n\r\n\/\/ magicyuv.c:287\r\ndst = p->data[1] + j * height * stride\r\n = p->data[1] + 1 * 16 * stride \/\/ row 16 of a 16-row buffer!\r\n<\/code><\/pre>\n\r\n\/\/ magicyuv.c:291-294\r\nfor (k = 0; k < height; k++) {\r\n bytestream_get_buffer(&slice, dst, width); \/\/ OOB WRITE\r\n dst += stride;\r\n}\r\n<\/code><\/pre>\n\r\n\/\/ magicyuv.c:566-568 - guard ONLY for interlaced mode\r\nif (s->interlaced) {\r\n if ((s->slice_height >> s->vshift[1]) < 2)\r\n<\/code><\/pre>\n\r\n==PID==ERROR: AddressSanitizer: heap-buffer-overflow\r\nWRITE of size 512 at 0x52500000214f thread T0\r\n #2 bytestream_get_buffer libavcodec\/bytestream.h:367\r\n #3 magy_decode_slice libavcodec\/magicyuv.c:292\r\n #5 magy_decode_frame libavcodec\/magicyuv.c:630\r\n\r\n0x52500000214f is located 0 bytes after 8271-byte region\r\n<\/code><\/pre>\n![\"Pixelsmash](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2026\/06\/21161320\/Pixelsmash-Diagram-1-1024x677.png\"){kind=tracking}
<\/p>\nVom OOB-Write zur Codeausf\u00fchrung: AVBuffer kapern<\/h3>\n
buf->free(buf->opaque, buf->data);\r\n<\/code><\/pre>\nsystem(cmd_string); \/\/ attacker's shell command executes\r\n<\/code><\/pre>\n\r\nOOB + 0: [88 bytes of zeros - command string hole]\r\nOOB + 88: [glibc chunk headers - must be preserved]\r\nOOB + 256: AVBuffer struct:\r\n +256 .data = Cb_data pointer\r\n +264 .size = 0x284f\r\n +272 .refcount = 1 <- we write 1\r\n +280 .free = <- we overwrite with &system\r\n +288 .opaque = <- we overwrite with &cmd_string OOB + 384: AVBufferRef.buffer -> points back to AVBuffer at +256\r\n<\/code><\/pre>\n\n
![\"Pixelsmash-Diagramm](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2026\/06\/21161505\/Pixelsmash-Diagram-2-1024x679.png\"){kind=tracking}
<\/p>\nVom Absturz zur RCE: Eine Schwachstelle eskalieren<\/h2>\n
\n
Exploit in der Praxis: RCE auf einem Jellyfin-Medienserver<\/h2>\n
Kalibrierung: Warum das Heap-Layout wichtig ist<\/h3>\n
\n
\r\nffprobe -analyzeduration 200M -probesize 1G -threads 0 -v warning\r\n -print_format json -show_streams -show_chapters -show_format\r\n -show_frames -only_first_vframe -i file:\r\n<\/code><\/pre>\n\n
Der Exploit<\/h3>\n
\n
Das Ergebnis: Reverse Shell durch einen Video-Upload<\/h3>\n
$ nc -l 4444\r\njellyfin@ubuntu-vm:~$ id\r\nuid=115(jellyfin) gid=121(jellyfin) groups=121(jellyfin),29(audio),44(video),100(users)\r\njellyfin@ubuntu-vm:~$ whoami\r\njellyfin\r\n<\/code><\/pre>\n\n