CVE-2024-12864: Youdao Qanything DoS Vulnerability

CVE-2024-12864 Overview

CVE-2024-12864 is a Denial of Service (DoS) vulnerability affecting netease-youdao/qanything version v2.0.0. The flaw resides in the file upload feature, where the application improperly handles form-data requests containing oversized filenames. An unauthenticated attacker can send a crafted request with a large filename, causing the server to exhaust resources and become unavailable to legitimate users. The issue is classified as [CWE-400] Uncontrolled Resource Consumption. Because no authentication is required, the attack is highly scalable across exposed instances of the QAnything retrieval-augmented generation platform.

Critical Impact
Remote, unauthenticated attackers can render the QAnything service unavailable by submitting a single malformed file upload request.

Affected Products

Netease Youdao QAnything v2.0.0
CPE: cpe:2.3:a:youdao:qanything:2.0.0:*:*:*:*:*:*:*
Component: youdao:qanything

Discovery Timeline

2025-03-20 - CVE-2024-12864 published to NVD
2026-06-17 - Last updated in NVD database
Reported via the Huntr Bug Bounty Report

Technical Details for CVE-2024-12864

Vulnerability Analysis

QAnything exposes an HTTP file upload endpoint that accepts multipart/form-data requests. The endpoint parses the filename parameter from the request without enforcing a length limit or validating input size. When the server processes an excessively large filename value, memory and CPU consumption grow unbounded during parsing and storage operations. This behavior maps to [CWE-400] Uncontrolled Resource Consumption. The result is process starvation, degraded response times, and eventual service unavailability for concurrent legitimate users.

Root Cause

The root cause is missing input validation on the filename field of the file upload handler. The application does not enforce a maximum filename length before allocating buffers or performing string operations. Because filename metadata is processed before any authentication check, the request path is reachable by anonymous clients over the network.

Attack Vector

Exploitation requires only network access to the QAnything upload endpoint. An attacker crafts a multipart/form-data POST request in which the filename field of the Content-Disposition header contains a very large string. Delivering the request repeatedly amplifies the effect and can drive the server to full resource exhaustion. No user interaction, credentials, or privileged access are needed.

No verified public proof-of-concept code is available. Technical details are documented in the Huntr Bug Bounty Report.

Detection Methods for CVE-2024-12864

Indicators of Compromise

HTTP POST requests to QAnything file upload endpoints containing Content-Disposition headers with filename fields exceeding several kilobytes.
Sudden spikes in memory or CPU consumption on the QAnything application process correlated with upload traffic.
Repeated multipart/form-data requests from a single source IP targeting the upload API.

Detection Strategies

Inspect web server and reverse proxy logs for abnormally long filename values in multipart uploads.
Deploy a Web Application Firewall (WAF) rule that rejects Content-Disposition headers exceeding a defined byte threshold.
Correlate application crash or restart events with inbound upload traffic patterns.

Monitoring Recommendations

Track process memory and CPU utilization of the QAnything container or service and alert on sustained saturation.
Monitor HTTP 5xx error rates and request latency on the upload endpoint for early signs of resource exhaustion.
Enable rate-limit telemetry at the ingress layer to detect volumetric abuse of unauthenticated endpoints.

How to Mitigate CVE-2024-12864

Immediate Actions Required

Restrict network exposure of QAnything v2.0.0 upload endpoints to trusted networks or authenticated users via reverse proxy access controls.
Configure an upstream WAF or ingress controller to cap Content-Disposition filename length and reject oversized multipart headers.
Apply rate limiting to the file upload endpoint per source IP to reduce amplification potential.

Patch Information

No vendor patch or fixed version is referenced in the NVD entry at the time of publication. Consult the upstream netease-youdao/qanything repository and the Huntr Bug Bounty Report for remediation status. Until a fixed release is available, operators should treat exposed v2.0.0 deployments as vulnerable.

Workarounds

Place QAnything behind an authenticating reverse proxy so unauthenticated actors cannot reach the upload endpoint.
Enforce a maximum request header size and body size in NGINX or the equivalent gateway in front of QAnything.
Isolate the QAnything service in a resource-constrained container to limit blast radius during a resource-exhaustion event.

bash

# NGINX example: cap header and body size in front of QAnything
http {
    client_header_buffer_size 1k;
    large_client_header_buffers 4 8k;
    client_max_body_size 20m;

    limit_req_zone $binary_remote_addr zone=qanything_upload:10m rate=5r/s;

    server {
        listen 443 ssl;
        server_name qanything.example.com;

        location /api/upload {
            limit_req zone=qanything_upload burst=10 nodelay;
            proxy_pass http://qanything_backend;
        }
    }
}