Pixelsmash Vulnerability in ffmpeg (CVE-2026-8461) - Is Emby vulnerable?

[CHBMB 10]

With the public announcement of pixelsmash (see CVE report here) Could we get some clarity regarding where we stand with Emby and this vulnerability please?

It appears Jellyfin have already fixed it and were notified about t he vulnerability before it was made public, and Plex isn't vulnerable due to their customisation of ffmpeg.

I couldn't find any information regarding where Emby sits with regard to this and would appreciate some clarity.

Thanks

 

 

Edited Tuesday at 05:43 PM by CHBMB
Improve title

[Pejamas 64]

Came here straight after seeing the jellyfin post on reddit expecting to see an update.

[CHBMB 10]

I've sent a PM to the Emby devs as well, but, whilst it's been read by one of them, no reply as of yet.

[CHBMB 10]

Reading here it doesn't sound like Emby got a heads up, and it doesn't sound like a remote code execution can happen on Emby either, like it could on Jellyfin, but an Emby server could be crashed.   Less than ideal, but far less worrying than a RCE.  They also tested v4.8.11 rather than the current release.

[cowdoy 0]

Yeah I would love to see some sort of communication from the team about this. Doesn't make me feel great about running this on my system.

[Luke 42624]

Hi, we are currently reviewing this. Thanks.

[xe` 47]

It would helpful if we could get as early a notice as possible if we need to shutdown Emby in the short term.

Please dont wait until you have completed every in depth review, development, compilation and blog post step before giving that heads up.

Let people make early decisions on their own even working with imperfect information.

[me@jackbenda.com 12]

Just bumping this with some concern. Cheers team Emby!

[ike301 0]

So, do we get an update today? 

[RanmaCanada 548]

It appears Emby is affected as per all the documentation, but it's "just" DOS attack, and possible code execution if you have weak memory protections. Jellyfin was full on remotely exploitable. If you use any of the messaging and social media apps listed, you are at far greater risk as you have no control over those. 

Hopefully we get an update. Frustrating they told Jellyfin devs and no one else before releasing it..

[rbjtech 5368]

Lets wait for the official response but Emby are on the case...

 

[Luke 42624]

Hi, we are currently working on publishing 4.10.0.16 beta, which will have the magicyuv decoder disabled. Thanks.

[Ranse 8]

20 minutes ago, Luke said:

Hi, we are currently working on publishing 4.10.0.16 beta, which will have the magicyuv decoder disabled. Thanks.

Hi @Luke any plans for stable release ?  I would rather stay on stable release , but at the same time don't want to have the server vulnerable to this.

[TMCsw 277]

Emby? @Luke? Could you please address this? You have released a beta to block this vulnerability, but are you going to force us to run a beta version on our primary instance so we don’t get hacked? Everybody says run the beta at your own risk; it may have bugs…

I see this CVE is most risky for people who download torrents, but if left unaddressed, it could make its way into IPTV or OTA stuff.

Or is the stable version immune to this?

Edited 16 hours ago by TMCsw

[Jdiesel 1453]

Maybe they want to test the fix in the beta channel before blindly pushing a hotfix to stable? That is the purpose of beta testing is it not?

[TMCsw 277]

33 minutes ago, Jdiesel said:

Maybe they want to test the fix in the beta channel before blindly pushing a hotfix to stable?

Then they should say that, no?

[ruby362 1]

Just confirming: Pre-release with fix now available.

 

Edited 9 hours ago by ruby362

[rbjtech 5368]

5 hours ago, ruby362 said:

Just confirming: Pre-release with fix now available.

 

Yes - I can confirm the magicyuv decoder is now disabled in ffmpeg.  Tks Emby.

4.10.0.15

C:\Emby-Server>system.old\ffmpeg -decoders | find "magicyuv"
ffmpeg version 5.1-emby_2023_06_25_p4 Copyright (c) 2000-2022 the FFmpeg developers and softworkz for Emby LLC
  built with gcc 12.2.0 (Rev10, Built by MSYS2 project)
Execution Date: 2026-06-26 14:24:48
 VFS..D magicyuv             MagicYUV video
EXIT

4.10.0.16

C:\Emby-Server>system\ffmpeg -decoders | find "magicyuv"
ffmpeg version 5.1-emby_2023_06_25_p5 Copyright (c) 2000-2022 the FFmpeg developers and softworkz for Emby LLC
  built with gcc 12.2.0 (Rev10, Built by MSYS2 project)
Execution Date: 2026-06-26 14:24:39
EXIT

 

[me@jackbenda.com 12]

How's the stable fix coming along, team Emby? 

[saikou 2]

Pushed into the latest beta and not as a hotfix is really disappointing. Regardless, thank you for the fix.

[rbjtech 5368]

For those that do not want to wait - You can possibly just replace the ffmpeg from the beta.   I would suggest keeping a copy of the stable ffmpeg to rollback if this does not work, but it would seem unlikely that a newer ffmpeg would fail to work with the stable codebase imo.

Beta source here - just extract the ffmpeg from the zip's etc - do not replace ALL the files !

https://github.com/MediaBrowser/Emby.Releases/releases/tag/4.10.0.16

Try at your own risk - I have not tested this.

[RanmaCanada 548]

49 minutes ago, saikou said:

Pushed into the latest beta and not as a hotfix is really disappointing. Regardless, thank you for the fix.

Why? The issue with this is someone has to put the infected file onto your server, and then has to wait for ffmpeg to do it's thing, and even then, Emby is apparently not RCE capable. If you're not getting your files from questionable sources, and doing it all yourself, you really have nothing to worry about. I remember when everyone was freaking out back when there was the subtitle exploit, and people blew it out of proportion. You could fully RCE a system with en embedded subtitle, but again, if you weren't getting your files from sketchy sources, you had nothing to worry about.

[brcarls 1]

34 minutes ago, RanmaCanada said:

Why? The issue with this is someone has to put the infected file onto your server, and then has to wait for ffmpeg to do it's thing, and even then, Emby is apparently not RCE capable. If you're not getting your files from questionable sources, and doing it all yourself, you really have nothing to worry about. I remember when everyone was freaking out back when there was the subtitle exploit, and people blew it out of proportion. You could fully RCE a system with en embedded subtitle, but again, if you weren't getting your files from sketchy sources, you had nothing to worry about.

How do you know this?   As far as I know, Emby has not said that they even know if they have a problem or the scope of their vulnerability.

In any case, if your speculation is accurate, then everyone who is ripping their own media is safe.  The other 99.999999% of users should probably shut down their instance and use something else while waiting for a production fix or at least some indication from Emby as to the level of risk.