An unauthenticated remote attacker can exploit this behavior in three ways: by using timing side-channels to determine the existence of local files, by forcing the re-encoding of local image files to disclose their contents, and by generating massive, unbounded filesystem I/O and memory usage. This resource-intensive exploitation can exhaust system memory and disk throughput, leading to a denial-of-service condition. Research indicates a single request can trigger over 4 GB of file reads. This flaw is patched in version 0.15.5.

Attack Chain

1. Attacker hosts a malicious SVG file on an external server containing a crafted <image href> tag targeting a local system path.
2. Attacker sends a GET/POST request to the target's /proxy endpoint, providing the URL of the malicious SVG file.
3. The January service fetches the SVG file and parses the contents.
4. The service encounters the <image href> tag and attempts to resolve the provided path on the local filesystem.
5. Attacker observes response times (timing side-channel) to confirm the existence of specific files on the server.
6. Service reads the targeted local files into memory, performing re-encoding operations.
7. Attacker requests the proxied output, receiving the disclosed local image content.
8. Concurrent requests lead to excessive I/O and memory pressure, triggering a service crash or system-wide denial-of-service.

Impact

Successful exploitation leads to the unauthorized disclosure of local image files and denial-of-service. The vulnerability allows an unauthenticated attacker to probe the filesystem structure and extract local image data. Furthermore, the lack of resource constraints allows a single attacker to cause significant system instability through memory exhaustion, potentially impacting all services hosted on the same infrastructure.

Recommendation

1. Upgrade the Stoatchat January media proxy service to version 0.15.5 or later immediately.
2. Implement strict egress filtering on the January service host to prevent it from reaching arbitrary external URLs for image proxying if not required by business logic.
3. Monitor webserver logs for excessive requests to the /proxy endpoint, especially those referencing internal or system-like directory paths, to identify exploitation attempts.
4. Deploy network-based rate limiting on the /proxy endpoint to mitigate potential denial-of-service attempts.