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

[Q-Droid 1040]

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. 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 15 minutes ago by Q-Droid

[ebr 16453]

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

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 5 minutes ago by Q-Droid

[softworkz 5241]

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

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

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

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

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

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.