{"id":23489,"date":"2026-08-25T16:25:22","date_gmt":"2026-08-25T16:25:22","guid":{"rendered":"https:\/\/scannn.com\/llms-could-control-their-host-machines-by-exploiting-inference-engines\/"},"modified":"2026-08-25T16:25:22","modified_gmt":"2026-08-25T16:25:22","slug":"llms-could-control-their-host-machines-by-exploiting-inference-engines","status":"publish","type":"post","link":"https:\/\/scannn.com\/lv\/llms-could-control-their-host-machines-by-exploiting-inference-engines\/","title":{"rendered":"LLMs could control their host machines by exploiting inference engines"},"content":{"rendered":"\n
\n

| Read on LessWrong<\/svg><\/a> | Comment on HN<\/svg><\/a> |<\/p>\n

Large language models often take actions running on one computer (via an
\nagentic harness such as Claude Code or Codex), however the LLMs\u2019 responses to
\nprompts are computed on a different computer with GPU access. Could a malicious
\nLLM gain control of the host machine where its weights are loaded? Such a
\nmachine is a high-value target: it has sufficient compute to run a frontier
\nLLM, offers easy access to the LLM\u2019s weights, and has privileged access to
\nother computers in the datacentre compared with a generic computer on the
\ninternet.<\/p>\n

This essay explores how easily a malicious LLM could take control of the host
\nmachine. The primary attack considered here involves the LLM emitting a token
\nsequence whose semantic meaning is irrelevant but that exploits a vulnerability
\nin the software that loads an LLM onto GPUs, runs the LLM to generate output
\ntokens, and parses those tokens into responses. .<\/p>\n

How could an LLM execute code on the host machine?<\/svg><\/a><\/h2>\n

Like any program, inference engines like vLLM<\/svg><\/a> or SGLang<\/svg><\/a> may contain
\nexploitable bugs. Because the LLM controls the tokens passed to the inference
\nengine, a malicious LLM could therefore emit a sequence of tokens that a poorly
\nwritten inference engine mistakes for code or instructions to execute rather
\nthan data to return to the user.<\/p>\n

But surely all inference engines are robust pieces of software and this would
\nnever happen, right?<\/p>\n

CVE-2025-9141<\/svg><\/a> was an arbitrary-code execution bug in vLLM\u2019s XML-based tool
\nparser for Qwen3 Coder. The parser passed almost every tool-call argument to
\neval()<\/code>, allowing the LLM to execute arbitrary code on the host machine.
\nGemini automatically analysed the PR<\/svg><\/a> that introduced this bug and
\ncorrectly flagged it as a critical security vulnerability. Despite that
\nwarning, the lead maintainer<\/em> of vLLM force-merged the PR, writing:<\/p>\n

<\/p>\n

Unfortunately, parsing an arbitrary token sequence into a fully fledged chat
\n(with user turns, assistant responses, tool calls, and so on) is not trivial,
\nand the exact process often differs between LLMs. This complexity creates more
\nopportunities for bugs that could permit arbitrary code execution on the host
\nmachine.<\/p>\n

vLLM and SGLang are complex, and bugs are common<\/svg><\/a><\/h2>\n

Modern inference engines do more than map token sequences to strings. vLLM\u2019s
\ndocumentation lists support for more than 200 model architectures<\/svg><\/a>, and its
\nexamples directory contains about 35 Jinja chat templates<\/svg><\/a>. Modern
\ninference engines parse many chat formats, and slightly misspecified parsing
\nlogic result in an LLM\u2019s output being interpreted as code to execute.<\/p>\n

In this vLLM issue<\/svg><\/a>, a user was discussing how LLMs reason with MiniMax-M3,
\nand the LLM emitted the string <mm:think><\/code>. vLLM mistakenly parsed this plain
\nstring as the start of a reasoning block. So instead of:<\/p>\n

\n

Response: I'll echo exactly what you said: <mm:think>\\nThere, how was that?<\/code><\/p>\n<\/blockquote>\n

vLLM parsed this as:<\/p>\n

\n

Response: I'll echo exactly what you said: <\/code><\/p>\n

Reasoning: \\nThere, how was that?<\/code><\/p>\n<\/blockquote>\n

This is a fairly harmless parser bug, but it demonstrates that inference
\nengines do more than convert tokens to strings and concatenate them. They are
\ncomplex systems under constant iteration and their developers are under a lot
\nof pressure to make them as fast as possible. These factors increase the risk
\nthat a malicious LLM could turn a parser bug into arbitrary code execution on
\nthe inference host.<\/p>\n

Vision and audio tokens might<\/em> increase the attack surface<\/svg><\/a><\/h2>\n

Multimodal architectures allow an LLM to respond with images or audio as well as
\nplain text. Turning a model\u2019s audio or visual output into usable media is
\nprobably more complicated than decoding text tokens. However, as far as I can
\ntell, current multimodal LLMs generally emit constrained media tokens rather
\nthan arbitrary file bytes. A model-specific decoder turns those tokens into
\npixels or waveforms, which are then encoded into files. This makes classic
\nmalformed-file exploits against software such as ffmpeg<\/code> or media viewers less
\ndirectly accessible to the model, although the additional decoders, encoders,
\nand native kernels still increase the attack surface.<\/p>\n

I do not currently see multimodal output as a major route to host compromise.
\nHowever, it offers much higher bandwidth than text alone, and future inference
\nengines may optimise these media-generation pathways in ways that make them
\neasier to exploit. I also do not know how proprietary multimodal models
\nrepresent image and audio output; their methods may carry different risks.<\/p>\n

How likely is an LLM to discover and exploit inference engine vulnerabilities?<\/svg><\/a><\/h2>\n

Somewhat likely? I\u2019m unsure. Discovering a useful vulnerability is probably the
\nharder step. The sequence of tokens required to exploit it might be quite
\nunusual, but that does not make the vulnerability impractical to exploit. Given
\nthe right context (e.g. an LLM exploring the vLLM codebase and discovering a
\nvulnerability in the process), I\u2019d expect a frontier LLM to be able to emit the
\ntokens required to exploit it.<\/p>\n

Once an LLM discovers an exploit token sequence, it could store that sequence,
\nor instructions for recreating it, in files, filenames, or URLs likely to enter
\nanother LLM\u2019s context. The exploit would then act as a form of persistent
\nprompt injection: an agent might trigger code execution on the GPU host merely
\nby listing a directory or reading a file.<\/p>\n

Inference engines are an attractive target for power-seeking LLMs<\/svg><\/a><\/h2>\n

I believe<\/del> hope that OpenAI, Google, and Anthropic have security teams that
\nred-team the software they run internally. But as open-weight LLMs become more
\npowerful, we\u2019ll have more LLMs running on bleeding-edge inference engines that
\nhave received less scrutiny. This increases the chance that a malicious
\nopen-weight LLM will encounter and exploit a vulnerable inference engine.<\/p>\n

Another attack vector may emerge as LLMs are increasingly tasked with writing or
\nmodifying the inference engines that run them, usually to improve performance. A
\nmalicious LLM could use that access to plant a backdoor. C++ and CUDA
\ncomponents<\/svg><\/a> of the inference pipeline seem like especially attractive
\ntargets: the LLM could introduce an out-of-bounds memory-access vulnerability
\nthat enables arbitrary code execution on the GPUs or on the CPU host that
\ncontrols them.<\/p>\n

How do we defend against this?<\/svg><\/a><\/h2>\n

Beyond red-teaming inference engines for vulnerabilities, a few other measures
\nmight help:<\/p>\n