Unauthenticated access to images by itemid

[Guest]

On 4/20/2024 at 11:50 PM, Luke said:

Hi, yes we do plan to address this. Thanks for reporting.

Any update?

[rechigo 364]

13 hours ago, rbjtech said:

I believe it was me (amongst others) that mentioned the industry mechanism for reporting vulnerabilities is the CVE process.  I believe Emby have had more than enough time to address this, so in the interest of public safety, my personal opinion is this should be reported.   If this forces Emby to do something about it - then about time, but on the other hand if it spotlights the issue and causes more visability, then that is a bad thing.   Maybe Emby can respond with a committed deadline on getting it resolved, afterwhich if still no resolution it will be raised.   It's not a zero day or anything like that, but I'm surprised nobody has publicly exploited it yet..

I think logs being anonymized now plays a part in why this hasn't been exploited on a larger scale. Someone made a post in the Jellyfin subreddit and one of their team members actually responded. Jellyfin uses some sort of UUIDs for ItemIds, not an incremental number, so its inherently less vulnerable as the UUID acts as a "password" in a sense, however their images endpoint also requires no auth still. They supposedly have a solution to resolve this within the next major version. If Emby hasnt addressed this by then, then CVE should be reported.

 

 

[sross44 430]

Hi all. As a heads up, this will be resolved in the next build of the beta. As soon as that's done, it will be posted here as well. 

[rechigo 364]

9 minutes ago, sross44 said:

Hi all. As a heads up, this will be resolved in the next build of the beta. As soon as that's done, it will be posted here as well. 

That's wonderful! Would you mind explaining the changes you guys decided to make to fix this?

[adrianwi 279]

Actions speak louder than words, and at this stage, the only assumption you could make is that the emby development team don't really care about security.

There are multiple security issues and feature requests dating back several years, none of which have been addressed.  

After an actual security breach last year, which had been raised as an issue on this forum years before that, you would have thought they might have learned a lesson?

ALL security issues/requests should be addressed before any new features are added to emby. Security should be the number 1 priority, not some after thought years later.

[visproduction 315]

I use an IIS server on the same workstation as Emby and assign a different port number.  Then you can limit access to all images for members only.
https://techexpert.tips/iis/iis-blocking-direct-access-image/

This solves access all my secure family tree type images.  I never use Emby for such images and only add media.  I don't care if the media posters or actor portraits can be linked directly.  I understand that some people want secure images inside Emby.  To me this has no value and if it was available, I would just turn it off to make sure that all pages open as fast as possible. 

[ellisd4 73]

On 10/19/2025 at 11:55 PM, rechigo said:

I wonder if Jellyfin suffers from the same vulnerability. If it does, which would come as a little surprise, I will be interested to see how they handle it. 

 

I remember reading a reply in another post where one of the devs actually responded and claimed it was because requiring auth would break some older clients... a very silly reason to me. usability should never take priority over security. Security should always be no. 1.

That was probably the excuse for not fixing the issue that caused the 2023 Security Breach as well that blew up.  We're two years later and clients are still having to catch up to that "fix".  I'd rather clients cripple along than have security/privacy vulnerabilities. 

[rechigo 364]

5 hours ago, adrianwi said:

Actions speak louder than words, and at this stage, the only assumption you could make is that the emby development team don't really care about security.

There are multiple security issues and feature requests dating back several years, none of which have been addressed.  

After an actual security breach last year, which had been raised as an issue on this forum years before that, you would have thought they might have learned a lesson?

ALL security issues/requests should be addressed before any new features are added to emby. Security should be the number 1 priority, not some after thought years later.

Would you mind linking to some of these other security issues? Since Emby doesnt seem to be taking action on disclosing these issues to users and fixing them

[ellisd4 73]

16 minutes ago, rechigo said:

Would you mind linking to some of these other security issues? Since Emby doesnt seem to be taking action on disclosing these issues to users and fixing them

Agreed!  If there are others that haven't been tackled, I'd be interested as well.   

[pünktchen 1409]

Because it was brought up in an other thread: https://feedly.com/cve/vendors/emby

[rbjtech 5284]

7 hours ago, rechigo said:

Would you mind linking to some of these other security issues? Since Emby doesnt seem to be taking action on disclosing these issues to users and fixing them

A list below - there may be others.

I did a while back speak to the Admins to see if we could have a dedicated 'Security' forum section - but it was not taken up.   I still think think it's a good idea to focus this important topic.  The #1 sticky on it would be 'out the box configuration 'Best Practice', as even that is poor' ..

 

 

[rbjtech 5284]

FYI - I believe the unauthorised image access is being addressed in the next Beta.   Unless all Clients have updates (unlikely) then I'm assuming this is not adding Auth, but just randomising the id's used (as opposed to sequential), but at least it's a step in the right direction...   I'm unsure if a fresh db would be needed to change existing id's - I would guess so.

[ebr 16169]

4 hours ago, rbjtech said:

I'm unsure if a fresh db would be needed to change existing id's

The reason JF has GUIDs as item IDs is because they are us 10 years ago. I know you know that but for the casual reader... 

We changed this design for performance reasons which were significant so we won't be going back.

[rbjtech 5284]

41 minutes ago, ebr said:

The reason JF has GUIDs as item IDs is because they are us 10 years ago. I know you know that but for the casual reader... 

We changed this design for performance reasons which were significant so we won't be going back.

I must confess, I have not noticed any performance issues with JF - I guess the performance you speak of is with the db indexing ?, so a 'slow' db with a fast cpu is masked by other bottlenecks in the system, but you would notice it on a slower system such as a NAS for example ?

[adrianwi 279]

13 hours ago, rechigo said:

Would you mind linking to some of these other security issues? Since Emby doesnt seem to be taking action on disclosing these issues to users and fixing them

 

[rechigo 364]

20 hours ago, rbjtech said:

FYI - I believe the unauthorised image access is being addressed in the next Beta.   Unless all Clients have updates (unlikely) then I'm assuming this is not adding Auth, but just randomising the id's used (as opposed to sequential), but at least it's a step in the right direction...   I'm unsure if a fresh db would be needed to change existing id's - I would guess so.

Well, we will see soon. If they are using some sort of UUID to reference images instead of an incremental number that's fine for me... of course the end goal would be to have an authenticated route, but with how long it took them to apply a potential "bandaid" fix doesn't leave me feeling confident. 

[cptlores 40]

19 hours ago, ebr said:

The reason JF has GUIDs as item IDs is because they are us 10 years ago. I know you know that but for the casual reader... 

We changed this design for performance reasons which were significant so we won't be going back.

If your solution to increase performance is to remove GUID/UUID from links without some equivalent replacement, then the solution is broken. There is no scenario where you replace security with performance gains in a web hosting solution.

[ebr 16169]

5 hours ago, cptlores said:

If your solution to increase performance is to remove GUID/UUID from links without some equivalent replacement, then the solution is broken. There is no scenario where you replace security with performance gains in a web hosting solution.

Hi.  I'm not sure what your point is as we already indicated that this specific issue of accessing random images is being addressed in the next build.  I simply stated we won't be going back to using GUIDs as item IDs as that isn't a good solution.

[cptlores 40]

On 10/24/2025 at 3:39 PM, ebr said:

Hi.  I'm not sure what your point is as we already indicated that this specific issue of accessing random images is being addressed in the next build.  I simply stated we won't be going back to using GUIDs as item IDs as that isn't a good solution.

The point is that removing GUID without a replacement, and having links be guessable for years.... is something that should never have happened in the first place. It's such a basic concept for web apps security that it boggles the mind.  And it hurts your credibility when it comes to making secure software.

Edited October 28, 2025 by cptlores

[Alex.the.Riddler 1]

So is this fixed in either the 4.9.1.90 or 4.9.2.6-beta releases? Or we are waiting on the NEXT beta version?

[Luke 42077]

Hi, just a heads up that the changes for this are not in 4.9.2.7 as a little more time is needed for this .Thanks.

[rechigo 364]

7 hours ago, Luke said:

Hi, just a heads up that the changes for this are not in 4.9.2.7 as a little more time is needed for this .Thanks.

It's like you knew we would be back to comment about this, lol. I saw the new version came out and this was the first thing that came to mind. Thanks for letting us know !

Edited November 30, 2025 by rechigo

[ellisd4 73]

@LukeIs this included in 4.9.2.8 that was released today? 

[Luke 42077]

53 minutes ago, ellisd4 said:

@LukeIs this included in 4.9.2.8 that was released today? 

Hi, no, probably 1-2 more builds away. Thanks.

[ellisd4 73]

Just commenting to note that 4.9.4.1 does not resolve the issue either. At least we got a landing tab for books though. 

I will note that it's not resolved in JellyFin's release today either... just that they use GUIDs and not IDs... not any better.  Nothing should be accessible without Auth.  Period.

Edited December 15, 2025 by ellisd4