Vulnerabilities

llama.cpp builds through commit 97f06e9 fail to handle a negative top_n value in POST requests to the /rerank endpoint, producing an out-of-memory condition (std::bad_alloc, classified as uncontrolled recursion per CWE-674) that is surfaced as an HTTP 500 error. The flaw is triggered remotely and without authentication whenever a server process is started with the --reranking flag and accepts requests at /rerank. An attacker who can reach the endpoint can disrupt availability, either crashing the process or making rerank requests fail, with no confidentiality or integrity impact (CVSS 3.1: AV:N/AC:L/PR:N/UI:N, A:H). Only deployments running the llama.cpp HTTP server with reranking enabled are affected; instances run without the --reranking flag, or whose /rerank endpoint is not reachable by untrusted clients, are not exposed. No public proof of concept exists, it is not in CISA's KEV catalog, and EPSS estimates a 0.3% probability of exploitation within 30 days, so no in-the-wild exploitation is currently known.

Do: Upgrade to a llama.cpp build newer than commit 97f06e9 once a patched release is available, since the advisory does not name a fixed version. As interim mitigations, avoid starting the server with --reranking unless reranking is required, restrict /rerank to trusted clients or place authentication in front of it, and reject requests with a negative top_n at a reverse proxy. Monitor /rerank for HTTP 500 responses as a possible sign of probing.

llama.cpp builds b1886 through b7445 contain a double free vulnerability in the LLaMA-Android JNI wrapper where new_1batch() allocates memory using malloc() while free_1batch() deallocates it using the C++ delete operator, causing heap metadata corruption. Attackers can trigger this memory management mismatch to cause denial of service through process crashes or potentially achieve arbitrary code execution depending on allocator state.