Bazarr EUVD-2026-114256

No special conditions for the core takeover - remote unauthenticated exploitation against default configurations of Bazarr prior to 1.5.7-beta.14, because the api_ns_plex handlers ship without the @authenticate decorator and are reachable by any caller that can send HTTP requests to the /api/plex/... routes. The /oauth/logout and /apikey sinks need no PIN, Plex account or OAuth state. What LIMITS impact: the attacker must have network reachability to the Bazarr API (internet exposure or same-network access); SSRF credential exposure via X-Plex-Token is only meaningful when a Plex integration/token is already configured on the instance; and binding an attacker's Plex account requires driving the /oauth/pin then /oauth/pin/<id>/check flow with an attacker-controlled Plex account. Availability impact is confined to the Plex integration, not the whole application.

The signals are unusually consistent in pointing to high real-world risk. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, base 10.0) describes a network-reachable flaw requiring no privileges, no user interaction and low complexity, and the GHSA advisory corroborates the mechanism directly from source code: the entire api_ns_plex namespace in bazarr/api/plex/oauth.py omits the @authenticate decorator that its 65 sibling handlers carry, and no global auth hook compensates. The vuln.today Decision label is act_now, which aligns with the trivially-exploitable, unauthenticated nature. Two signals are absent rather than conflicting: no EPSS probability and no CISA KEV status are provided in the input, so widespread or confirmed active exploitation cannot be asserted - this is not currently a known-exploited vulnerability. No PoC or exploit reference is supplied either; the references are the vendor advisory and the fix commits, not working exploit code, so this should be treated as 'no public exploit identified at time of analysis' despite how mechanically simple exploitation is. The one metric worth scrutiny is A:H: the described availability impact is persistent denial of the Plex integration specifically (clearing credentials, setting use_plex=False), not of the whole application, so the raw 10.0 slightly overstates availability damage even though confidentiality (apikey/token exposure via SSRF) and integrity (persistent config tampering, binding an attacker's Plex token) are genuinely high. Net: this is a real, high-priority issue on the merits - not a high-CVSS-but-low-real-risk case - though its blast radius is scoped to internet- or network-exposed Bazarr instances.

An attacker who can reach a Bazarr instance's API over the network sends POST /api/plex/apikey and POST /api/plex/oauth/servers with no API key, persisting an attacker-chosen apikey and an attacker-controlled server URL into the saved configuration. When Bazarr subsequently issues outbound requests.get(server_url, ...) calls, it forwards the configured credential in the X-Plex-Token header to the attacker's endpoint, yielding SSRF and credential exposure; alternatively POST /api/plex/oauth/logout alone wipes the integration for a persistent denial of service. No public exploit code is identified at time of analysis, but the GHSA advisory documents each sink by file and line and exploitation requires only unauthenticated HTTP requests.