CVE-2024-58399 in llama.cppinfo

Summary

by MITRE • 10/27/2026

llama.cpp before b2731 contains an out-of-bounds read vulnerability in llama_model_loader that allows attackers to read memory outside the mapped model file via crafted GGUF tensor offsets. Attackers can supply a crafted or truncated GGUF model file with arbitrary 64-bit tensor offsets to crash the process or load adjacent process memory as model weights.

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Analysis

by VulDB Data Team • 10/27/2026

The vulnerability identified in versions of llama.cpp prior to build b2731 represents a critical out-of-bounds read flaw within the llama_model_loader component, specifically triggered by malformed GGUF format inputs. The Generalized GPU Unified Format (GGUF) is the standard file structure used for storing large language model weights and metadata, designed for efficient loading across various hardware accelerators including CPUs and GPUs. During the initialization phase of a model, the loader parses the header to determine tensor locations via offsets stored within the file. In vulnerable versions, this parsing logic fails to adequately validate that these 64-bit offset values fall strictly within the boundaries of the mapped memory region corresponding to the GGUF file itself. This lack of rigorous bounds checking allows an attacker who controls or influences the input model file to specify arbitrary tensor offsets that point beyond the allocated buffer space.

From a technical perspective, this flaw constitutes an out-of-bounds read vulnerability where the application attempts to access memory addresses that are not part of the intended data structure. When the loader processes these crafted offsets, it reads from adjacent memory regions rather than throwing an exception or halting execution safely. The operational impact is severe and multifaceted. First, if the offset points to unmapped virtual memory pages, the process will likely terminate abruptly with a segmentation fault, resulting in a denial of service against any system relying on this inference engine for availability. Second, and more critically, if the offset falls within mapped but unintended memory regions belonging to other processes or sensitive internal data structures, the vulnerability enables information disclosure. An attacker could potentially exfiltrate cryptographic keys, user credentials, session tokens, or proprietary model weights stored in adjacent memory spaces by interpreting these leaked bytes as part of the neural network parameters.

This type of vulnerability aligns with Common Weakness Enumeration (CWE) category CWE-125, which describes out-of-bounds read operations that allow attackers to access sensitive information beyond intended boundaries. Furthermore, from a tactical standpoint in cyber attack frameworks such as MITRE ATT&CK, this behavior maps directly to the technique T1083, File and Directory Discovery, or more specifically T1005, Data from Local System, where an adversary seeks to gather data for further exploitation without direct network interaction. The ability to read arbitrary memory via a model file effectively turns the inference engine into a primitive information leak channel, which can be chained with other vulnerabilities in hosting applications to achieve remote code execution or persistent access depending on the surrounding software architecture and privilege levels of the running process.

Mitigation strategies must prioritize immediate version updates as well as defensive coding practices for developers integrating this library. The primary remediation is upgrading llama.cpp to build b2731 or later, where the maintainers have implemented strict validation checks ensuring that all tensor offsets are verified against the actual file size and mapped memory limits before any read operations occur. For organizations unable to update immediately due to dependency constraints, implementing input sanitization at the application layer can provide a temporary buffer; this involves validating GGUF files for structural integrity and rejecting any entries with offset values exceeding expected bounds derived from standard model sizes. Additionally, deploying runtime protection mechanisms such as Address Space Layout Randomization (ASLR) and memory guard pages can mitigate the impact of successful exploitation by making adjacent sensitive data harder to predict or access reliably through out-of-bounds reads.

Responsible

VulnCheck

Reservation

10/27/2026

Disclosure

10/27/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

low

Sources

Do you want to use VulDB in your project?

Use the official API to access entries easily!