Miggo Logo

CVE-2025-64178: Jellysweep uses uncontrolled data in image cache API endpoint

N/A

CVSS Score

Basic Information

EPSS Score
-
Published
11/4/2025
Updated
11/4/2025
KEV Status
No
Technology
TechnologyGo

Technical Details

CVSS Vector
-
Package NameEcosystemVulnerable VersionsFirst Patched Version
github.com/jon4hz/jellysweepgo< 0.13.00.13.0

Vulnerability Intelligence
Miggo AIMiggo AI

Miggo AIRoot Cause Analysis

The vulnerability is a Server-Side Request Forgery (SSRF) in the /api/images/cache endpoint of the Jellysweep application. The root cause was the direct use of a user-provided url parameter to fetch remote content without proper validation. The analysis of the patch commit 17466312510966418aea941e4944229856d55101 reveals the key functions involved in this vulnerability.

The primary vulnerable function is handler.Handler.ImageCache located in internal/api/handler/handler.go. This function acted as the HTTP handler for the /api/images/cache endpoint. It directly extracted the url from the query string and passed it to cache.ImageCache.ServeImage. This lack of validation on the user-controlled input is the core of the vulnerability.

The function cache.ImageCache.ServeImage in internal/cache/image_cache.go is also a key part of the vulnerable execution flow. It received the tainted URL and proceeded to fetch content from it, triggering the SSRF. The patch remediates this by changing the function to accept a mediaID instead of a raw URL. It then safely retrieves the poster URL from the database using this ID.

Finally, the function arr.GetCachedImageURL in internal/engine/arr/arr.go was identified as a contributing factor. This function was responsible for creating the vulnerable URL structure, which was then used in the application's frontend. The removal of this function in the patch further confirms its role in the vulnerability.

By tracing the flow of the untrusted url parameter from the HTTP handler to the image fetching logic, these three functions are identified as the key components that, when combined, created the SSRF vulnerability.

Vulnerable functions

handler.Handler.ImageCache
internal/api/handler/handler.go
This function was the main entry point for the vulnerability. It directly read the `url` parameter from the HTTP request and passed it to the `ServeImage` function without any validation, allowing an attacker to specify an arbitrary URL for the server to fetch.
cache.ImageCache.ServeImage
internal/cache/image_cache.go
This function was responsible for fetching and serving the image. It received the untrusted `imageURL` from the `ImageCache` handler and used it to download content, leading to the SSRF vulnerability. The patch changed this function to accept a `mediaID` and fetch the URL from the database, preventing the direct use of user-provided URLs.
arr.GetCachedImageURL
internal/engine/arr/arr.go
This function was removed as part of the fix. It was used to construct the vulnerable URL for the `/api/images/cache` endpoint, taking an arbitrary `imageURL` and encoding it as a query parameter. This utility function directly contributed to the creation of the SSRF vector.

WAF Protection Rules

WAF Rule

### Imp**t T** `/*pi/im***s/*****` w*i** is us** to *ownlo** m**i* post*rs *rom t** s*rv*r ****pt** *n `url` p*r*m*t*r, w*i** w*s *ir**tly p*ss** to t** ***** p**k*** *n* t**t *ownlo**** t** post*r *rom t*is URL. T*is URL p*r*m*t*r **n ** us** to m*k

Reasoning

T** vuln*r**ility is * S*rv*r-Si** R*qu*st *or**ry (SSR*) in t** `/*pi/im***s/*****` *n*point o* t** J*llysw**p *ppli**tion. T** root **us* w*s t** *ir**t us* o* * us*r-provi*** `url` p*r*m*t*r to **t** r*mot* *ont*nt wit*out prop*r v*li**tion. T** *