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

[CHBMB 19]

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 June 23 by CHBMB
Improve title

[Pejamas 68]

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

[CHBMB 19]

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 19]

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 42794]

Hi, we are currently reviewing this. Thanks.

[xe` 49]

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 563]

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 5374]

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

 

[Luke 42794]

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

[Ranse 10]

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 285]

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 June 26 by TMCsw

[Jdiesel 1469]

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 285]

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 June 26 by ruby362

[rbjtech 5374]

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 3]

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

[rbjtech 5374]

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 563]

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 2]

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.

[rbjtech 5374]

56 minutes ago, brcarls said:

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.

Emby have patched the ffmpeg - or more specifically, they have simply disabled the magicyuv decoder in their custom ffmpeg.   To note,  the magicyuv codec is an uncompressed codec used for professional pre-processing, thus is extremly unlikely to be in 'common' use - if it was, the file sizes would be huge.   If you source unsolicited files from the internet - then I guess there is a slim chance it may become an issue for you, but it will only cause a DoS as Emby does not allow any remote code execution in Emby anyway.  I'm not speaking on behalf of Emby, but the risk of this CVE to Emby is 'low' thus they have taken the steps to remove the risk (by patching ffmpeg in beta) but have, thus far, decided not to panic the community by releasing a 'hotfix' - as this does not warranty this.   I agree with this approach but perhaps a brief paragraph from them explaining the 'why' would be useful.

[CHBMB 19]

I would echo what others have said earlier.

I love Emby, I really do, but, and I say this with genuine "love" sometimes it's not so much what you do, but how this is communicated. 

You had no advance heads up about this vulnerability, which is of no fault of your own, but despite the message being read, it took a long time to acknowledge with no further  information until a fix to the beta branch was announced. 

Commiting the fix to beta in a timely manner is commendable, but for people to patch their server they need to be

1.  Aware of the problem

2.  Willing to run beta software.

 

There will inevitably be large number of Emby admins who are completely unaware but would blindly update to a new stable point release and be blissfully ignorant to any CVE.

I accept that this may not be the most severe CVE in existence and from my understanding no RCE is possible on Emby, however as a standard operating procedure on how to react to these I'd suggest

1.  Acknowledge the issue

2.  Provide a brief assessment of the risk of the CVE and am ETA on a time to fix and any suggested mitigations in the meantime, such as stop ingesting media from any questionable sources, take server offline, sprinkle holy water on the server whilst muttering an incantation. 

3.  Push a fix both to beta and backport to a stable release.

From all the evidence it looks like Emby as a project has escaped serious issue thus far, but having a process in place for the next CVE would be very sensible.

Whilst a lot of what I've said might seem superfluous, there are some situations where the optics of the situation matters a lot. 

We all want Emby as a project to have continued success, if prospective users come to the forum to look around, evidence of a robust security posture and professional approach makes a lot of difference.

Just my opinion, and genuinely meant as constructive criticism.