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.