![\"Pixelsmash](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2026\/06\/21161456\/Pixelsmash-863x300-1.png\"){kind=tracking}
<\/p>\n<\/p>\n
L\u2019\u00e9quipe de recherche en s\u00e9curit\u00e9 de JFrog a r\u00e9cemment d\u00e9couvert et divulgu\u00e9 une vuln\u00e9rabilit\u00e9 critique dans FFmpeg, le framework de traitement multim\u00e9dia le plus largement d\u00e9ploy\u00e9 au monde. La vuln\u00e9rabilit\u00e9 d\u00e9couverte, que nous avons baptis\u00e9e PixelSmash<\/strong>, porte l’identifiant CVE-2026-8461<\/strong>\u00a0. Il s’agit d’une \u00e9criture hors limites dans le tas au niveau du d\u00e9codeur MagicYUV (CVSS 8.8 \u00e9lev\u00e9e). Nous avons fait passer cette vuln\u00e9rabilit\u00e9 d\u2019un simple plantage \u00e0 une ex\u00e9cution de code \u00e0 distance fiable\u00a0: il suffit de traiter un seul fichier multim\u00e9dia malveillant.<\/p>\n L\u2019\u00e9criture hors limites suffit \u00e0 faire planter toute application utilisant FFmpeg<\/strong>\u00a0: des lecteurs vid\u00e9o de bureau comme Kodi et mpv aux g\u00e9n\u00e9rateurs de miniatures des gestionnaires de fichiers Linux, en passant par les pipelines de transcodage cloud et les serveurs multim\u00e9dias auto-h\u00e9berg\u00e9s. Nous avons d\u00e9montr\u00e9 l\u2019exploit complet en obtenant une ex\u00e9cution de code \u00e0 distance sur deux cibles ind\u00e9pendantes\u00a0: un serveur multim\u00e9dia Jellyfin<\/strong> (via une analyse automatique de la biblioth\u00e8que) et une instance Nextcloud<\/strong> (via le fournisseur d\u2019aper\u00e7us vid\u00e9o), dans les deux cas, en t\u00e9l\u00e9versant simplement un fichier\u00a0AVI sp\u00e9cialement con\u00e7u de 50\u00a0Ko.<\/p>\n Il est recommand\u00e9 aux utilisateurs de FFmpeg de passer \u00e0 la version corrig\u00e9e d\u00e8s que possible. Si le d\u00e9codeur MagicYUV n\u2019est pas n\u00e9cessaire, il peut \u00eatre d\u00e9sactiv\u00e9 lors du build (voir notre section \u00ab\u00a0Solutions de contournement\u00a0\u00bb ci-dessous).<\/strong><\/p>\n FFmpeg est int\u00e9gr\u00e9 ou li\u00e9 par pratiquement toutes les applications de traitement multim\u00e9dia sur toutes les plateformes, ce qui signifie que la surface d’exposition est consid\u00e9rable. Nous avons confirm\u00e9 des plantages sur Kodi, mpv, ffmpegthumbnailer (utilis\u00e9 par GNOME, KDE, XFCE), Jellyfin, Emby, Nextcloud, Immich, PhotoPrism et OBS\u00a0Studio, entre autres, et d\u00e9montr\u00e9 une ex\u00e9cution de code \u00e0 distance compl\u00e8te sur Jellyfin.<\/p>\n PixelSmash est une vuln\u00e9rabilit\u00e9 de la cha\u00eene d\u2019approvisionnement logicielle\u00a0: un seul bug dans un seul d\u00e9codeur de codec au sein de FFmpeg, une d\u00e9pendance fondamentale int\u00e9gr\u00e9e dans des centaines de projets en aval, se r\u00e9percute sur chaque application qui est li\u00e9e \u00e0 libavcodec<\/strong>. Aucun des projets concern\u00e9s (Jellyfin, mpv, Nextcloud, Immich, OBS, vLLM et bien d’autres) n’a introduit ce bug. Ils en ont h\u00e9rit\u00e9 silencieusement via leur d\u00e9pendance \u00e0 FFmpeg, et la plupart ne disposent d\u2019aucun m\u00e9canisme pour le d\u00e9tecter ou l\u2019att\u00e9nuer de mani\u00e8re ind\u00e9pendante.<\/p>\n Dans cet article de blog technique, nous expliquerons la cause profonde de la vuln\u00e9rabilit\u00e9, d\u00e9taillerons l\u2019exploitation \u00e9tape par \u00e9tape, du plantage \u00e0 l\u2019ex\u00e9cution de code, et d\u00e9montrerons une ex\u00e9cution de code \u00e0 distance en conditions r\u00e9elles sur un serveur multim\u00e9dia Jellyfin, d\u2019un simple fichier vid\u00e9o t\u00e9l\u00e9vers\u00e9 \u00e0 un reverse shell.<\/p>\n Nous tenons \u00e0 remercier les \u00e9quipes de s\u00e9curit\u00e9 de FFmpeg et Jellyfin pour leur r\u00e9activit\u00e9 dans le traitement de ces probl\u00e8mes.<\/p>\n Afin d\u2019exploiter PixelSmash, un auteur d\u2019attaque doit fournir un fichier multim\u00e9dia sp\u00e9cialement con\u00e7u (conteneur AVI, MKV ou MOV) \u00e0 toute application qui d\u00e9code la vid\u00e9o \u00e0 l\u2019aide de libavcodec de FFmpeg. Il s\u2019agit notamment des \u00e9l\u00e9ments suivants\u00a0:<\/p>\n Aucune authentification, aucun privil\u00e8ge sp\u00e9cial ou acc\u00e8s pr\u00e9alable au syst\u00e8me cible n\u2019est requis au-del\u00e0 de la capacit\u00e9 de livrer un fichier multim\u00e9dia, la surface d\u2019attaque par d\u00e9faut de toute application de traitement multim\u00e9dia.<\/p>\n Pour d\u00e9tecter si votre syst\u00e8me inclut le d\u00e9codeur MagicYUV vuln\u00e9rable, ex\u00e9cutez\u00a0:<\/p>\n Si la sortie inclut VFS..D magicyuv, votre build FFmpeg est vuln\u00e9rable. Le d\u00e9codeur MagicYUV est activ\u00e9 par d\u00e9faut<\/strong> dans chaque build FFmpeg en amont et dans chaque package de distribution que nous avons test\u00e9 (Ubuntu, Debian, Fedora, Arch, Alpine) avant la version\u00a09.0.<\/p>\n S\u2019il n\u2019est pas imm\u00e9diatement possible de mettre \u00e0 niveau FFmpeg\u00a0:<\/p>\n Option 1 – Proc\u00e9der au rebuild de FFmpeg avec le d\u00e9codeur vuln\u00e9rable d\u00e9sactiv\u00e9\u00a0:<\/strong><\/p>\n <\/p>\n Option 2 – Appliquer le correctif minimal (7 lignes ajout\u00e9es \u00e0 libavcodec\/magicyuv.c)\u00a0:<\/p>\n <\/p>\n Cela rejette les valeurs slice_height mal form\u00e9es qui d\u00e9clenchent l\u2019\u00e9criture OOB. L\u2019encodeur MagicYUV de r\u00e9f\u00e9rence \u00e9met toujours des hauteurs de tranche align\u00e9es, de sorte que cela ne rejette que les entr\u00e9es malveillantes.<\/p>\n FFmpeg est l\u2019\u00e9pine dorsale du traitement multim\u00e9dia dans l\u2019ensemble de l\u2019\u00e9cosyst\u00e8me logiciel. Il est li\u00e9 ou int\u00e9gr\u00e9 par la quasi-totalit\u00e9 des applications qui traitent de la vid\u00e9o\u00a0: des lecteurs de bureau (mpv, VLC) aux serveurs multim\u00e9dias auto-h\u00e9berg\u00e9s (Jellyfin, Plex, Emby), en passant par les pipelines de transcodage cloud (AWS\u00a0MediaConvert, Cloudflare\u00a0Stream) et les environnements de bureau Linux (GNOME, KDE, XFCE l\u2019utilisent pour les miniatures vid\u00e9os).<\/p>\n La biblioth\u00e8que libavcodec<\/strong> de FFmpeg contient des d\u00e9codeurs pour des centaines de codecs vid\u00e9o et audio. Chaque d\u00e9codeur analyse les donn\u00e9es du flux de bits contr\u00f4l\u00e9 par l\u2019auteur de l\u2019attaque et \u00e9crit les pixels d\u00e9cod\u00e9s dans des tampons de trame allou\u00e9s sur le tas. Un bug dans n\u2019importe quel d\u00e9codeur est accessible depuis toute application qui traite le format multim\u00e9dia correspondant, ce qui fait des bugs de codec l\u2019une des classes de vuln\u00e9rabilit\u00e9s ayant le plus d\u2019impact dans l\u2019\u00e9cosyst\u00e8me logiciel.<\/p>\n MagicYUV<\/strong> est un codec vid\u00e9o sans perte con\u00e7u pour les workflows de montage vid\u00e9o haute performance. Bien qu\u2019il ne soit pas aussi connu que H.264 ou VP9, son d\u00e9codeur est compil\u00e9 dans chaque build FFmpeg par d\u00e9faut et enregistr\u00e9 pour les conteneurs AVI, MKV et MOV. Toute application capable d\u2019ouvrir un fichier vid\u00e9o peut d\u00e9clencher le d\u00e9codeur MagicYUV.<\/p>\n En compression vid\u00e9o, une tranche est une r\u00e9gion distincte, divis\u00e9e horizontalement, d\u2019une seule image vid\u00e9o qui peut \u00eatre d\u00e9cod\u00e9e ind\u00e9pendamment du reste de l\u2019image.<\/p>\n La vid\u00e9o num\u00e9rique stocke rarement les images en RVB (rouge, vert, bleu) standard. Au lieu de cela, elle utilise l\u2019espace colorim\u00e9trique YUV, qui divise une image en couches ou \u00ab\u00a0plans\u00a0\u00bb distincts\u00a0:<\/p>\n La vuln\u00e9rabilit\u00e9 est un d\u00e9passement de tampon sur le tas d\u2019une ligne dans la gestion des tranches du d\u00e9codeur MagicYUV, caus\u00e9 par une incoh\u00e9rence entre la fa\u00e7on dont l\u2019allocateur de trames et le d\u00e9codeur calculent la hauteur des plans Chroma.<\/p>\n MagicYUV encode la vid\u00e9o en tranches horizontales. Pour les formats de pixels sous-\u00e9chantillonn\u00e9s comme YUV420P (o\u00f9 les plans Chroma ont la moiti\u00e9 de la r\u00e9solution verticale du plan Luma), le d\u00e9codeur doit convertir les hauteurs de tranche des lignes Luma en lignes Chroma \u00e0 l\u2019aide de d\u00e9calages \u00e0 droite arrondis \u00e0 l\u2019entier sup\u00e9rieur.<\/p>\n Le probl\u00e8me\u00a0: lorsque slice_height est impair, le d\u00e9calage arrondi \u00e0 l\u2019entier sup\u00e9rieur (AV_CEIL_RSHIFT) ajoute une ligne suppl\u00e9mentaire par tranche. Sur plusieurs tranches, ces lignes suppl\u00e9mentaires s\u2019accumulent au-del\u00e0 de la fin du tampon qui a \u00e9t\u00e9 allou\u00e9 pour le plan Chroma.<\/p>\n Le probl\u00e8me peut \u00eatre d\u00e9compos\u00e9 selon les \u00e9tapes suivantes\u00a0:<\/p>\n 1. L’allocateur de trames calcule la hauteur que doit avoir le tampon du plan de chrominance. Dans update_frame_pool (get_buffer.c), la hauteur de la trame est align\u00e9e sur 32, puis divis\u00e9e par deux pour Chroma\u00a0:<\/p>\n Le tampon du plan de chrominance est allou\u00e9 pour 16 lignes.<\/p>\n 2.\u00a0Le d\u00e9codeur lit slice_height directement \u00e0 partir du flux de bits contr\u00f4l\u00e9 par l\u2019auteur de l\u2019attaque (magicyuv.c:550)\u00a0:<\/p>\n Avec notre valeur sp\u00e9cialement con\u00e7ue de slice_height = 31 et coded_height = 32, le d\u00e9codeur calcule\u00a0:<\/p>\n 3. Pour la deuxi\u00e8me (derni\u00e8re) tranche, le d\u00e9codeur calcule le pointeur de destination\u00a0:<\/p>\n Le tampon Chroma comporte les lignes\u00a00 \u00e0 15 (16\u00a0lignes). Le d\u00e9codeur \u00e9crit \u00e0 la ligne\u00a016, une ligne compl\u00e8te au-del\u00e0 de la fin de l\u2019allocation.<\/p>\n 4.\u00a0L\u2019\u00e9criture OOB se d\u00e9clenche. En mode brut, le d\u00e9codeur copie directement les octets contr\u00f4l\u00e9s par l’attaquant\u00a0:<\/p>\n <\/p>\n Avec width = 640 (pour notre coded_width = 1280, divis\u00e9 par deux pour Chroma), cela d\u00e9pose 640\u00a0octets enti\u00e8rement contr\u00f4l\u00e9s par l\u2019auteur de l\u2019attaque dans le bloc de tas qui suit imm\u00e9diatement le tampon du plan Chroma.<\/p>\n La validation existante de slice_height dans magicyuv.c:566 v\u00e9rifie uniquement le chemin de code entrelac\u00e9 \u2013 le chemin non entrelac\u00e9 que nous exploitons ne comporte aucun contr\u00f4le d\u2019alignement\u00a0:<\/p>\n <\/p>\n Le rapport ASAN du master en amont confirme pr\u00e9cis\u00e9ment le d\u00e9bordement\u00a0:<\/p>\n <\/p>\n Sch\u00e9ma1\u00a0: disposition du tas<\/em><\/p>\n Un d\u00e9passement de tas n’est utile que si l’attaquant peut \u00e9craser quelque chose de significatif. Dans la disposition du tas de FFmpeg, la r\u00e9ponse est la structure AVBuffer, l\u2019objet de gestion de tampon \u00e0 comptage de r\u00e9f\u00e9rences que FFmpeg alloue imm\u00e9diatement apr\u00e8s les donn\u00e9es de pixels de chaque plan.<\/p>\n Lorsque FFmpeg termine le d\u00e9codage d\u2019une image, il appelle av_frame_unref, qui parcourt la r\u00e9f\u00e9rence de tampon de chaque plan et appelle av_buffer_unref. Dans av_buffer_unref (libavutil\/buffer.c:133), lorsque le compteur de r\u00e9f\u00e9rences atteint z\u00e9ro\u00a0:<\/p>\n <\/p>\n Il s\u2019agit d\u2019un appel indirect via un pointeur de fonction stock\u00e9 dans le tas. Si nous pouvons \u00e9craser buf->free avec l\u2019adresse de system() de libc et buf->opaque avec un pointeur vers une cha\u00eene de commande shell, l\u2019appel indirect devient\u00a0:<\/p>\n <\/p>\n Notre \u00e9criture OOB de 640\u00a0octets tombe directement sur la structure AVBuffer pour le plan Chroma Cb. La disposition du tas dans la r\u00e9gion OOB (captur\u00e9e via GDB sur la version de jellyfin-ffmpeg\u00a07.1.3 fournie avec Jellyfin)\u00a0:<\/p>\n <\/p>\n <\/p>\n L\u2019exploit place une commande shell termin\u00e9e par NUL au d\u00e9calage OOB 0 (le trou de z\u00e9ros de 88\u00a0octets exempt de m\u00e9tadonn\u00e9es glibc), puis \u00e9crase\u00a0:<\/p>\n Lorsque av_buffer_unref se d\u00e9clenche pendant le nettoyage normal des trames, l\u2019appel indirect devient system(“attacker_command”). Le processus enfant du shell dupliqu\u00e9 ex\u00e9cute la commande avant que le processus parent FFmpeg ne plante suite \u00e0 une corruption ult\u00e9rieure du tas, l\u2019effet secondaire s\u2019est d\u00e9j\u00e0 produit.<\/p>\n Le d\u00e9fi critique\u00a0: les en-t\u00eates de blocs malloc de la glibc au sein de la r\u00e9gion OOB doivent \u00eatre conserv\u00e9s \u00e0 l\u2019identique, sinon les appels \u00e0 free() sur des allocations non li\u00e9es d\u00e9tecteront une corruption et interrompront le processus avant que notre av_buffer_unref d\u00e9tourn\u00e9e ne s\u2019ex\u00e9cute. Notre exploit encode les m\u00e9tadonn\u00e9es exactes du chunk observ\u00e9es dans le tas de la cible dans la charge utile OOB, en utilisant un encodage par pr\u00e9diction gauche pour correspondre \u00e0 l\u2019algorithme de d\u00e9compression de MagicYUV.<\/p>\n Sch\u00e9ma2\u00a0: flux d\u2019exploitation<\/em><\/p>\n L\u2019\u00e9criture OOB dans le tas n\u2019est pas seulement un d\u00e9ni de service. Nous l\u2019avons fait \u00e9voluer en une ex\u00e9cution de commandes arbitraires fiable contre la version de FFmpeg\u00a07.1.3 fournie avec Jellyfin.<\/p>\n Avertissement important\u00a0: l\u2019ASLR a \u00e9t\u00e9 d\u00e9sactiv\u00e9 pour cette d\u00e9monstration. Notre exploit n\u00e9cessite des adresses cod\u00e9es en dur pour system() et la cha\u00eene de commande OOB, ce qui signifie qu\u2019il ne fonctionne de mani\u00e8re d\u00e9terministe qu\u2019avec l\u2019ASLR d\u00e9sactiv\u00e9 (setarch x86_64 -R). Dans une configuration Linux par d\u00e9faut avec l\u2019ASLR activ\u00e9, les adresses sont rendues al\u00e9atoires \u00e0 chaque ex\u00e9cution, et l\u2019exploit n\u2019aboutit pas. Cependant, nous avons identifi\u00e9 une vuln\u00e9rabilit\u00e9 de fuite d\u2019informations distincte dans le d\u00e9codeur FlashSV de FFmpeg (libavcodec\/flashsv.c), une divulgation de m\u00e9moire tas non initialis\u00e9e pr\u00e9sente dans FFmpeg en amont depuis juillet\u00a02022 et qui n\u2019a toujours pas \u00e9t\u00e9 corrig\u00e9e au moment de la publication. Elle ne peut \u00eatre exploit\u00e9e qu\u2019en utilisant des indicateurs d\u2019environnement sp\u00e9cifiques pour ffmpeg (par ex., -threads\u00a01), la gravit\u00e9 est donc uniquement informative. En principe, une fuite d\u2019informations similaire qui pourrait \u00eatre d\u00e9couverte \u00e0 l\u2019avenir pourrait \u00eatre associ\u00e9e \u00e0 l\u2019\u00e9criture OOB de MagicYUV afin de contourner l\u2019ASLR et d\u2019ex\u00e9cuter du code \u00e0 distance (RCE) malgr\u00e9 la pr\u00e9sence de toutes les mesures d\u2019att\u00e9nuation, mais cet encha\u00eenement n\u00e9cessite des recherches suppl\u00e9mentaires et n\u2019a pas \u00e9t\u00e9 d\u00e9montr\u00e9. L\u2019\u00e9criture OOB MagicYUV seule (sans contournement d\u2019ASLR) suffit pour un DoS fiable contre chaque cible test\u00e9e.<\/p>\n L\u2019escalade a n\u00e9cessit\u00e9 de relever trois d\u00e9fis d\u2019ing\u00e9nierie\u00a0:<\/p>\n Afin de d\u00e9montrer l\u2019impact concret, nous avons obtenu une ex\u00e9cution de code \u00e0 distance compl\u00e8te sur un serveur multim\u00e9dia Jellyfin\u00a010.11.9, le deuxi\u00e8me serveur multim\u00e9dia auto-h\u00e9berg\u00e9 le plus populaire (apr\u00e8s Plex), via son pipeline d\u2019analyse de biblioth\u00e8que multim\u00e9dia classique.<\/p>\n Chemin d\u2019attaque\u00a0: le t\u00e9l\u00e9chargement d\u2019un fichier AVI MagicYUV sp\u00e9cialement con\u00e7u dans la biblioth\u00e8que multim\u00e9dia -> Jellyfin d\u00e9clenche automatiquement ffprobe pour l\u2019extraction des m\u00e9tadonn\u00e9es -> l\u2019\u00e9criture OOB se d\u00e9clenche -> AVBuffer.free est d\u00e9tourn\u00e9 vers system() -> une commande arbitraire s\u2019ex\u00e9cute en tant qu\u2019utilisateur du service jellyfin (uid\u00a0115).<\/p>\n La disposition du tas de la r\u00e9gion OOB d\u00e9pend des arguments exacts de la ligne de commande ffprobe et de la longueur du chemin d\u2019acc\u00e8s au fichier d\u2019entr\u00e9e. Nous l’avons d\u00e9couvert au cours de trois cycles complets de recalibrage\u00a0:<\/p>\n <\/p>\n Notre calibrage final vise un chemin d\u2019acc\u00e8s au fichier de 60\u00a0caract\u00e8res (correspondant \u00e0 la structure de la biblioth\u00e8que multim\u00e9dia par d\u00e9faut de Jellyfin). L\u2019exploit AVI\u00a0:<\/p>\n L\u2019int\u00e9gralit\u00e9 de la charge utile d\u2019exploitation devient un seul fichier AVI de 50\u00a0Ko (mais il peut \u00e9galement s\u2019agir d\u2019un conteneur MKV ou MOV).<\/p>\n Nous avons configur\u00e9 un \u00e9couteur sur la machine de l\u2019auteur de l\u2019attaque et d\u00e9clench\u00e9 une analyse de la biblioth\u00e8que Jellyfin (avec l\u2019ASLR d\u00e9sactiv\u00e9 pour cette d\u00e9monstration, voir la discussion sur l\u2019ASLR ci-dessus). Quelques secondes apr\u00e8s le traitement du fichier t\u00e9l\u00e9vers\u00e9 par le ffprobe de Jellyfin, nous avons obtenu un reverse shell s\u2019ex\u00e9cutant en tant qu\u2019utilisateur du service Jellyfin\u00a0:<\/p>\nQui est affect\u00e9 par PixelSmash\u00a0?<\/h2>\n
Pr\u00e9requis de l\u2019attaque<\/h3>\n
\n
D\u00e9tection<\/h3>\n
ffmpeg -decoders 2>\/dev\/null | grep magicyuv\r\n<\/code><\/pre>\nSolutions de contournement<\/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>\nPlong\u00e9e dans la vuln\u00e9rabilit\u00e9 PixelSmash<\/h2>\n
FFmpeg et codecs multim\u00e9dias\u00a0: une surface d\u2019attaque universelle<\/h3>\n
CVE-2026-8461\u00a0: \u00e9criture hors limites dans le tas dans le d\u00e9codeur MagicYUV<\/h2>\n
Contexte<\/h3>\n
\n
La cause profonde\u00a0: un \u00e9cart d’arrondi<\/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>\nDe l\u2019\u00e9criture OOB \u00e0 l\u2019ex\u00e9cution de code\u00a0: d\u00e9tournement d\u2019AVBuffer<\/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](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2026\/06\/21161505\/Pixelsmash-Diagram-2-1024x679.png\"){kind=tracking}
<\/p>\nDu plantage \u00e0 la RCE\u00a0: escalader la primitive<\/h2>\n
\n
Exploitation dans le monde r\u00e9el\u00a0: RCE du serveur multim\u00e9dia Jellyfin<\/h2>\n
Calibrage\u00a0: pourquoi la disposition du tas est importante<\/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
L\u2019exploit<\/h3>\n
\n
R\u00e9sultat\u00a0: reverse shell \u00e0 partir d\u2019un t\u00e9l\u00e9versement de vid\u00e9o<\/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