CVE-2026–10107: SSRF in MoviePilot v2 Image Proxy Endpoint

A newly disclosed vulnerability, tracked as CVE-2026–10107, affects MoviePilot v2, an open-source media automation and management project. The issue is a Server-Side Request Forgery vulnerability in the application's image proxy endpoint, which could allow authenticated attackers to make the server request arbitrary internal or external URLs under specific conditions. NVD published the CVE on May 29, 2026, and lists VulnCheck as the source.

The vulnerability is particularly interesting because it does not rely on classic unauthenticated remote code execution or direct database access. Instead, it abuses a trusted server-side feature — an image proxy — to reach network resources that should not normally be exposed to the attacker.

What Is CVE-2026–10107?

CVE-2026–10107 is a Server-Side Request Forgery, or SSRF, vulnerability affecting MoviePilot v2.

According to the NVD description, the vulnerability exists in the image proxy endpoint. An authenticated attacker can supply a resource_token cookie and a URL whose domain matches the assembled allowlist. The vulnerable validation logic checks whether the target domain belongs to an allowed set, but it does not properly block private, loopback, or link-local addresses.

This means that the application may be tricked into requesting internal network resources on behalf of the attacker.

In practical terms, the vulnerable server becomes a proxy. Instead of directly connecting to an internal service, the attacker asks MoviePilot to do it for them.

Technical Summary

CVE ID: CVE-2026–10107 Product: MoviePilot v2 Affected versions: MoviePilot up to and including v2.13.2 Vulnerability type: Server-Side Request Forgery CWE: CWE-918 — Server-Side Request Forgery CVSS 3.1 score: 7.7 High CVSS 3.1 vector: AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N CVSS 4.0 score: 7.0 High according to NVD / CNA data Fixed in: commit 0b7854a Research credit: YU SUN, according to VulnCheck

VulnCheck describes the issue as affecting MoviePilot versions up to v2.13.2, with the fix introduced in commit 0b7854a.

Why the Image Proxy Became Dangerous

Image proxy endpoints are common in modern applications. They are often used to fetch remote images, cache them, resize them, or serve them safely through the application's own backend.

The problem is that any feature that fetches a user-controlled URL can become dangerous if the target is not strictly validated.

In this case, the vulnerable logic relied heavily on domain-membership checking. The application attempted to decide whether a URL was safe by checking whether its domain matched an allowed list. However, this is not enough for SSRF protection.

A secure SSRF defense must also consider where the hostname resolves. A domain may appear allowed at the string level while still resolving to a private, loopback, reserved, or link-local address. Without that check, an attacker may be able to pivot from an external-facing application into internal services.

Internal Services at Risk

NVD specifically mentions that the vulnerability could allow enumeration of internal services such as Jellyfin, Emby, or Plex, and could enable exfiltration of data from internal network resources.

This is important because MoviePilot is often deployed in home-lab, NAS, media server, or self-hosted environments. In those setups, internal applications may not be exposed to the public internet, but they may still be reachable from the MoviePilot server.

That makes SSRF especially dangerous.

An attacker does not need direct access to the private network. If MoviePilot can reach the internal service, the attacker may be able to make MoviePilot perform the request.

Attack Requirements

CVE-2026–10107 requires authentication. The CVSS vector includes PR:L, meaning the attacker needs low privileges. It does not require user interaction, and the attack can be performed remotely over the network.

This lowers the risk compared to a fully unauthenticated SSRF, but it does not make the issue negligible.

Low-privileged access is often easier to obtain than administrator access. It may come from weak credentials, shared accounts, exposed test accounts, leaked tokens, or compromised users. Once inside, an attacker could abuse the image proxy to explore internal services that were never meant to be accessible.

The Patch

The fix is visible in MoviePilot commit 0b7854a, titled "fix: block private image proxy targets." The change updates the image fetching logic so that SecurityUtils.is_safe_url() is called with block_private=True.

The patch also introduces additional hostname and IP validation logic. The updated code imports ipaddress and socket, resolves hostnames, and rejects non-global addresses. This is a key improvement because it moves validation beyond simple string-based domain checks.

In other words, the patched logic does not only ask:

"Does this domain look allowed?"

It also asks:

"Does this hostname resolve to a public, globally routable address?"

That distinction is critical for SSRF defense.

Why Domain Allowlisting Alone Is Not Enough

Domain allowlists are useful, but they are not complete SSRF protection.

A domain-based check can fail in several ways. Hostnames can resolve to internal IP addresses. DNS records can change. Attackers may abuse DNS rebinding-like behaviors. URL parsing can be tricky. Some IP formats may bypass naive filters. Internal addresses may appear through IPv4, IPv6, localhost names, link-local ranges, or reserved ranges.

That is why SSRF defenses should validate the final resolved destination, not only the text of the URL.

A strong SSRF mitigation strategy usually includes:

Strict scheme validation, usually allowing only https and sometimes http.

Host allowlists only where absolutely necessary.

DNS resolution checks.

Blocking private, loopback, link-local, multicast, reserved, and metadata service addresses.

Re-validating after redirects.

Network-level egress filtering.

Timeouts and response-size limits.

Avoiding direct proxying of sensitive response bodies.

CVE-2026–10107 shows what happens when URL validation stops too early.

Security Impact

The main impact of this vulnerability is confidentiality.

The CVSS vector reports high confidentiality impact, no integrity impact, and no availability impact. This makes sense: the issue is mainly about reading or discovering internal resources, not necessarily modifying them or crashing the system.

Possible consequences include:

Internal service enumeration.

Access to internal media server metadata.

Exposure of private API responses.

Discovery of local dashboards or admin panels.

Leakage of internal network structure.

Retrieval of sensitive files or endpoints if internal services expose them without proper authentication.

The final impact depends heavily on the deployment environment. A tightly isolated container with no access to internal services may reduce the risk. A self-hosted server with access to multiple media services, dashboards, and local APIs may increase it significantly.

Remediation

MoviePilot users should update to a version containing commit 0b7854a or later. VulnCheck identifies MoviePilot up to v2.13.2 as affected and states that the issue was fixed in that commit.

Administrators should also review whether their MoviePilot instance can reach sensitive internal services. Even after patching, it is a good idea to apply network segmentation and restrict outbound access from application containers.

Recommended actions:

Update MoviePilot to a patched build.

Review all exposed MoviePilot accounts and remove unnecessary users.

Rotate credentials if an untrusted or compromised user had access.

Check logs for suspicious image proxy requests.

Restrict MoviePilot's network access to only the services it actually needs.

Avoid exposing internal dashboards without authentication.

Run MoviePilot in a segmented network or container environment.

Lessons for Developers

The key lesson from CVE-2026–10107 is simple: any backend feature that fetches a user-controlled URL must be treated as a potential SSRF sink.

Checking only the domain string is not enough. Developers must validate the resolved IP address and block private or non-routable destinations. They should also consider redirects, DNS changes, IPv6, alternative IP representations, and cloud metadata endpoints.

The MoviePilot patch is a good example of a more defensive approach: it introduces hostname resolution and rejects non-global addresses before allowing the proxy request to proceed.

Final Thoughts

CVE-2026–10107 is a strong reminder that SSRF vulnerabilities are not limited to enterprise cloud platforms. They also matter in self-hosted applications, media automation tools, NAS deployments, and home-lab environments.

When an application is allowed to fetch remote resources, it becomes part of the network boundary. If that boundary is not carefully enforced, attackers may use the application as a bridge into private infrastructure.

In this case, MoviePilot's image proxy endpoint turned a convenience feature into a network pivot primitive. The fix reinforces an important security principle: never trust a URL just because its domain looks acceptable. Always validate where it actually goes.

References

NVD — CVE-2026–10107 VulnCheck Advisory — MoviePilot v2 SSRF via /api/v1/system/img/{proxy} Endpoint GitHub Commit — fix: block private image proxy targets GitHub Release — MoviePilot v2.13.2