Summary
Bazarr's Plex API exposes configuration-changing resource handlers without the authentication required by other APIs. Anonymous callers may alter Plex credentials and server settings, disable the integration, expose configured API keys through attacker-controlled outbound requests, or associate an attacker-controlled Plex account with the instance.
Bazarr's Plex API exposes configuration-changing resource handlers without the authentication required by other APIs. Anonymous callers may alter Plex credentials and server settings, disable the integration, expose configured API keys through attacker-controlled outbound requests, or associate an attacker-controlled Plex account with the instance.
Affected context
The issue affects Bazarr deployments using the Plex API namespace before authentication is enforced on its resource handlers. Risk is present when the API is reachable by an unauthenticated client and the affected endpoints can perform configuration writes or initiate Plex-related requests. OAuth flows may also remain exposed to state-validation weaknesses when state data is absent or mismatched.
The issue affects Bazarr deployments using the Plex API namespace before authentication is enforced on its resource handlers. Risk is present when the API is reachable by an unauthenticated client and the affected endpoints can perform configuration writes or initiate Plex-related requests. OAuth flows may also remain exposed to state-validation weaknesses when state data is absent or mismatched.
Exploit preconditions
- Attack surface: Bazarr's Plex API endpoints, including OAuth, API-key, server-selection, webhook, and encryption-related handlers
- Required access: Network access to the Bazarr API; an authenticated Bazarr account or PIN is not required for the anonymous mutation paths
- Trigger point: Requests to resource handlers that update configuration, clear credentials, set API keys, or process Plex OAuth state
- Why exploitation is possible: Authentication decorators are omitted, allowing callers to reach write operations and, in some OAuth paths, proceed without complete state validation
- Attack surface: Bazarr's Plex API endpoints, including OAuth, API-key, server-selection, webhook, and encryption-related handlers
- Required access: Network access to the Bazarr API; an authenticated Bazarr account or PIN is not required for the anonymous mutation paths
- Trigger point: Requests to resource handlers that update configuration, clear credentials, set API keys, or process Plex OAuth state
- Why exploitation is possible: Authentication decorators are omitted, allowing callers to reach write operations and, in some OAuth paths, proceed without complete state validation
Why this happens
The primary defect is missing authorization enforcement on state-changing API resources, mapping to CWE-862: Missing Authorization. The handlers perform sensitive operations without first establishing that the caller is permitted to invoke them, allowing anonymous requests to modify persistent integration settings.
The OAuth flow also contains incomplete state validation, which is related to CWE-352: Cross-Site Request Forgery when a request can be accepted without verifying an expected state value. Together, these insecure patterns weaken the trust boundary around configuration and account-linking operations.
The primary defect is missing authorization enforcement on state-changing API resources, mapping to CWE-862: Missing Authorization. The handlers perform sensitive operations without first establishing that the caller is permitted to invoke them, allowing anonymous requests to modify persistent integration settings.
The OAuth flow also contains incomplete state validation, which is related to CWE-352: Cross-Site Request Forgery when a request can be accepted without verifying an expected state value. Together, these insecure patterns weaken the trust boundary around configuration and account-linking operations.
Potential impact
- An attacker may clear Plex credentials and disable the integration.
- An attacker may persist a selected API key or alter Plex server configuration.
- An attacker could associate an attacker-controlled Plex account with the Bazarr instance.
- Attacker-controlled server URLs may cause outbound requests carrying the configured Plex API key.
- Sensitive credentials may be exposed to an attacker-controlled server.
- The Bazarr instance may experience persistent configuration tampering or integration denial of service.
- An attacker may clear Plex credentials and disable the integration.
- An attacker may persist a selected API key or alter Plex server configuration.
- An attacker could associate an attacker-controlled Plex account with the Bazarr instance.
- Attacker-controlled server URLs may cause outbound requests carrying the configured Plex API key.
- Sensitive credentials may be exposed to an attacker-controlled server.
- The Bazarr instance may experience persistent configuration tampering or integration denial of service.
General mitigation guidance
Mitigation generally focuses on enforcing authorization consistently for every state-changing API operation and treating OAuth state as a mandatory security control.
Common defensive patterns include:
- Require authentication and authorization on all Plex API resource handlers that mutate state.
- Apply centralized, fail-closed authorization middleware rather than relying only on per-handler annotations.
- Require and strictly validate OAuth state values before accepting PIN completion or account-linking actions.
- Validate server destinations against an explicit trust policy before making outbound requests.
- Avoid sending API keys to untrusted or user-controlled destinations.
- Limit the permissions of service credentials and protect configuration storage from unauthorized writes.
- Use CSRF defenses appropriate to the authentication model for browser-driven state-changing requests.
Mitigation generally focuses on enforcing authorization consistently for every state-changing API operation and treating OAuth state as a mandatory security control.
Common defensive patterns include:
- Require authentication and authorization on all Plex API resource handlers that mutate state.
- Apply centralized, fail-closed authorization middleware rather than relying only on per-handler annotations.
- Require and strictly validate OAuth state values before accepting PIN completion or account-linking actions.
- Validate server destinations against an explicit trust policy before making outbound requests.
- Avoid sending API keys to untrusted or user-controlled destinations.
- Limit the permissions of service credentials and protect configuration storage from unauthorized writes.
- Use CSRF defenses appropriate to the authentication model for browser-driven state-changing requests.
How teams detect issues like this
Detection can include static analysis and review rules that identify state-changing handlers lacking authentication or authorization decorators, especially those invoking configuration-write functions such as write_config().
Code review should examine whether OAuth callbacks require a present, unpredictable, and matching state value, whether failure paths terminate processing, and whether user-controlled URLs influence outbound requests containing credentials. Runtime monitoring can alert on anonymous POST requests to Plex mutation endpoints, unexpected configuration changes, and outbound requests to unapproved server destinations. API gateways and policy enforcement can also require authentication for sensitive routes.
Detection can include static analysis and review rules that identify state-changing handlers lacking authentication or authorization decorators, especially those invoking configuration-write functions such as write_config().
Code review should examine whether OAuth callbacks require a present, unpredictable, and matching state value, whether failure paths terminate processing, and whether user-controlled URLs influence outbound requests containing credentials. Runtime monitoring can alert on anonymous POST requests to Plex mutation endpoints, unexpected configuration changes, and outbound requests to unapproved server destinations. API gateways and policy enforcement can also require authentication for sensitive routes.
