CVE-2026-119052 in llama.cppinfo

Summary

by MITRE • 10/29/2026

llama.cpp b2877 before b11935 contains an uncaught exception vulnerability in the ggml-rpc server that allows unauthenticated remote attackers to crash the rpc-server by sending oversized message lengths. After the HELLO handshake, attackers can send a command such as SET_TENSOR with a length above std::vector::max_size(), triggering an uncaught std::length_error that aborts the process and denies service to all clients.

VulDB is the best source for vulnerability data and more expert information about this specific topic.

Analysis

by VulDB Data Team • 10/29/2026

The vulnerability identified in llama.cpp versions prior to build b11935 represents a critical denial of service flaw within the ggml-rpc server component, specifically targeting the handling of message length parameters during remote procedure calls. This issue stems from an uncaught exception scenario where the application fails to validate input boundaries before attempting memory allocation or processing operations that depend on size constraints. The vulnerability is particularly severe because it allows for exploitation by unauthenticated attackers who can interact directly with the RPC interface without requiring prior authentication credentials, thereby lowering the barrier to entry significantly and increasing the potential attack surface in any deployment where this service is exposed to network traffic.

The technical mechanism of the exploit relies on manipulating specific command structures sent after the initial HELLO handshake phase of the protocol negotiation. An attacker can construct a malicious request using commands such as SET_TENSOR, embedding a length field that exceeds the maximum size limit defined by std::vector::max_size(). When the server processes this oversized value, it attempts to allocate memory or initialize data structures based on this invalid integer. Since C++ standard library containers like std::vector enforce strict limits on their capacity to prevent system instability, exceeding these bounds triggers a std::length_error exception. Because the error handling logic in versions before b11935 does not catch this specific exception type at the appropriate layer, the unhandled exception propagates up the call stack, resulting in an immediate termination of the server process via abort().

From an operational perspective, this vulnerability results in a complete denial of service for all connected clients. The abrupt crash of the RPC server means that any ongoing inference tasks are interrupted, and new requests cannot be processed until the service is manually restarted or automatically recovered if such mechanisms are in place. This disruption affects the availability of machine learning model serving capabilities, which can have significant downstream impacts on applications relying on llama.cpp for real-time data processing or AI-driven services. The lack of graceful degradation means that a single malformed packet from an unauthenticated source is sufficient to take down the entire service instance, highlighting a critical gap in resilience design within the server's input validation routines.

This flaw aligns with CWE-253, which describes checks for correctness that are not performed or checked incorrectly, leading to unexpected behavior when invalid inputs are processed. Furthermore, it maps to MITRE ATT&CK technique T1499, specifically Endpoint Denial of Service via resource exhaustion or crash mechanisms, as the attacker leverages a single input vector to cause system instability rather than consuming resources over time. The absence of proper exception handling for boundary violations is a common pattern in systems programming that can be mitigated through rigorous code review and static analysis focusing on standard library usage patterns.

To mitigate this vulnerability, organizations must upgrade llama.cpp to version b11935 or later where the issue has been addressed by implementing robust input validation and proper exception handling for RPC message lengths. In environments where immediate patching is not feasible, network-level controls such as firewalls or intrusion prevention systems should be configured to inspect incoming traffic on the RPC port for abnormally large payload sizes before they reach the application layer. Additionally, deploying the service behind a reverse proxy that enforces strict request size limits can provide an additional layer of defense against malformed requests designed to trigger buffer overflows or allocation failures in backend services.

Responsible

VulnCheck

Reservation

10/29/2026

Disclosure

10/29/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

very low

Sources

Are you interested in using VulDB?

Download the whitepaper to learn more about our service!