morpheus65535 bazarr, CVE-2026-61826: a new CVE scored 10

The short version

morpheus65535 bazarr (CVE-2026-61826) is a new CVE record, published by GitHub on 30 October 2026, with a base score of 10 (CVSS 3.1). We picked it for our daily highlight on 31 October 2026.

It is not on CISA's list of exploited vulnerabilities when we read it, which means nothing public says yet that anyone is using it. A high score is the record's author describing the worst case. Read the conditions before you act on the number.

Free analysis report · 8 pagesmorpheus65535 bazarr, CVE-2026-61826: a new CVE scored 10The same note as a document you can keep or forward: what the sources say, who is affected, and what to do first.Download the analysis report →

Our reading

Bazarr's Plex endpoints do not check who is calling. The record says an anonymous caller can clear the Plex credentials, set a key of their choosing, or link their own Plex account to the instance.

Anyone running Bazarr below 1.5.7-beta.14 whose web interface can be reached by people you do not trust, such as through a port forward, a reverse proxy or a shared network.

Why it matters

Our reading is that this is a takeover of the Plex link, not a break-in to the host: the record describes changes to the Plex integration only. The score of 10 reflects no login, no user action and a network path. The record also lists CWE-352, a request-forgery weakness. The sources do not say what else the endpoints reach, so treat any exposed instance as open to change.

What the record says

The CVE record says:

Bazarr is a companion application to Sonarr and Radarr. Prior to 1.5.7-beta.14, the `api_ns_plex` namespace in `bazarr/api/plex/oauth.py` omits `@authenticate` on its Resource handlers, while normal APIs require an API key and no global authentication hook compensates. Anonymous callers can invoke `POST /api/plex/oauth/logout` to clear credentials and disable the integration, or `POST /api/plex/apikey` to persist an attacker-selected key, without a PIN, account or state precondition. `POST /api/plex/oauth/pin` and `GET /api/plex/oauth/pin/<pin_id>/check` additionally allow an attacker who completes a PIN with an attacker-controlled Plex account to bind that account's token to the instance. …

What the vendor's advisory says

We read two pages on github.com. In short:

• The record says the flaw is in the Plex namespace, where the handlers omit the authentication check that normal Bazarr APIs require.
• The record names four actions open to anonymous callers: logout, setting a key, starting a PIN, and checking a PIN. It also names select-server and servers calls, but the text is cut off.
• The record says the PIN check skips state validation when no state value is sent, and only logs a mismatch.
• The GitHub advisory page lists CWE-306, CWE-352 and CWE-918. The record lists CWE-352 and CWE-862.
• The fixed version named is 1.5.7-beta.14, which is a beta tag on the project's repository.

Are you affected?

The record lists these versions of morpheus65535 bazarr as affected:

• < 1.5.7-beta.14

If you run it, find the version number first. If you cannot say what you run, that is the first job, and your IT provider can answer it in minutes.

Exposure by situation

These priorities are our judgement from what the sources say about who can use the flaw and how. They are not vendor ratings.

Things people will get wrong

• "It needs a Bazarr login, so we are safe" The record says the Plex handlers omit the authentication check and that no global hook makes up for it. The CVSS vector says no privileges are needed.
• "We do not use Plex, so this does not apply" The record does not make the endpoints depend on Plex being set up. It says no account or state precondition is needed to call them.
• "Nothing is on CISA's list, so it can wait" The record is new, so a missing listing says little. The flaw needs no login or user action, and the sources do not say whether it is being exploited.

How we would triage it

This is our judgement.

The commands only read: they print a version or list what is installed. They come from general knowledge of this kind of product, not from the sources, so check them against the vendor's page before you run them. Words in capitals are for you to fill in.

Step 1: Find the versions you run

• List every Bazarr instance, including containers and ones run by other people.
• Compare each against 1.5.7-beta.14, the fixed version named in the record.

docker ps --format '{{.Names}} {{.Image}}' | grep -i bazarr
docker image ls | grep -i bazarr
systemctl status bazarr

Step 2: Reduce exposure

• Take Bazarr off any public address until it is updated. The flaw needs no login, so a login page in front of it from Bazarr itself does not help.
• Limit access to a VPN or to a proxy that makes users sign in first.

Step 3: Update

• Move to 1.5.7-beta.14 or later, as the record names this as the first fixed version.
• Check whether your update channel offers a stable build at that level, as the sources only name a beta tag.

Step 4: Check the Plex link

• Open the Plex settings and confirm the key, linked account and chosen server are the ones you set.
• If anything differs, remove the link and set it up again with your own account.

If it is in range and you cannot update today, write down who owns it, the new date, and what limits exposure until then.

Read the version from the product itself, not from an old inventory, and save the output with the date, so you can show later when it was done.

The weakness behind it

The record classes this as CWE-352 and CWE-862.

• CWE-862 →What this kind of mistake is, and which exploited vulnerabilities share it.

What we do not know yet

• Whether this is being exploited. The record is new and the sources say nothing on it.
• Whether a stable release carries the fix. The sources only name a beta tag.
• Whether the select-server and servers calls change anything more, because the record text is cut off.
• Whether an attacker linked to an instance can reach anything beyond the Plex integration.
• This is a new record. We read the vendor pages named above, and nothing here has been tested.
• Scores, versions and wording can change in the first days. They are as at 31 October 2026.
• Exploitation is not recorded. That is not the same as none.
• The sections headed "Our reading", "Why it matters", "Exposure by situation", "Things people will get wrong" and "How we would triage it" are our interpretation of the sources, not a statement by CISA or the vendor.

• The day's CVE highlight →The three new records we picked that day, and how we chose them.
• Today's mission →Every exploited vulnerability from the last seven days, in the order their deadlines fall.