CVE-2024-58400 in llama.cppinfo

Summary

by MITRE • 10/27/2026

llama.cpp before b3701 contains an out-of-bounds read vulnerability in llama_decode_internal and llama_encode_internal that allows remote unauthenticated attackers to read memory by supplying unvalidated token IDs. Attackers can send integer-array prompts to the llama-server /completion endpoint with IDs outside 0 to n_vocab to read embedding memory out of bounds or crash the process.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Analysis

by VulDB Data Team • 10/27/2026

The vulnerability identified in versions of llama.cpp prior to build b3701 represents a critical security flaw within the core inference engine, specifically affecting the internal functions responsible for processing input sequences during both encoding and decoding phases. This issue manifests as an out-of-bounds read condition that arises when the system fails to properly validate token identifiers before accessing underlying data structures. The llama-server component, which provides a RESTful interface for interacting with large language models, is particularly susceptible because it accepts raw integer-array prompts directly from clients without sufficient boundary checks against the model's vocabulary size. When an unauthenticated remote attacker submits a prompt containing token IDs that fall outside the valid range of zero to n_vocab, the internal logic attempts to access memory locations associated with embedding vectors using these invalid indices. Because the code does not enforce strict bounds checking on these array accesses, it results in reading from memory regions that are not allocated for this specific operation or lie beyond the intended buffer limits.

From a technical perspective, this flaw is classified under CWE-125, which denotes an out-of-bounds read vulnerability. The root cause lies in the lack of input sanitization within llama_decode_internal and llama_encode_internal functions. These functions are designed to map token IDs to their corresponding embedding vectors stored in memory. When a malicious actor provides a token ID that exceeds the maximum vocabulary index or is negative, the pointer arithmetic used to locate the correct vector calculates an address outside the allocated heap or stack segment for embeddings. This allows the attacker to read arbitrary memory contents, which may include sensitive information such as other users' data, internal model weights, cryptographic keys, or system state details that were previously loaded into those memory addresses. In scenarios where the out-of-bounds access triggers a segmentation fault due to unmapped pages, the consequence shifts from information disclosure to denial of service, resulting in the crash of the llama-server process and disrupting availability for legitimate users.

The operational impact of this vulnerability is significant given the typical deployment context of llama.cpp-based servers. These services are often exposed over networks to allow various applications to leverage local or remote LLM capabilities without authentication mechanisms being strictly enforced by default configurations. An attacker can exploit this flaw remotely with no prior access, making it a high-risk issue for any public-facing instance. The ability to read arbitrary memory poses severe confidentiality risks, potentially leading to the leakage of proprietary model parameters or sensitive context data processed during previous requests if memory reuse patterns allow such exposure. Furthermore, the potential for causing application crashes impacts service reliability and availability, requiring manual intervention or automated restarts to restore functionality, thereby increasing operational overhead and downtime costs for administrators relying on these services for critical workflows.

To mitigate this vulnerability, organizations running llama.cpp must immediately upgrade to version b3701 or any later release where the developers have implemented proper input validation checks within the encoding and decoding routines. These updates ensure that all token IDs are verified against the model's vocabulary size before being used as array indices for embedding lookups. For environments where upgrading is not immediately feasible, administrators should implement network-level controls such as web application firewalls to filter out requests containing suspiciously large or negative integer arrays in prompt payloads. Additionally, deploying the service behind a reverse proxy that enforces strict input schema validation can provide an additional layer of defense by rejecting malformed inputs before they reach the vulnerable application logic. Regular security audits and static code analysis tools configured to detect buffer overflow patterns should also be employed to identify similar issues in custom integrations or forks of the library, ensuring robust protection against memory corruption attacks aligned with techniques described in MITRE ATT&CK under data exfiltration via local input capture or denial of service through application crashes.

Responsible

VulnCheck

Reservation

10/27/2026

Disclosure

10/27/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

low

Sources

Want to know what is going to be exploited?

We predict KEV entries!