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.

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 1 hour ago by Q-Droid

[ebr 16451]

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]

10 minutes 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: If this CVE is specific to video codecs and not in any way affected by images then I retract what I posted. But if a file delivered as an image can contain a malicious payload and still be consumed by ffmpeg as if it were a video there could be other vectors to exploit this.

 

 

Edited 29 minutes ago by Q-Droid

[softworkz 5240]

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

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

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.