Unauthenticated access to images by itemid

[Neminem 1518]

2 minutes ago, Abul3ees said:

I think you are overlooking the point that is being made here.  This is a major issue that effects everyone, but is more concerning for publicly hosted servers.  We are just attempting to get some answers and fixes for this issue with the emby team.  This is meant to be more constructive discussion rather than destructive. 

Nice that's the point, but a commend ever blue moon, will not cut it.

I aggravated you and you responded, and now the topic is flaming.

Keep it up to get traction

Then dev's might notice.

Do it daily, do it often, do not forget to raise your point.

[rbjtech 5284]

The issue here is people are not being made aware that an advertised feature in Emby is simply not as secure/private as they would expect it to be.    Admins can implement https, reverse proxies etc - doesn't matter, if you know or can guess the url, then you can get unauthenticated access to the images.    Is an attacker likely to even know the base url, or spend time brute forcing - unlikely, but security by obscurity has no place in 2025.     Randomising the id's/url would be a start, but implementing proper Auth for photo library images would be what I would want to see - if it costs performance, then so be it.   For other general metadata images, then I see no reason to implement Auth for them.

Edited June 11, 2025 by rbjtech

[Neminem 1518]

Guess I need to poke the bear again..

The flame is out.

[Jdiesel 1431]

I just discovered thas thread and will be removing my photo and home video libraries until this has been addressed. It was convenient being able to share photos with family because of the tv app support but I will be looking at migrating this functionality over to Immich as I am already using it for personal use.

Personal photos and videos are the most sensitive information I have and expect the highest level of security. If someone unauthorized wanted to view my Linux iso collection it would be annoying but an accepted level of risk, personal photos absolutely not.

[Clackdor 109]

1 minute ago, Jdiesel said:

I just discovered thas thread and will be removing my photo and home video libraries until this has been addressed. It was convenient being able to share photos with family because of the tv app support but I will be looking at migrating this functionality over to Immich as I am already using it for personal use.

This is exactly why this needs attention. IMO emby is the perfect platform to share photos and videos with family because of the app support. Other alternative solutions cannot compete on this front, and each have their own issues/shortcomings (immich included)

[rhodges 49]

The whole, oh, we can't secure images because of people that want to use a caching service seems like a bad reason for not securing images. By default, it should be secured. If, a user wants to take advantage of something that requires a decreased level of security, then they should be required opt out of security and not the other way around.

Edited June 11, 2025 by rhodges

[Abul3ees 4]

21 hours ago, Jdiesel said:

I just discovered thas thread and will be removing my photo and home video libraries until this has been addressed. It was convenient being able to share photos with family because of the tv app support but I will be looking at migrating this functionality over to Immich as I am already using it for personal use.

Personal photos and videos are the most sensitive information I have and expect the highest level of security. If someone unauthorized wanted to view my Linux iso collection it would be annoying but an accepted level of risk, personal photos absolutely not.

This is exactly why it needs to be explicitly addressed.  I mistakenly stumbled upon this thread and would have had absolutely no idea since it is buried.   

[Abul3ees 4]

Just wanted to give this thread another bump to see if the emby team has any additional information on getting this privacy leak fixed. 

[Neminem 1518]

@Santrexits been 7 days, without you bumping, I don't trust Emby with nudes with my wife in them, so don't care.

I guess after 7 days, you don't either

 

[visproduction 315]

Seems like adding a password access with something like Apache, could then block any image access from direct URLs because .htaccess could be set to not allow images, unless the user has logged into the Apache web space.  This is a 3rd party sort of fix, but it should work for anyone, who needs it.
  https://duckduckgo.com/?q=protecting+.htaccess+images+jpg+app+folders+inside+Apache+Password+access&ia=web

The user experience would change with a username and first password challenge that could appear any style you like, in an HTML login page.  The user's browser, I believe, can cache this and bypass the Apache login page.  Then the user is taken to Emby, which also has the option to remember logins.  If both logins are cached, then the user would just go right in and everything would look the same as before, with no extra Apache request.  Then, even with a complete URL to an image should not work for anyone without the original Apache web service having an active and correct login.  I know that limited jpg works on Apache.  I think also that .jpg (.png, .gif...) access can be allowed, only for logged in users.  But, every webserver would be different.  The obvious drawback is setting it up, can be complex. Since no one seemed to have mentioned this before, then it may not be very practical. .htaccess is cranky and particular.  You have to get it just right.

Does anyone know something similar that would be easier to set up?

Edited June 18, 2025 by visproduction

[darkassassin07 652]

That would also restrict you to web browser access only as embys apps do not support http basic_auth (.htaccess).

 

Embys total silence on this issue isn't exactly encouraging for anyone reading along. It's a pretty prominent topic being closely followed among the self-hosted coms; with JF suffering a similar vulnerability. (being built off the same core code)

[Clackdor 109]

27 minutes ago, darkassassin07 said:

That would also restrict you to web browser access only as embys apps do not support http basic_auth (.htaccess).

 

Embys total silence on this issue isn't exactly encouraging for anyone reading along. It's a pretty prominent topic being closely followed among the self-hosted coms; with JF suffering a similar vulnerability. (being built off the same core code)

For a reverse proxy to properly "fix" this issue it would have to be configured to recognize emby's auth headers to work with client apps (as well as other configuration to properly allow/block the correct paths based on those headers, etc.). I'm not even sure this would be possible, and if it is it would definitely be complex to say the least. I've only vaguely been revisiting this idea again recently.

As far as JF, they still have a similar issue, however the way itemid's are assigned seem to make it slightly less problematic than emby.

Edited June 18, 2025 by Clackdor

[rechigo 364]

Why the f#*k is this still an issue? This is beyond infuriating. Excuse my language, but I just had to pull all of my mixed content libraries off of Emby out of respect for privacy of myself and my family members.

It's so god damn infuriating that not only is this still an issue, but it has hardly been addressed by the devs. I remember this issue years ago when I was first using Emby and was astonished by it then, and that feeling is only tenfold seeing this privacy vulnerability is STILL present nearly 6 years later.

What if a bad actor were to scrape the forum for log files that aren't anonymized, extract the domain name, make a bunch of requests to `https://myembyserver.com/emby/Items/0/Images/Primary` starting from zero, and going up until getting a 404. Bad actor could look for any "questionable" content on the server and potentially use it to blackmail the server administrator.

[rechigo 364]

On 6/18/2025 at 5:52 PM, Clackdor said:

For a reverse proxy to properly "fix" this issue it would have to be configured to recognize emby's auth headers to work with client apps (as well as other configuration to properly allow/block the correct paths based on those headers, etc.). I'm not even sure this would be possible, and if it is it would definitely be complex to say the least. I've only vaguely been revisiting this idea again recently.

As far as JF, they still have a similar issue, however the way itemid's are assigned seem to make it slightly less problematic than emby.

I was just looking into this now as well.. The problem I am seeing is that the client apps I have tested don't even request the endpoint with any form of auth key at all, so hopes of trying to do some hackery with a proxy seems like a no-go...

[BiggusThiccus 0]

Has anything been updated with this?

[aletomic 2]

Please provide an update on this.

[Abul3ees 4]

3 hours ago, rechigo said:

Why the f#*k is this still an issue? This is beyond infuriating. Excuse my language, but I just had to pull all of my mixed content libraries off of Emby out of respect for privacy of myself and my family members.

It's so god damn infuriating that not only is this still an issue, but it has hardly been addressed by the devs. I remember this issue years ago when I was first using Emby and was astonished by it then, and that feeling is only tenfold seeing this privacy vulnerability is STILL present nearly 6 years later.

What if a bad actor were to scrape the forum for log files that aren't anonymized, extract the domain name, make a bunch of requests to `https://myembyserver.com/emby/Items/0/Images/Primary` starting from zero, and going up until getting a 404. Bad actor could look for any "questionable" content on the server and potentially use it to blackmail the server administrator.

I tried revitalizing this concern a few months ago, but to no avail.  The developers are clearly ignoring this blatant security/privacy leak for a reason beyond my knowledge. This privacy issue should be a priority for them to remedy.  

[rechigo 364]

48 minutes ago, Abul3ees said:

I tried revitalizing this concern a few months ago, but to no avail.  The developers are clearly ignoring this blatant security/privacy leak for a reason beyond my knowledge. This privacy issue should be a priority for them to remedy.  

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.

[Abul3ees 4]

2 minutes ago, 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.

I believe Jellyfin does have a similar issue as well.  The devs used to respond early in, but have gone silent in addressing whether or not there are plans for having the issue fixed.  The concerning part is that they still proudly advertise for people to upload their photos to the library, and people have no idea that they can potentially be publicly accessible.  

[rechigo 364]

13 minutes ago, Abul3ees said:

I believe Jellyfin does have a similar issue as well.  The devs used to respond early in, but have gone silent in addressing whether or not there are plans for having the issue fixed.  The concerning part is that they still proudly advertise for people to upload their photos to the library, and people have no idea that they can potentially be publicly accessible.  

That sucks. I hoped they would do better. Looks like devs quit replying to this entirely after 2024. Everything between then and 2020 was them sliding it under the rug by saying they had to update clients to be able to implement an authenticated image endpoint... great..  you guys have had FIVE YEARS to make changes to the clients, and update the server. This is a big privacy issue and could be exploited to target specific Emby users. 

 

Another user on this post brought it up, but we could file a report with CVE or similar. We all should collectively keep an eye on this issue, and if they don't put their foot down and actually address it, we could file a report... 

 

In the meantime, I came across two users on here who made a workaround for nginx to block requests to Images endpoint if the remote IP address cannot be associated with an emby session. When I go back to find them I will be sure to link them here.

[rbjtech 5284]

3 hours ago, rechigo said:

Another user on this post brought it up, but we could file a report with CVE or similar. We all should collectively keep an eye on this issue, and if they don't put their foot down and actually address it, we could file a report... 

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

Edited October 20, 2025 by rbjtech

[barat 27]

3 hours ago, rechigo said:

In the meantime, I came across two users on here who made a workaround for nginx to block requests to Images endpoint if the remote IP address cannot be associated with an emby session. When I go back to find them I will be sure to link them here.

Wow ... was unaware of such an issue. I was planning to open Emby to the world (now I'm using VPN only so no bigger issues) at some point during the Christmas holidays, but now I won't do it until this vulnerability will be fixed. 

Quoting this fragment to have a reference to come at some point to check for those nginx workarounds.

Edited October 20, 2025 by barat

[cptlores 40]

There is a industry standard solution for this problem, and that is using GUID (Globally Unique Identifier) so that it is virtually impossible to guess the links.

Anything else is amateur hour, and Emby having used GUID before and then removing it is ... .. ... 

[dukeofhurl 0]

This is truly awful and sucks so hard. How is this STILL an issue?

[Clackdor 109]

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

This issue is once again circulating on the emby subreddit. Just thought it would be worth mentioning that this is currently being talked about outside of the forums again.

Given the changing landscape on the internet and various regulations in different countries this could also extend into being a legal/liability issue for some admins if they have any kind of adult content on their server (homemade or otherwise). As it stands right now they could be seen as hosting adult content without age verification since images don't require any authentication whatsoever. Just some food for thought. 

I do have a couple of thoughts on how to "fix" the problem without breaking compatiblity with older apps that can't be updated (or those that want a reverse proxy to cache images or other assets) Add a toggle for each library type that enables "Protected Mode" (or whatever you want to call it)  This would disable unauthenticated access to the images endpoints when enabled. Modern clients can be updated to support "Protected mode" libraries, while anyone stuck on a legacy client can opt to leave it disabled for compatibility. Having the toggle on a per-library basis for all library types would allow admins to selectively enable it where they see fit. This also provides compatibility for those that have opted to use a different library type than what the content actually is.

There's already been a lot of negativity around this particular issue for quite some time now, the sooner this gets fixed, the better.