566
this post was submitted on 28 Nov 2025
566 points (98.3% liked)
Selfhosted
53386 readers
128 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
-
No low-effort posts. This is subjective and will largely be determined by the community member reports.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Please do explain or link sources to what you think are “security holes”.
It has several unsecured endpoints.
https://github.com/jellyfin/jellyfin/issues/5415
If you read the comments the devs know it's a serious issue but don't want to break backwards compatibility fixing them. Their solution for now is to warn people of the risks of exposing their instance to the Web. Which I don't think they're doing a great job of.
Aside from most of those being “potential issues”, which weren’t proven, the rest are GETs of things that do not need to be secret, things like album art and list of installed plugins. Besides the one plugin issue, which was an actual security issue, which was fixed over a year and a half ago. https://github.com/jellyfin/jellyfin/pull/11436
Contrast that with Plex which has numerous high severity CVEs that include things like remote code execution, directory traversal, and more.
And you think if Jellyfin were a comparable size, there wouldn't be just as many or more?
No… because more people would be working on it.
Yeah, as you said, that's a pretty serious security issue. That's a data leak that explicitly lays out the shape of your attack surface. It tells the attacker exactly what additional software your server is running and if any of it includes known vulnerabilities, the attacker now knows how to gain access.
That only works if the plugins are somehow accessible through an api controller, which as far as I’m aware, is not how jellyfin plugins work. So no, it wouldn’t increase your attack surface at all.
You’re aware those CVEs are only relevant for ancient versions of Plex and were fixed long ago?
Those are the the ones that somone has managed to find in closed source software...
They are not marked as resolved.
CVEs don’t get issued “resolved” statuses… They are either reserved, published, or rejected (technically NVD have a few extra for published). That’s just junk data in that tool you’re using. Use authoritative sources like cve.org or nvd.nist.gov.
You can see the CPEs on NVD and they’re old versions of Plex (and were old when the vulns were published).
Isn't that the point of major version upgrades? To make breaking changes?
Its also possible for a webserver to offer two versions of an API. Add a new one that needs authentication, mark the old one as deprecated and add a checkbox to disable it. Then clients can update to use the secure one and if you use and unmaintained client you can enable the old insecure api