MoviePilot EUVD-2026-33364

Requires (1) network reachability to MoviePilot v2 prior to v2.13.2, (2) a valid authenticated session on MoviePilot sufficient to obtain a resource_token cookie (PR:L per CVSS), (3) a request to the /api/v1/system/img-proxy endpoint with a URL whose hostname matches an entry in the assembled allowed_domains set - either via a literal internal IP that is itself in the allowlist (e.g., a configured Jellyfin/Emby/Plex backend at 192.168.x.x) or via a hostname that resolves into a non-global address. Limiting factors: the image proxy will not fetch entirely arbitrary domains - the target must clear the existing domain-membership check, which in practice means it must coincide with allowlisted media-server endpoints, so unrestricted SSRF to any internet host is not the primary primitive. Authentication is required, narrowing exposure to instances with shared, leaked, or self-registered accounts; no user interaction is needed once a token is held.

The CVSS 3.1 vector AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N yields 7.7 (High) and is internally consistent with the description: network reach, low complexity, requires low-privileged authentication (the resource_token cookie any logged-in user can mint), no user interaction, scope change as the server reaches into a separate security authority (the internal network), and high confidentiality impact via data exfiltration. The flaw is not in CISA KEV and EPSS is not provided in the input, so real-world exploitation pressure is unquantified; with a vendor advisory from VulnCheck and a public commit diff plus regression tests, weaponization barriers are low even though no public exploit is identified at time of analysis. Practical risk is highest for MoviePilot instances deployed on shared LANs with other *arr/media stacks, where the SSRF maps cleanly onto valuable internal targets; risk is reduced by the PR:L requirement, which means an attacker must first obtain or coerce an authenticated session.

An attacker with any low-privilege MoviePilot account obtains a valid resource_token cookie, then issues a request to the image proxy with a URL whose hostname matches a permitted domain but resolves to (or literally is) an internal IP such as http://192.168.1.50:8096 (a Jellyfin instance), http://127.0.0.1:32400 (Plex), or http://169.254.169.254/ (cloud metadata). The server fetches the URL and returns the response body, enabling enumeration and data exfiltration from internal services that would otherwise be unreachable. The vendor's own regression tests demonstrate exactly these primitives, so a working PoC is essentially derivable from the commit diff.