CVE-2026-52132 in llama.cpp
Summary
by MITRE • 09/01/2026
llama.cpp through commit 97f06e9, when started with the --reranking flag, allows remote attackers to cause a denial of service (std::bad_alloc and HTTP 500) via a negative top_n value in a POST request to /rerank.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/01/2026
The vulnerability identified in llama.cpp prior to commit 97f06e9 represents a critical input validation failure within the model serving component, specifically affecting the reranking functionality exposed through the HTTP API. When the application is launched with the --reranking flag enabled, it initializes specific data structures and memory allocation routines designed to process ranking requests for natural language processing tasks. The core technical flaw lies in the insufficient sanitization of integer parameters received via POST requests directed at the /rerank endpoint. Specifically, the software fails to validate whether the top_n parameter, which dictates the number of results to return or process internally, is a positive value greater than zero. This lack of boundary checking allows an attacker to supply negative integers as input values for this parameter.
From a technical perspective, the processing logic likely attempts to allocate memory buffers based on the magnitude of the provided top_n value without accounting for its sign. In many C++ implementations involving standard library containers or raw pointer arithmetic, passing a large negative number can be interpreted as an extremely large unsigned integer due to two's complement representation rules, or it may trigger immediate exceptions when passed to functions expecting non-negative sizes such as std::vector resize operations or new array allocations. This results in the system attempting to allocate an excessive amount of memory that far exceeds available physical and virtual resources. Consequently, the C++ runtime throws a std::bad_alloc exception because the heap cannot satisfy the allocation request. The HTTP server layer catches this unhandled exception but responds with a generic 500 Internal Server Error code rather than a more specific client error like 400 Bad Request, thereby masking the true nature of the failure from automated scanners while still disrupting service availability for legitimate users.
The operational impact of this vulnerability is primarily focused on denial of service against the inference or ranking server. An attacker can exploit this flaw by sending repeated POST requests with negative top_n values to the /rerank endpoint. Each successful request consumes system resources during the failed allocation attempt and potentially leaves memory in an inconsistent state if not properly cleaned up before exception handling completes. Over time, this resource exhaustion leads to service degradation or complete unavailability of the llama.cpp instance. This is particularly dangerous in production environments where the reranking model might be a critical component of a larger retrieval-augmented generation pipeline, as its failure can cascade into broader application instability. The vulnerability aligns with CWE-20 Improper Input Validation and CWE-400 Uncontrolled Resource Consumption, highlighting both the root cause and the resulting effect on system stability.
Mitigation strategies for this issue involve immediate patching to a version of llama.cpp that includes commit 97f06e9 or later, which implements proper input validation checks before processing the top_n parameter. Developers should ensure that all integer inputs from external APIs are validated against expected ranges, specifically enforcing positive values where applicable. Additionally, implementing robust exception handling within the HTTP request handler can prevent unhandled exceptions from crashing the server process and allow for more graceful error responses. For organizations unable to patch immediately, deploying a web application firewall with rules to block POST requests containing negative integers in parameters associated with array sizes or counts can provide temporary protection against exploitation of this specific flaw.