CVE-2024-49363: Misskey Media Proxy DoS Vulnerability

CVE-2024-49363 Overview

CVE-2024-49363 affects Misskey, an open source federated social media platform. The FileServerService media proxy in versions 2024.10.1 and earlier fails to detect proxy loops. Remote attackers can trigger a self-propagating reflected and amplified distributed denial-of-service (DDoS) condition by publishing a maliciously crafted note. The FileServerService.prototype.proxyHandler function does not verify that incoming requests originate outside the proxy itself. An attacker chains nested proxy requests that end with a malicious redirect back into another nested proxy request, producing unbounded recursion until request timeout. The flaw is categorized under [CWE-405] Asymmetric Resource Consumption (Amplification).

Critical Impact
A single malicious note can cause federated Misskey instances to amplify recursive proxy traffic against themselves and peers, exhausting server resources until requests time out.

Affected Products

Misskey 2024.10.1 and earlier
FileServerService media proxy component
FileServerService.prototype.proxyHandler request handler

Discovery Timeline

2024-12-18 - CVE-2024-49363 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-49363

Vulnerability Analysis

Misskey's media proxy fetches and re-serves remote files referenced in federated content. Activity from peer servers routinely traverses the proxy. The FileServerService does not detect that an incoming request was itself issued by a Misskey media proxy. An attacker crafts a note that references a proxied URL pointing back through the same or another Misskey instance's media proxy. Each recursive hop spawns a new outbound request without termination conditions. The result is uncontrolled recursion and asymmetric resource consumption against the affected server and any federated peers caught in the loop.

Root Cause

The root cause is missing loop detection in FileServerService.prototype.proxyHandler. The handler does not inspect the originating User-Agent or other identifying headers to determine whether the request comes from another Misskey proxy. Without this check, the proxy services its own recursive callbacks indefinitely.

Attack Vector

Exploitation requires only network access and user interaction with a federated note. An attacker posts a note containing a crafted media URL. When the URL is fetched, the response redirects to another nested proxy URL on the same server, creating a recursive chain. The attack amplifies through federation, as multiple instances proxying the same note multiply the resource impact. The vulnerability mechanism is described in the GitHub Security Advisory GHSA-gq5q-c77c-v236.

Detection Methods for CVE-2024-49363

Indicators of Compromise

Sustained spikes in outbound HTTP requests from the Misskey media proxy to the instance's own hostname or peer instance proxy paths.
High volume of in-flight requests with User-Agent containing Misskey/ terminating in timeouts.
Elevated process CPU and socket counts on the Node.js Misskey backend without corresponding legitimate user activity.

Detection Strategies

Inspect reverse proxy access logs for recursive request patterns where the proxy endpoint calls itself or peer proxy endpoints repeatedly within short windows.
Monitor for federated notes referencing media URLs that resolve back to Misskey /proxy/ paths.
Correlate request timeout rates against the FileServerService endpoint to identify abnormal recursion depth.

Monitoring Recommendations

Enable verbose logging on the reverse proxy fronting Misskey and alert on bursts of requests with empty or Misskey/-prefixed User-Agent values.
Track connection counts, file descriptor usage, and event loop lag on Misskey worker processes.
Forward web server and application telemetry into a centralized analytics or SIEM platform to correlate proxy abuse patterns across federated peers.

How to Mitigate CVE-2024-49363

Immediate Actions Required

Upgrade Misskey to version 2024.11.0-alpha.3 or later, which addresses the proxy loop condition.
If upgrading immediately is not feasible, deploy reverse proxy rules that block requests to the media proxy carrying an empty User-Agent or a User-Agent containing Misskey/.
Audit recent federated notes and media URLs for crafted proxy chains and purge offending content.

Patch Information

The maintainers fixed the issue in Misskey 2024.11.0-alpha.3. Operators should upgrade to that release or any later stable version. Patch details are published in the GitHub Security Advisory GHSA-gq5q-c77c-v236. An attacker cannot effectively modify the User-Agent header without making an additional direct request to the server, so the reverse-proxy workaround is effective until patching is complete.

Workarounds

Configure the reverse proxy in front of Misskey to reject requests to /proxy/ paths when the User-Agent header is empty.
Block requests where the User-Agent header contains the substring Misskey/ from reaching the media proxy endpoint.
Apply per-source rate limits and request timeouts at the reverse proxy to constrain recursion depth and connection counts.

bash

# Example NGINX configuration to block looped proxy requests
location /proxy/ {
    if ($http_user_agent = "") {
        return 403;
    }
    if ($http_user_agent ~* "Misskey/") {
        return 403;
    }
    proxy_pass http://misskey_backend;
}