CVE-2025-64178: Jellysweep SSRF Vulnerability

CVE-2025-64178 Overview

CVE-2025-64178 is a Server-Side Request Forgery (SSRF) vulnerability in Jellysweep, a cleanup tool for the Jellyfin media server. In versions 0.12.1 and below, the /api/images/cache endpoint accepts a user-supplied url parameter that is passed directly to the cache package, which downloads content from the supplied URL. Authenticated users can abuse this endpoint to force the Jellysweep server to issue HTTP requests to arbitrary destinations. The issue is tracked as [CWE-918] and is fixed in version 0.13.0.

Critical Impact

Authenticated users can coerce the Jellysweep server into downloading arbitrary content from attacker-chosen URLs, enabling reconnaissance of internal networks and resource abuse.

Affected Products

• Jellysweep versions 0.12.1 and below
• Jellysweep deployments exposing /api/images/cache
• Fixed in Jellysweep version 0.13.0

Discovery Timeline

• 2025-11-06 - CVE-2025-64178 published to NVD
• 2026-04-15 - Last updated in NVD database

Technical Details for CVE-2025-64178

Vulnerability Analysis

The vulnerability resides in the ImageCache handler within internal/api/handler/handler.go. The handler reads the url query parameter directly from the HTTP request and forwards it to the image cache's ServeImage function. The cache package then performs an outbound HTTP request to fetch the resource at that URL. No allowlist, hostname validation, or scheme restriction is applied before the fetch.

Because Jellysweep performs the network request from its own context, an attacker can target internal IP ranges, loopback addresses, cloud metadata services, or non-HTTP services reachable from the server. The endpoint requires authentication, which limits exposure to users who already hold valid credentials, but does not prevent abuse by low-privileged accounts.

Root Cause

The root cause is missing input validation on the url query parameter. The handler treated client-supplied URLs as trusted identifiers for poster images rather than as untrusted user input. Combined with PosterURL being exposed through the API response models, attackers could enumerate or supply arbitrary URLs to the cache fetch routine.

Attack Vector

An authenticated user issues a GET request to /api/images/cache?url=<attacker_url>. The Jellysweep server fetches the supplied URL and returns the response body to the caller. This pattern enables internal port scanning, exfiltration of internal HTTP responses, and abuse of the server's outbound network position.

// Patched ImageCache handler in internal/api/handler/handler.go
// ImageCache serves cached images or downloads them if not cached.
func (h *Handler) ImageCache(c *gin.Context) {
-	imageURL := c.Query("url")
-	if imageURL == "" {
-		c.JSON(http.StatusBadRequest, gin.H{"error": "url parameter is required"})
+	mediaID, err := parseUintParam(c.Query("id"))
+	if err != nil {
+		c.JSON(http.StatusBadRequest, gin.H{"error": "invalid or missing id parameter"})
 		return
 	}

 	// Serve the cached image
-	err := h.engine.GetImageCache().ServeImage(c.Request.Context(), imageURL, c.Writer, c.Request)
+	err = h.engine.GetImageCache().ServeImage(c.Request.Context(), mediaID, c.Writer, c.Request)
 	if err != nil {
 		// Error is already handled in ServeImage
 		return

Source: GitHub Commit 17466312510966418aea941e4944229856d55101

The patch replaces the attacker-controllable url parameter with a server-side id lookup. The corresponding PosterURL field is also removed from the API response model in internal/api/models/converter.go, preventing clients from influencing the URL fetched by the cache.

Detection Methods for CVE-2025-64178

Indicators of Compromise

• Requests to /api/images/cache with a url query parameter referencing internal IP ranges (RFC1918), 127.0.0.1, 169.254.169.254, or non-HTTP schemes.
• Outbound HTTP connections from the Jellysweep host to unexpected internal hosts or cloud metadata endpoints.
• Abnormally high request volume to /api/images/cache from a single authenticated session.

Detection Strategies

• Inspect reverse proxy and application logs for GET /api/images/cache?url= requests containing host components other than expected media-poster domains.
• Correlate authenticated user identifiers with outbound network connections originating from the Jellysweep process to flag SSRF probing.
• Alert on responses from /api/images/cache that return non-image content types or unusually large payloads.

Monitoring Recommendations

• Enable egress logging on the Jellysweep host and forward records to a central log platform for review.
• Track the installed Jellysweep version across deployments and alert on instances still running 0.12.1 or earlier.
• Monitor for repeated 4xx and 5xx responses from /api/images/cache, which can indicate enumeration of internal services.

How to Mitigate CVE-2025-64178

Immediate Actions Required

• Upgrade Jellysweep to version 0.13.0 or later, which replaces the URL parameter with a server-side media id lookup.
• Audit existing accounts and revoke credentials for users who do not require Jellysweep access.
• Review recent application and proxy logs for prior abuse of /api/images/cache.

Patch Information

The fix is delivered in Jellysweep 0.13.0. Reference the GitHub Security Advisory GHSA-xc93-q32j-cpcg and the upstream commit for full patch details.

Workarounds

• Restrict network egress from the Jellysweep host to the specific external poster sources required by the application.
• Place Jellysweep behind a reverse proxy that blocks requests to /api/images/cache containing url parameters pointing to internal or metadata addresses.
• Limit Jellysweep access to trusted authenticated users until the upgrade to 0.13.0 is complete.

# Example nginx rule to block SSRF-style url parameters until upgrade
location = /api/images/cache {
    if ($arg_url ~* "(127\.|10\.|192\.168\.|172\.(1[6-9]|2[0-9]|3[0-1])\.|169\.254\.|localhost|file://|gopher://)") {
        return 403;
    }
    proxy_pass http://jellysweep_upstream;
}