Jellyfin 12.0 security fixes arrive alongside the removal of legacy client logins
Jellyfin shipped version 12.0 of its media server. Several of the security fixes in it block requests built to reach files outside the folders the server is supposed to hand out. The rest of the security work touches first-run setup, plugin installs, parental controls, and the web interface.
On a misconfigured server, someone who had not signed in could get the setup wizard, the first-run pages that create the administrator account and point Jellyfin at your libraries, to run a second time.
Plugin packages with unsafe names are now rejected. Parental controls apply in places where they previously did not, and the web client has fixes for cross-site scripting, the bug class where content an attacker supplies runs as script inside another user’s browser session.
The project does not name the individual issues, attach CVE identifiers, or rate severity, so an administrator deciding how fast to patch is working from the word “security” and the sentence around it.
Old clients and old logins stop working
Support for the legacy /emby/ and /mediabrowser/ addresses is gone, and the sign-in method Jellyfin had already marked deprecated is switched off by default, on existing servers as well as new installs. Clients that have not been updated in years are the ones that will stop connecting.
Jellyfin also deleted POST /Users/{userId}/EasyPassword, one of five routes removed in this release that had already been reduced to no-ops, and marked UserDto.HasPassword obsolete on the grounds that its answer is no longer useful.
Usernames are case insensitive in 12.0, and two accounts can no longer carry names that differ only by capitalization. A server holding such a pair will fail the database migration outright, so the user list is worth reading before the upgrade starts.
Built-in TLS is still there, for now
Jellyfin said in the 10.11.0 notes that it would remove the server’s own TLS support in this release. That removal has been pushed to a future version. The project continues to recommend running the server behind a reverse proxy.
Anyone running an internet-facing instance on Jellyfin’s built-in TLS keeps working through the upgrade, which is the practical effect of the postponement.
What to do before upgrading
Third-party plugins built for 10.11 will not load on 12.0. The server now targets .NET 10 and several plugin interfaces changed, so those plugins need updated builds from their authors; Jellyfin advises pulling them off the server before upgrading and adding them back as new builds appear. Official plugins have been updated already. Disabled plugins now also stay disabled across a restart, which was not the case on 10.11.
The upgrade path starts at 10.10.7 or any 10.11.x release, and anything older needs a stop at 10.10.7 first. A full library scan is required afterward, and the first one runs significantly longer than usual because Jellyfin now checks every item in the library against the files on disk. Administrators who want to run the migration as a deliberate step can start the server with --mode MigrateSystem, which performs the upgrade and exits without bringing the rest of Jellyfin up.
The database schema changes and data is rewritten on first boot, and the backup taken before that happens is the only way back to the previous version.
