CVE-2026-52132: llama.cpp Reranking DOS Vulnerability

CVE-2026-52132 Overview

CVE-2026-52132 is a denial-of-service vulnerability in llama.cpp through commit 97f06e9. When the server is started with the --reranking flag, remote attackers can crash the process by submitting a POST request to the /rerank endpoint with a negative top_n value. The condition triggers a std::bad_alloc exception and returns an HTTP 500 response, terminating request handling.

The issue is tracked under CWE-674 (Uncontrolled Recursion) and requires no authentication or user interaction. Exposed llama.cpp reranking servers on untrusted networks are directly reachable by unauthenticated attackers.

Critical Impact
Unauthenticated remote attackers can crash llama.cpp reranking services with a single malformed HTTP request, disrupting availability of inference endpoints.

Affected Products

llama.cpp through commit 97f06e9
llama.cpp server binary started with the --reranking flag
Deployments exposing the /rerank HTTP endpoint

Discovery Timeline

2026-09-01 - CVE-2026-52132 published to NVD
2026-09-02 - Last updated in NVD database

Technical Details for CVE-2026-52132

Vulnerability Analysis

The vulnerability resides in the /rerank HTTP handler exposed by the llama.cpp server when launched with --reranking. The handler accepts a JSON body containing a top_n parameter that controls how many reranked results the server returns. The server does not validate that top_n is a non-negative integer before using it in memory allocation logic.

When a negative value is supplied, the value is interpreted as a very large unsigned quantity during allocation. The C++ standard library then attempts to allocate an unreasonably large buffer and throws std::bad_alloc. The unhandled allocation failure propagates up through the request handler, producing an HTTP 500 response and disrupting service.

For deeper technical background, see the Ph4nt0m Blog CVE Analysis and the upstream GitHub Llama.cpp Project.

Root Cause

The root cause is missing input validation on the top_n field in the /rerank endpoint. Signed-to-unsigned conversion during size computation transforms negative values into large allocation sizes, which the allocator cannot satisfy. The handler does not enforce a minimum value or catch the resulting allocation exception cleanly.

Attack Vector

Exploitation requires only network reachability to the llama.cpp server. An attacker sends a POST request to /rerank with a JSON payload containing "top_n": -1 (or any negative integer). No credentials, tokens, or session state are required. Repeated requests can be used to sustain service disruption against a running reranking endpoint.

A conceptual request body resembles: { "query": "...", "documents": [...], "top_n": -1 }. Refer to the linked advisory for the exact reproduction details.

Detection Methods for CVE-2026-52132

Indicators of Compromise

HTTP 500 responses returned by the llama.cpp /rerank endpoint correlated with client-supplied JSON bodies.
Server logs showing std::bad_alloc exceptions or abrupt worker termination during rerank request processing.
POST requests to /rerank containing a negative integer in the top_n field.

Detection Strategies

Inspect HTTP request bodies destined for /rerank and alert on non-positive top_n values at the reverse proxy or web application firewall layer.
Monitor llama.cpp server process restarts and memory allocation errors captured in stderr or systemd journals.
Baseline request rates to /rerank and alert on error-rate spikes that indicate abuse.

Monitoring Recommendations

Forward llama.cpp server logs to a centralized logging pipeline and index on HTTP status code and exception strings.
Track availability of the reranking service with synthetic health checks and alert on repeated HTTP 500 responses.
Correlate source IP addresses issuing malformed /rerank payloads to identify scanning or targeted denial-of-service activity.

How to Mitigate CVE-2026-52132

Immediate Actions Required

Update llama.cpp to a commit newer than 97f06e9 that includes input validation on the top_n parameter. Review the GitHub Llama.cpp Project commit history for the applicable fix.
Restrict network exposure of servers started with --reranking to trusted clients only.
Place llama.cpp behind an authenticating reverse proxy that validates request payloads before forwarding.

Patch Information

No formal vendor advisory or fixed-version identifier is listed in the NVD entry at publication. Monitor the upstream GitHub Llama.cpp Project repository for commits that add validation on top_n in the /rerank handler, and rebuild deployments from a commit that includes the fix.

Workarounds

Deploy a reverse proxy or WAF rule that rejects POST requests to /rerank where top_n is missing, non-numeric, or less than 1.
Disable the --reranking flag on production servers that do not require the rerank endpoint.
Enforce network-level access controls so only trusted internal services can reach the llama.cpp HTTP interface.
Run the llama.cpp server under a supervisor that automatically restarts the process to reduce sustained outage from crash conditions.

bash

# Example NGINX snippet to block negative top_n values before they reach llama.cpp
location /rerank {
    if ($request_method = POST) {
        # Reject bodies containing a negative top_n integer
        if ($request_body ~* "\"top_n\"\s*:\s*-") {
            return 400;
        }
    }
    proxy_pass http://llama_cpp_upstream;
}