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

[Q-Droid 1041]

There is no real world RCE with this CVE for Emby or Jellyfin. Read the CVE info and the investigative report. In order for them to exploit with RCE they had to explicitly disable a long standing and enabled by default kernel security feature, ASLR. It was the only way they were able to craft a payload that could result in RCE. The investigators are very clear about this in their post.

DoS, silent process/thread failures and possibly server process crash are the realistic scenarios AFTER a malicious payload gets on the server for ffmpeg to process.

This part is not a concern as I've been told that ffmpeg is not involved in processing downloaded metadata images. It is still entirely possible for this type of payload (image) to get on anyone's server because almost every Emby user relies on 3rd parties to provide metadata (images) for our content. Those images we all get from any number of sources could possibly be used exploit this CVE.

 

Edited 17 hours ago by Q-Droid

[ebr 16454]

30 minutes ago, Q-Droid said:

Those images we all get from any number of sources could possibly be used exploit this CVE.

Since the vulnerability is in ffmpeg, how would an image provide an exploit surface in Emby?

We are addressing the issue but RBJ is correct, the actual risk here is very low and should be pretty easy to identify (due to the huge size of a bad video).  Beta is already handled and stable is in-process.

[Q-Droid 1041]

1 hour ago, ebr said:

Since the vulnerability is in ffmpeg, how would an image provide an exploit surface in Emby?

We are addressing the issue but RBJ is correct, the actual risk here is very low and should be pretty easy to identify (due to the huge size of a bad video).  Beta is already handled and stable is in-process.

Is ffmpeg used to process metadata images in any way? Is it used to render, resize, scan or modify banners, actors, directors, thumbs, station logos, etc?

Edit to add: I've been told that ffmpeg is not in the workstream for downloaded metadata images.

 

Edited 17 hours ago by Q-Droid

[softworkz 5244]

52 minutes ago, CHBMB said:

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.

We DO have a process in place and a way for confidential disclosure of security issues: 

https://github.com/EmbySupport/Emby.Security/security/advisories

Three cases have been processed (analyzed, fixed, validated, released, advisory published) already, two others are in progress. Once confirmed and the patched versions are available, these will be published as well.

[softworkz 5244]

16 minutes ago, Q-Droid said:

Edit to add: If this CVE is specific to video codecs

It is specific to that single video codec, prmiarily used in professional post-production (lossless compression, fast and multithreaded decoding, huge video files but still much smaller than individual images).

[Q-Droid 1041]

2 minutes ago, softworkz said:

It is specific to that single video codec, prmiarily used in professional post-production (lossless compression, fast and multithreaded decoding, huge video files but still much smaller than individual images).

Yeah but it doesn't really matter what that video codec is used for. What matters is if ffmpeg detects it, no? In other words if the content, regardless of size, happens to be identified by ffmpeg as MagicYUV then that opens the door to the exploit.

[Smitty018210 162]

9 minutes ago, softworkz said:

We DO have a process in place and a way for confidential disclosure of security issues: 

https://github.com/EmbySupport/Emby.Security/security/advisories

Three cases have been processed (analyzed, fixed, validated, released, advisory published) already, two others are in progress. Once confirmed and the patched versions are available, these will be published as well.

Because not all us use GitHub? I freaking hate that site. This kind of info HAS to posted here, on the forum. 

[softworkz 5244]

1 minute ago, Q-Droid said:

Yeah but it doesn't really matter what that video codec is used for. What matters is if ffmpeg detects it, no? In other words if the content, regardless of size, happens to be identified by ffmpeg as MagicYUV then that opens the door to the exploit.

Yes, like it has been said before, if you get to acquire such video from a malicious source, then ffprobe (not ffmpeg) might crash. But not Emby Server. It would continue to be working.

[softworkz 5244]

7 minutes ago, Smitty018210 said:

Because not all us use GitHub? I freaking hate that site. This kind of info HAS to posted here, on the forum. 

We do not have thje capacity to re-program a complex portal like this - and I don't mean whole GitHub - I mean the vulnerability reporting alone. They have proper separation of private and public information exchange and reporters of vulnerabilities like it, because they are getting proper credits for their findings through GitHub. The ability to acquire CVE numbers has its own hurdles and is not something we can deal with - GitHub handles all of this very well.
Apart from that, the way for reporting that we provide is not even up for debate.

[RanmaCanada 549]

3 hours 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.

I literally posted up above what the exploit covers..Jellyfin was the only one that had full RCE and that is why they were contacted..Please read the entire thread before making such baseless remarks. But I'll post it again..

[brcarls 2]

9 minutes ago, RanmaCanada said:

baseless remarks

 

Baseless?   My observations were 100% accurate.   Unless you have access to the Emby source code, you were speculating, end of story.

 

[TMCsw 278]

I’m mostly satisfied that this has been addressed,

But one last question, TRIALERS from YouTube?

I don’t think YouTube is trustworthy (have you seen the BS ads they allow?)

Also, how can we know if these are huge trailer files?

[softworkz 5244]

10 minutes ago, TMCsw said:

I’m mostly satisfied that this has been addressed,

But one last question, TRIALERS from YouTube?

I don’t think YouTube is trustworthy (have you seen the BS ads they allow?)

Also, how can we know if these are huge trailer files?

No video that you upload to YouTube is served directly.

Videos are always processed and re-encoded in different sizes and qualities, codecs and separate audio tracks.

Further, Emby is always embedding the YouTube html player in one or the other way. It is not allowed to download pure videos from YT and play them with your own player.
Since the YT player is web-based and no browser engine supports MagicYUV, there's absolutely no chance for this to happen - even at (these) two levels.

Edited 11 hours ago by softworkz

[TMCsw 278]

thanks

[sh0rty 748]

Thanks for beta patch. 

Edited 1 hour ago by sh0rty

[CHBMB 16]

18 hours ago, softworkz said:

We DO have a process in place and a way for confidential disclosure of security issues: 

https://github.com/EmbySupport/Emby.Security/security/advisories

Three cases have been processed (analyzed, fixed, validated, released, advisory published) already, two others are in progress. Once confirmed and the patched versions are available, these will be published as well.

Sure, so you have somewhere to disclose concerns, and then that can be tracked there, but my point wasn't "what" is done, more "what is communicated" 

 

For all we know, the whole Emby team may have had sleepless nights and worked round the clock to push a fix, let the community know and they'll rally around you and be supportive, but taking a long time to reply and just stating "We're looking into it" doesn't illustrate what's is actually happening.

 

The fact there was a CVE and there are other CVEs and there will be further CVEs is inevitable.  But how this is communicated, how it looks to the users, the "optics" of the situation can be controlled by yourselves. 

 

Personally I was frustrated I bought up a CVE, created a thread, PM'd the team, my PM was read, yet I then saw multiple replies to other, somewhat, trivial threads occurring in the same subforum without any acknowledgement of either the thread or the PM, from memory it took about 1 hour to see my PM had been read, but then about 15 hours to get a reply on the thread, and my PM was never replied to.

 

Granted I wasn't aware of the Github repo to report CVEs but at the same time, this was already being reported across the internet, so I don't think it would be classed as irresponsible disclosure.

 

Improve the communication and a lot of the comments on this thread melt away.

 

"Hi, thanks for bringing this to our attention, rest assured we're looking at it immediately, and our initial assessment is that we think there's minimal risk here for you guys, but if you wanted to be cautious, we'd suggest stop media ingestion until we push a fix, we intend to initially push a fix onto beta, and if all is well, after 24 hours, we'll backport it to stable, our provisional ETA to provide a fix and push to beta is 48 hours"

 

See how the work you guys do is going to be the same, but the statement above gives a whole different perception to the scenario.

 

Like I said before, I love the Emby project, but sometimes it's difficult to defend the communication, I'm genuinely not attacking you, it's user feedback and showing you how it looks from our perspective.

 

None of this is a criticism of what has been done, other than I don't understand the rationale of pushing a fix to beta rather than stable, but again, communicate why that decision has been made, show us the rationale and maybe we'd understand.

 

It must be disheartening to read posts like my last couple, but it genuinely doesn't need to be that way.

Edited 55 minutes ago by CHBMB

[softworkz 5244]

29 minutes ago, CHBMB said:

Sure, so you have somewhere to disclose concerns, and then that can be tracked there, but my point wasn't "what" is done, more "what is communicated" 

For all we know, the whole Emby team may have had sleepless nights and worked round the clock to push a fix, let the community know and they'll rally around you and be supportive, but taking a long time to reply and just stating "We're looking into it" doesn't illustrate what's is actually happening.

Granted - communication can be improved, but at that point there wasn't really more to say than "we're looking into it", because it required us to get several people together who are working on the build and release processes for the various platforms and all their expertise, views and concerns had to be heared and considered to get to a decision what we will do about it.
 

34 minutes ago, CHBMB said:

None of this is a criticism of what has been done, other than I don't understand the rationale of pushing a fix to beta rather than stable, but again, communicate why that decision has been made, show us the rationale and maybe we'd understand.

Normally, we have two active build setups, one for beta and one for stable. For most platforms, FFmpeg is independent from the server build, but for most Linux based platforms it's not. Right now we're in a transition phase: The beta is about to become released as stable and we already have the other build path set up for the future 8.0-based ffmpeg. Trying to return to the old stable setup for producing a release with only the ffmpeg change could be risky and might cause regressions - but it's one option. The other option is to release the current beta as stable - as planned. This still takes a few more days to evaluate.

So it's not that the beta gets the patch first because it has a higher priority. The highest priority is always the stable release as it affects a high multiple of users, and that means it requires more planning, consideration and testing than the beta and in turn may take longer to get a patch released.

I can assure you that we are trying to get a new stable out as soon as possible - one or the other way.

Thanks for your friendly criticism.