CVE-2026-43632: llama.cpp UAF race — HIGH

CISO Take

A use-after-free race condition in llama.cpp's llama-server lets six tokenization endpoints — including /tokenize, /detokenize, and /infill — read a vocabulary object on HTTP worker threads after the main thread has already freed it, producing a crash or, in the worst case, remote code execution. This lands in one of the most widely self-hosted LLM inference engines, so any team running llama-server as a local or edge inference backend for RAG pipelines, coding assistants, or internal chat tools is potentially exposed. The 8.1 CVSS score reflects real impact to confidentiality, integrity, and availability, but exploitation requires high attack complexity (precise race-window timing) and only manifests when the operator has enabled --sleep-idle-seconds; EPSS sits at a low 0.33% and CISA's SSVC rates it TRACK — the lowest action tier — with no public exploit, no Nuclei template, and no evidence of active exploitation. Teams running llama-server between build b7492 and b9060 with --sleep-idle-seconds enabled should disable that flag as an immediate workaround, monitor for unexpected llama-server crashes or restarts as a detection signal, and track the upstream repo for a patched release since none is currently published.

Sources: NVD EPSS CISA KEV ATLAS vulncheck.com github.com

What is the risk?

Overall risk is MODERATE despite the high 8.1 CVSS score. The vulnerability is genuinely severe in impact (crash-to-potential-RCE via classic memory corruption) and reachable pre-authentication over the network with no user interaction, but three factors cap real-world exploitability: attack complexity is HIGH because the attacker must win a narrow TOCTOU race window between vocab teardown and handler completion; the vulnerable behavior only triggers under a non-default configuration (--sleep-idle-seconds); and there is no public PoC, no Nuclei template, and CISA SSVC rates it TRACK. EPSS (0.33%, ~74th percentile) suggests it is not currently a mass-exploitation target. Exposure is elevated wherever llama-server is directly internet-facing rather than sitting behind an internal network boundary, which is common in self-hosted or edge AI deployments.

How does the attack unfold?

Recon & targeting

Attacker scans for internet-facing llama-server instances running a vulnerable build (b7492-b9060) with --sleep-idle-seconds enabled.

AML.T0006

Race condition trigger

Attacker sends requests to one of six tokenization endpoints timed against the server's idle-unload cycle to win the TOCTOU race on ctx_server.vocab.

AML.T0049

Memory corruption

The handler thread accesses freed vocab memory after the main thread destroys it, corrupting process state.

Impact

Result is a crash of the inference service (denial of service) or, if the freed memory is exploited further, code execution on the host.

AML.T0029

Recon & targeting

Attacker scans for internet-facing llama-server instances running a vulnerable build (b7492-b9060) with --sleep-idle-seconds enabled.

AML.T0006

Race condition trigger

Attacker sends requests to one of six tokenization endpoints timed against the server's idle-unload cycle to win the TOCTOU race on ctx_server.vocab.

AML.T0049

Memory corruption

The handler thread accesses freed vocab memory after the main thread destroys it, corrupting process state.

Impact

Result is a crash of the inference service (denial of service) or, if the freed memory is exploited further, code execution on the host.

AML.T0029

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
llama.cpp	—	—	No patch

Do you use llama.cpp? You're affected.

How severe is it?

CVSS 3.1

8.1 / 10

EPSS

0.3%

chance of exploitation in 30 days

Higher than 26% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Advanced

What is the attack surface?

AV Network

AC High

PR None

UI None

S Unchanged

C High

I High

A High

What should I do?

1 step

Immediate workaround: disable --sleep-idle-seconds on any llama-server deployment until a patch ships, since the vulnerable teardown path is only triggered by that idle-unload behavior. No patched version has been published yet (patched: N/A) — track the upstream llama.cpp repository and the third-party advisory on vulncheck.com for a fix and upgrade past b9060 once available. Where the flag can't be disabled, restrict network exposure of llama-server to trusted internal callers only (place it behind an authenticated reverse proxy rather than directly internet-facing). For detection, monitor for unexpected llama-server process crashes/restarts or core dumps correlated with idle-timeout events, and treat any crash cluster on the tokenization endpoints as a potential exploitation attempt.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact total

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

DoS Code Execution Inference API AML.T0029 - Denial of AI Service AML.T0040 - AI Model Inference API Access AML.T0049 - Exploit Public-Facing Application

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

NIST AI RMF

MEASURE 2.7 - AI system security and resilience are evaluated and documented

OWASP LLM Top 10

LLM10:2025 - Unbounded Consumption

Frequently Asked Questions

What is CVE-2026-43632?

A use-after-free race condition in llama.cpp's llama-server lets six tokenization endpoints — including /tokenize, /detokenize, and /infill — read a vocabulary object on HTTP worker threads after the main thread has already freed it, producing a crash or, in the worst case, remote code execution. This lands in one of the most widely self-hosted LLM inference engines, so any team running llama-server as a local or edge inference backend for RAG pipelines, coding assistants, or internal chat tools is potentially exposed. The 8.1 CVSS score reflects real impact to confidentiality, integrity, and availability, but exploitation requires high attack complexity (precise race-window timing) and only manifests when the operator has enabled --sleep-idle-seconds; EPSS sits at a low 0.33% and CISA's SSVC rates it TRACK — the lowest action tier — with no public exploit, no Nuclei template, and no evidence of active exploitation. Teams running llama-server between build b7492 and b9060 with --sleep-idle-seconds enabled should disable that flag as an immediate workaround, monitor for unexpected llama-server crashes or restarts as a detection signal, and track the upstream repo for a patched release since none is currently published.

Is CVE-2026-43632 actively exploited?

No confirmed active exploitation of CVE-2026-43632 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-43632?

Immediate workaround: disable --sleep-idle-seconds on any llama-server deployment until a patch ships, since the vulnerable teardown path is only triggered by that idle-unload behavior. No patched version has been published yet (patched: N/A) — track the upstream llama.cpp repository and the third-party advisory on vulncheck.com for a fix and upgrade past b9060 once available. Where the flag can't be disabled, restrict network exposure of llama-server to trusted internal callers only (place it behind an authenticated reverse proxy rather than directly internet-facing). For detection, monitor for unexpected llama-server process crashes/restarts or core dumps correlated with idle-timeout events, and treat any crash cluster on the tokenization endpoints as a potential exploitation attempt.

What systems are affected by CVE-2026-43632?

This vulnerability affects the following AI/ML architecture patterns: model serving, LLM inference endpoints, self-hosted/edge LLM deployments, RAG pipelines.

What is the CVSS score for CVE-2026-43632?

CVE-2026-43632 has a CVSS v3.1 base score of 8.1 (HIGH). The EPSS exploitation probability is 0.33%.

What is the AI security impact?

Affected AI Architectures

model servingLLM inference endpointsself-hosted/edge LLM deploymentsRAG pipelines

MITRE ATLAS Techniques

AML.T0029 Denial of AI Service

AML.T0040 AI Model Inference API Access

AML.T0049 Exploit Public-Facing Application

Compliance Controls Affected

EU AI Act: Article 15

NIST AI RMF: MEASURE 2.7

OWASP LLM Top 10: LLM10:2025

What are the technical details?

Original Advisory

llama.cpp builds b7492 through the latest b9060 contains a use-after-free vulnerability in llama-server affecting six tokenization endpoints (/tokenize, /detokenize, /infill, /apply-template, /rerank, and /anthropic/count_tokens) that bypass the task queue and access ctx_server.vocab directly on HTTP worker threads. Attackers can exploit a time-of-check-time-of-use race condition where the main thread destroys and frees vocab after the synchronization lock is released but before the handler finishes using it, causing a crash or potential code execution when --sleep-idle-seconds is configured.

Exploitation Scenario

An attacker identifies a llama-server instance exposed to the network (e.g., a self-hosted inference gateway) running with --sleep-idle-seconds enabled and a vulnerable build (b7492-b9060). They send a request to one of the six affected endpoints — say, /tokenize — timing it to coincide with the server's idle-unload cycle. If they win the race, the main thread frees ctx_server.vocab after the handler's lock is released but before the handler finishes reading it, causing the worker thread to operate on freed memory. With enough attempts to reliably win the race, this can be escalated from a crash (denial of service against the inference endpoint) toward exploitation of the freed memory for code execution on the host running llama-server.

Weaknesses (CWE)

CWE-367 Time-of-check Time-of-use (TOCTOU) Race Condition CWE-416 Use After Free

CWE-367 — Time-of-check Time-of-use (TOCTOU) Race Condition: The product checks the state of a resource before using that resource, but the resource's state can change between the check and the use in a way that invalidates the results of the check.

[Implementation] The most basic advice for TOCTOU vulnerabilities is to not perform a check before the use. This does not resolve the underlying issue of the execution of a function on a resource whose state and identity cannot be assured, but it does help to limit the false sense of security given by the check.
[Implementation] When the file being altered is owned by the current user and group, set the effective gid and uid to that of the current user and group when executing this statement.

Source: MITRE CWE corpus.