CVE-2024-10714: GPT Academic DoS Vulnerability

CVE-2024-10714 Overview

CVE-2024-10714 is a denial-of-service vulnerability in binary-husky/gpt_academic version 3.83. An unauthenticated attacker can send a crafted multipart file upload request containing excessive characters appended to the multipart boundary. The server enters a costly parsing loop, emitting repeated multipart.multipart Consuming a byte '0x2d' in end state warnings and consuming CPU and I/O resources until the application becomes unresponsive.

The flaw is tracked as CWE-770: Allocation of Resources Without Limits or Throttling and is remotely exploitable over the network without authentication or user interaction.

Critical Impact
Remote unauthenticated attackers can render the gpt_academic web application inaccessible by sending a single malformed multipart upload request.

Affected Products

binary-husky/gpt_academic version 3.83
Deployments exposing the file upload endpoint to untrusted networks
Self-hosted instances that have not applied upstream fixes after the reported version

Discovery Timeline

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

Technical Details for CVE-2024-10714

Vulnerability Analysis

The vulnerability resides in the multipart form parser used by gpt_academic when handling file uploads. When a client submits a Content-Type: multipart/form-data request, the parser processes the boundary declared in the header and scans the request body for matching boundary markers. In version 3.83, the parser fails to enforce an upper bound on trailing characters that follow the boundary terminator.

An attacker who appends a large volume of characters, such as repeated 0x2d (-) bytes, to the end of the boundary forces the parser into an inefficient state loop. Each byte is consumed individually while the parser remains in its terminal state, producing continuous warning output and blocking the request thread. Concurrent requests are unable to progress, resulting in denial of service.

Because exploitation requires only a single crafted HTTP request, the attack cost is negligible while the impact on availability is total.

Root Cause

The root cause is missing validation on the length and content of trailing bytes after the multipart boundary terminator. The parser continues to consume input character by character in an end state instead of rejecting the malformed payload or capping processing time. This aligns with [CWE-770], where a resource-consuming operation lacks throttling or size limits.

Attack Vector

Exploitation is straightforward and remote. An attacker sends an HTTP POST request to a file upload endpoint with a Content-Type header containing a valid multipart boundary, followed by a request body where excessive trailing characters are appended after the closing boundary marker. The parser then loops on each character, emitting multipart.multipart Consuming a byte '0x2d' in end state warnings and monopolizing server resources. No credentials, tokens, or user interaction are required.

The vulnerability mechanism is described in the public Huntr Bug Bounty Listing. No verified exploit code is required to reproduce the condition; the payload is a malformed multipart body.

Detection Methods for CVE-2024-10714

Indicators of Compromise

Repeated log entries containing multipart.multipart Consuming a byte '0x2d' in end state from the gpt_academic process.
Sustained high CPU utilization on the application worker handling a single upload request.
HTTP POST requests to upload endpoints with unusually long Content-Type boundary values or oversized request bodies with trailing padding.
Application unresponsiveness or timeouts affecting all users following a single request.

Detection Strategies

Inspect web server and reverse proxy logs for multipart requests with boundary strings exceeding typical lengths (for example, greater than 200 bytes).
Alert on process-level CPU spikes correlated with a single active HTTP connection to the gpt_academic upload handler.
Deploy a web application firewall rule that flags multipart bodies where trailing bytes after the closing boundary exceed a defined threshold.

Monitoring Recommendations

Forward application stdout and stderr to a centralized logging pipeline and create detections for the Consuming a byte warning pattern.
Track request duration percentiles on upload endpoints and alert on outliers that indicate parser stalls.
Monitor for repeated source IP addresses generating long-running multipart uploads without completing the transfer.

How to Mitigate CVE-2024-10714

Immediate Actions Required

Restrict access to the gpt_academic web interface to trusted networks or VPN clients until a patched release is deployed.
Place the application behind a reverse proxy that enforces request size and header length limits.
Rate-limit requests to file upload endpoints per source IP address to reduce exploitation impact.
Monitor the upstream repository for a release addressing this issue and upgrade as soon as a fix is available.

Patch Information

At the time of publication, no vendor advisory URL is listed in the NVD entry for CVE-2024-10714. Administrators should track the upstream binary-husky/gpt_academic repository and the Huntr Bug Bounty Listing for remediation guidance. Version 3.83 is confirmed vulnerable; later releases should be evaluated for the fix before production deployment.

Workarounds

Configure the fronting reverse proxy (for example, Nginx or a WAF) to reject Content-Type headers where the multipart boundary exceeds a reasonable byte length.
Enforce a maximum request body size at the proxy layer to bound parser work per request.
Terminate long-running upload connections with an aggressive server-side timeout.

bash

# Example Nginx hardening for the gpt_academic upstream
http {
    client_max_body_size 20m;
    client_header_buffer_size 1k;
    large_client_header_buffers 4 8k;
    client_body_timeout 15s;
    client_header_timeout 10s;

    server {
        listen 443 ssl;
        server_name gpt-academic.example.com;

        location / {
            limit_req zone=uploads burst=5 nodelay;
            proxy_pass http://127.0.0.1:8080;
            proxy_read_timeout 30s;
        }
    }
}