CVE-2026-27707: Seerr Plex Auth Bypass via Jellyfin

CVE-2026-27707 is a high severity authentication flaw (CVSS 7.3) in Seerr, the media request manager. On a Plex configured instance, an unauthenticated user can register an account through the Jellyfin login route and get a session. Upgrade to Seerr 3.1.0.

What's affected

Seerr from 2.0.0 up to but not including 3.1.0. The advisory describes the affected setup as one where all three of these are true:

• The media server type is set to Plex, the most common setup.
• The Jellyfin address is empty, which is the default when Jellyfin was never configured.
• The setting for new Plex logins is on, which is also the default.

Jellyfin configured and Emby configured deployments are not affected, according to the advisory. The fix is in 3.1.0.

How to check if you're exposed

Check your Seerr version and its settings file.

docker image ls | grep seerr

In the settings, look at the three values named in the advisory: main media server type, the Jellyfin address and the new Plex login flag. If the first is Plex, the second is empty and the third is true, you match the vulnerable pattern. Also look at the user list for accounts you do not recognise.

What to do now

1. Upgrade to Seerr 3.1.0 or later.
2. Review the user list and remove accounts you did not approve.
3. Review requests sent to your Radarr and Sonarr connections for anything you do not recognise.
4. If you cannot upgrade at once, restrict access to the Seerr login page to trusted networks or put it behind your own authentication layer.
5. Do not expose request managers to the internet without a second layer of access control.

Why it matters

The record lists CWE-288, authentication bypass using an alternate path or channel, and CWE-807, reliance on untrusted inputs in a security decision. The advisory traces it to a guard condition on the Jellyfin login endpoint that does not stop the request when the server is configured for Plex. A client can then authenticate against a Jellyfin server of its own choosing and be treated as a valid new user.

The immediate harm is an unwanted account with default permissions, which includes sending media requests to Radarr and Sonarr. That is more of an access problem than a data breach, and the record scores its impact as low across confidentiality, integrity and availability.

The lesson is common in apps with several login providers. Every login route needs to check the same conditions, or the least strict route becomes the way in.

Quick check

Sources

• GitHub advisory GHSA-rc4w-7m3r-c2f7

Last reviewed: 19 October 2026.