CVE-2024-10225: Hliu Llava DoS Vulnerability

CVE-2024-10225 Overview

CVE-2024-10225 is a denial of service vulnerability in haotian-liu/llava version 1.2.0. Attackers can trigger the flaw by appending a large number of characters to the end of a multipart boundary in a file upload request. The server processes each appended character sequentially, exhausting resources and rendering the application inaccessible. The vulnerability is remotely exploitable over the network without authentication or user interaction. It is categorized under [CWE-770] as an allocation of resources without limits or throttling.

Critical Impact
Unauthenticated remote attackers can render LLaVA v1.2.0 instances unavailable by sending a crafted multipart upload with an oversized boundary string.

Affected Products

haotian-liu/llava v1.2.0
LLaVA multimodal model server deployments running the affected release
Applications embedding the vulnerable file upload handler

Discovery Timeline

2025-03-20 - CVE-2024-10225 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-10225

Vulnerability Analysis

The vulnerability resides in the multipart form parser used by the LLaVA v1.2.0 file upload endpoint. When a client submits a multipart request, the boundary delimiter defined in the Content-Type header separates the parts of the payload. LLaVA does not enforce an upper bound on the length of that boundary string.

An attacker can craft a request where the multipart boundary is padded with a very large number of trailing characters. The server iterates through the boundary character by character during parsing, and the processing time grows with the length of the attacker-controlled input. Sustained requests of this shape consume CPU cycles and block worker threads.

The result is a resource exhaustion condition that makes the LLaVA service unresponsive to legitimate traffic. Because no authentication is required and the request looks like a normal upload, the attack has a low barrier to execution against exposed instances.

Root Cause

The root cause is missing input length validation on the multipart boundary parameter, an instance of [CWE-770] uncontrolled resource consumption. The parser accepts arbitrarily long boundary values and processes them without throttling or early rejection.

Attack Vector

The attack vector is network-based. An attacker sends an HTTP POST request with a Content-Type: multipart/form-data header whose boundary value is padded with an excessive number of characters. Repeated requests amplify the impact and can exhaust server capacity.

No verified exploit code is published. Technical details are documented in the Huntr Bug Bounty Report.

Detection Methods for CVE-2024-10225

Indicators of Compromise

HTTP requests with Content-Type: multipart/form-data headers containing boundary values that exceed typical lengths, often thousands of characters.
Repeated file upload requests from a single source with abnormally large or malformed Content-Type headers.
Sudden spikes in CPU utilization on LLaVA worker processes coinciding with upload traffic.

Detection Strategies

Inspect inbound HTTP traffic at a reverse proxy or web application firewall and flag multipart/form-data requests whose boundary parameter exceeds a defined length threshold.
Baseline normal request sizes and header lengths for the LLaVA endpoint, then alert on deviations.
Correlate high CPU usage on the LLaVA host with concurrent multipart uploads to identify active exploitation.

Monitoring Recommendations

Monitor request processing latency and worker thread saturation on the LLaVA service.
Log full Content-Type header values on upload endpoints for forensic review.
Track HTTP 5xx error rates and connection timeouts as availability indicators.

How to Mitigate CVE-2024-10225

Immediate Actions Required

Restrict network access to the LLaVA v1.2.0 upload endpoint to trusted clients until a fixed release is available.
Deploy a reverse proxy or WAF rule that rejects multipart/form-data requests with boundary parameters longer than a reasonable limit, such as 200 characters.
Enforce request timeouts and per-client rate limits on upload endpoints.

Patch Information

No vendor advisory or patched version is referenced in the NVD entry at the time of publication. Consult the Huntr Bug Bounty Report and the upstream haotian-liu/llava repository for the latest remediation status before upgrading.

Workarounds

Place the LLaVA service behind a reverse proxy that validates and truncates the Content-Type header before forwarding requests.
Limit maximum request body size and connection duration at the proxy layer to reduce the impact of resource exhaustion attempts.
Isolate the service in a dedicated container or process group with CPU and memory quotas so a DoS attempt does not affect adjacent workloads.

bash

# Example NGINX configuration to constrain multipart uploads
http {
    client_max_body_size 20m;
    client_body_timeout 10s;
    client_header_buffer_size 1k;
    large_client_header_buffers 4 8k;

    map $http_content_type $blocked_boundary {
        default 0;
        "~*boundary=[^;]{200,}" 1;
    }

    server {
        location /upload {
            if ($blocked_boundary) { return 400; }
            proxy_pass http://llava_backend;
        }
    }
}