Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-01T18:17:43.823Z",
  "pubdate": "2026-09-01T18:17:43.823Z",
  "executiveSummary": "A memory allocation vulnerability exists in llama.cpp up to commit 97f06e9 when the --reranking flag is active. The vulnerability stems from improper validation of the top_n parameter provided during POST requests to the /rerank endpoint.\nThe flaw allows an unauthenticated remote attacker to trigger a std::bad_alloc exception by submitting a negative integer value for the top_n parameter. This results in an unhandled memory allocation failure, leading to a service crash and a subsequent HTTP 500 error, effectively creating a Denial of Service (DoS) condition.\nThe vulnerability affects systems configured for reranking tasks. Risk is significant due to the ease of exploitation, as it requires no specialized authentication or high-level privileges. Attackers can remotely disrupt service availability by manipulating input parameters in standard HTTP requests, potentially impacting the stability of AI inference pipelines dependent on this service.",
  "technicalDetails": "The vulnerability is rooted in an integer handling flaw within the /rerank API endpoint of llama.cpp. When the application is launched with the --reranking flag, it initializes components to handle ranking tasks. The system fails to implement rigorous bounds checking on the 'top_n' parameter supplied by the user within the JSON payload of a POST request.\nUpon receiving a request, the server-side code parses the 'top_n' field. If an attacker provides a negative integer, the logic fails to sanitize the input before passing it to internal memory allocation routines. In C++, requesting an allocation size based on a negative value or a value that causes integer underflow/overflow during calculation can lead to a std::bad_alloc exception. Specifically, when the runtime attempts to allocate buffer space for result handling based on the manipulated top_n value, the underlying memory allocator fails to fulfill the request.\nThe attack flow is straightforward: 1) The attacker identifies a target instance of llama.cpp running with the --reranking feature enabled. 2) The attacker crafts an HTTP POST request targeting the /rerank URI. 3) The JSON payload is constructed with the 'top_n' field set to a negative integer (e.g., -1). 4) The server processes the input, attempts to allocate memory, triggers the std::bad_alloc exception, and the process terminates or enters an error state that returns an HTTP 500 status code. Because the exception is not appropriately caught or handled by the request-processing thread, the application crashes, leading to a complete disruption of service.\nThis vulnerability is present in versions up to commit 97f06e9. The lack of input validation on the API boundary exposes the server's heap management to user-controlled values. As the service is network-exposed, any entity capable of reaching the /rerank endpoint can execute this attack without requiring prior authentication or specific credentials. Successful exploitation results in an immediate service outage, necessitating a manual restart of the affected llama.cpp process to restore functionality."
}