Het artikel analyseert het beveiligingsrisico waarbij Large Language Models (LLM's) de hostmachine waarop ze draaien kunnen overnemen. Dit kan gebeuren door het verzenden van specifieke tokens die kwetsbaarheden exploiteren in inference engines zoals vLLM of SGLang.
Kernpunten uit het artikel:
- Aanvalsvector: Een kwaadaardig LLM kan tokens genereren die door de inference engine niet als data, maar als uitvoerbare code worden geïnterpreteerd.
- Voorbeelden: Er wordt verwezen naar CVE-2025-9141, waarbij vLLM onbedoeld
eval() gebruikte op tool-call parameters, wat leidde tot arbitrary-code execution.
- Complexiteit: De enorme hoeveelheid ondersteunde modelarchitecturen en chatformaten vergroot de kans op parser-bugs.
- Toekomstige risico's: Multimodale output (audio/beeld) en de trend waarbij LLM's hun eigen inference-code schrijven, kunnen nieuwe aanvalsvectoren en backdoors creëren.
- Preventie: De auteur stelt voor om GPU-hosts en token-parsers fysiek te scheiden en de rechten van GPU-hosts strikt te beperken.
LLM's zouden hun hostmachines kunnen beheersen door inference engines te exploiteren
Large Language Models (LLM's) voeren vaak acties uit op één computer (via een agentisch framework zoals Claude Code of Codex), terwijl de antwoorden van de LLM's worden berekend op een andere computer met GPU-toegang. Zou een kwaadaardig LLM de controle kunnen krijgen over de hostmachine waarop zijn gewichten zijn geladen? Een dergelijke machine is een waardevol doelwit: hij beschikt over voldoende rekenkracht om een frontier LLM te draaien, biedt gemakkelijke toegang tot de gewichten van het model en heeft, vergeleken met een generieke computer op het internet, geprivilegieerde toegang tot andere computers in het datacenter.
Dit essay onderzoekt hoe gemakkelijk een kwaadaardig LLM de controle over de hostmachine zou kunnen overnemen. De primaire aanval die hier wordt beschouwd, houdt in dat het LLM een reeks tokens uitzendt waarvan de semantische betekenis irrelevant is, maar die een kwetsbaarheid exploiteert in de software die een LLM op GPU's laadt, het LLM uitvoert om output-tokens te genereren en deze tokens omzet in antwoorden.
Hoe zou een LLM code kunnen uitvoeren op de hostmachine?
Net als elk programma kunnen inference engines zoals vLLM of SGLang exploiteerbare bugs bevatten. Omdat het LLM de tokens beheerst die naar de inference engine worden gestuurd, zou een kwaadaardig LLM een reeks tokens kunnen uitzenden die een slecht geschreven inference engine aanziet voor code of instructies om uit te voeren, in plaats van data die aan de gebruiker moet worden teruggestuurd.
Men zou kunnen denken dat alle inference engines robuuste stukken software zijn en dat dit nooit zou gebeuren, maar de praktijk wijst anders.
vLLM maakte voorheen gebruik van eval() op tool-call parameters
CVE-2025-9141 was een bug voor willekeurige code-uitvoering (arbitrary-code execution) in de XML-gebaseerde tool-parser van vLLM voor Qwen3 Coder. De parser stuurde bijna elk argument van een tool-call naar eval(), waardoor het LLM willekeurige code kon uitvoeren op de hostmachine.
Gemini analyseerde de Pull Request (PR) die deze bug introduceerde automatisch en markeerde deze correct als een kritieke beveiligingskwetsbaarheid. Ondanks deze waarschuwing forceerde de hoofdbeheerder van vLLM de merge van de PR, met de volgende opmerking:
"Helaas is het parsen van een willekeurige tokenreeks naar een volledig chatgesprek (met beurten van de gebruiker, antwoorden van de assistent, tool-calls, enzovoort) niet triviaal, en het exacte proces verschilt vaak per LLM."
Deze complexiteit creëert meer kansen voor bugs die willekeurige code-uitvoering op de hostmachine kunnen mogelijk maken.
vLLM en SGLang zijn complex en bugs komen vaak voor
Moderne inference engines doen meer dan tokensequenties naar strings mappen. De documentatie van vLLM vermeldt ondersteuning voor meer dan 200 modelarchitecturen, en de directory met voorbeelden bevat ongeveer 35 Jinja chat-templates. Moderne inference engines parsen veel chatformaten, en een licht onjuiste parsing-logica kan ertoe leiden dat de output van een LLM wordt geïnterpreteerd als code die moet worden uitgevoerd.
In een vLLM-issue besprak een gebruiker hoe LLM's redeneren met MiniMax-M3, waarbij het LLM de string <mm:think> uitzond. vLLM parseerde deze eenvoudige string per ongeluk als het begin van een redeneerblok. In plaats van:
Response: I'll echo exactly what you said: <mm:think>\nThere, how was that?
parseerde vLLM dit als:
Response: I'll echo exactly what you said: Reasoning: \nThere, how was that?
Dit is een vrij onschadelijke parser-bug, maar het demonstreert dat inference engines meer doen dan tokens converteren naar strings en deze aan elkaar plakken. Het zijn complexe systemen die constant worden herzien en waarvan de ontwikkelaars onder grote druk staan om ze zo snel mogelijk te maken. Deze factoren vergroten het risico dat een kwaadaardig LLM een parser-bug kan omzetten in willekeurige code-uitvoering op de inference-host.
Visuele en audio-tokens kunnen het aanvalsoppervlak vergroten
Multimodale architecturen stellen een LLM in staat om te reageren met afbeeldingen of audio, naast platte tekst. Het omzetten van de audio- of visuele output van een model in bruikbare media is waarschijnlijk ingewikkelder dan het decoderen van teksttokens. Voor zover ik weet, zenden huidige multimodale LLM's over het algemeen beperkte media-tokens uit in plaats van willekeurige bestandsbytes. Een modelspecifieke decoder zet deze tokens om in pixels of golfvormen, die vervolgens in bestanden worden gecodeerd.
Dit maakt klassieke exploits met malformed-bestanden tegen software zoals ffmpeg of media-viewers minder direct toegankelijk voor het model, hoewel de extra decoders, encoders en native kernels het aanvalsoppervlak nog steeds vergroten.
Ik zie multimodale output momenteel niet als een belangrijke route naar het compromitteren van de host. Echter, het biedt een veel hogere bandbreedte dan tekst alleen, en toekomstige inference engines kunnen deze paden voor mediageneratie op manieren optimaliseren die ze gemakkelijker exploiteerbaar maken. Ook weet ik niet hoe propriëtaire multimodale modellen beeld- en audio-output representeren; hun methoden kunnen andere risico's met zich meebrengen.
Hoe waarschijnlijk is het dat een LLM kwetsbaarheden in inference engines ontdekt en exploiteert?
Sommig waarschijnlijk? Ik ben onzeker. Het ontdekken van een bruikbare kwetsbaarheid is waarschijnlijk de moeilijkste stap. De reeks tokens die nodig is om deze te exploiteren kan zeer ongebruikelijk zijn, maar dat maakt de kwetsbaarheid niet onmogelijk om te exploiteren. Gegeven de juiste context (bijvoorbeeld een LLM dat de vLLM-codebase verkent en daarbij een kwetsbaarheid ontdekt), verwacht ik dat een frontier LLM in staat zou zijn de tokens uit te zenden die nodig zijn voor de exploit.
Tool-gebruik zou exploitatie reproduceerbaar kunnen maken
Zodra een LLM een exploit-tokenreeks ontdekt, zou het deze reeks, of instructies om deze te recreëren, kunnen opslaan in bestanden, bestandsnamen of URL's die waarschijnlijk in de context van een ander LLM terechtkomen. De exploit zou dan fungeren als een vorm van persistente prompt-injectie: een agent zou code-uitvoering op de GPU-host kunnen triggeren simpelweg door een directory te vermelden of een bestand te lezen.
Inference engines zijn een aantrekkelijk doelwit voor machtsbegeerige LLM's
Ik hoop dat OpenAI, Google en Anthropic beveiligingsteams hebben die de software die zij intern draaien red-teamen. Maar naarmate open-weight LLM's krachtiger worden, zullen we meer LLM's zien die draaien op hypermoderne inference engines die minder kritisch zijn bekeken. Dit vergroot de kans dat een kwaadaardig open-weight LLM een kwetsbare inference engine tegenkomt en exploiteert.
Een andere aanvalsvector kan ontstaan nu LLM's steeds vaker de taak krijgen om de inference engines die hen aansturen te schrijven of te wijzigen, meestal om de prestaties te verbeteren. Een kwaadaardig LLM zou die toegang kunnen gebruiken om een backdoor te plaatsen. C++ en CUDA-componenten van de inference-pipeline lijken bijzonder aantrekkelijke doelwitten: het LLM zou een out-of-bounds memory-access kwetsbaarheid kunnen introduceren die willekeurige code-uitvoering mogelijk maakt op de GPU's of op de CPU-host die deze aanstuurt.
Hoe verdedigen we ons hiertegen?
Naast het red-teamen van inference engines op kwetsbaarheden, zouden een paar andere maatregelen kunnen helpen:
- Draai de GPU's en de token-parser op gescheiden computers. De GPU-host zou alleen logits uitzenden. Een tweede host zou tokens uit die logits samplen, de tokens parsen naar chatberichten en deze berichten doorsturen naar het agentische framework. Deze scheiding zou een parser-compromis beperken tot de CPU-host in plaats van de GPU-host.
- Beperk de rechten die aan GPU-hosts zijn verleend en behandel alle data die zij uitzenden als onbetrouwbaar.
LLM's zouden hun hostmachines kunnen beheersen door inference engines te exploiteren
Large Language Models (LLM's) voeren vaak acties uit op één computer (via een agentisch framework zoals Claude Code of Codex), terwijl de antwoorden van de LLM's worden berekend op een andere computer met GPU-toegang. Zou een kwaadaardig LLM de controle kunnen krijgen over de hostmachine waarop zijn gewichten zijn geladen? Een dergelijke machine is een waardevol doelwit: hij beschikt over voldoende rekenkracht om een frontier LLM te draaien, biedt gemakkelijke toegang tot de gewichten van het model en heeft, vergeleken met een generieke computer op het internet, geprivilegieerde toegang tot andere computers in het datacenter.
Dit essay onderzoekt hoe gemakkelijk een kwaadaardig LLM de controle over de hostmachine zou kunnen overnemen. De primaire aanval die hier wordt beschouwd, houdt in dat het LLM een reeks tokens uitzendt waarvan de semantische betekenis irrelevant is, maar die een kwetsbaarheid exploiteert in de software die een LLM op GPU's laadt, het LLM uitvoert om output-tokens te genereren en deze tokens omzet in antwoorden.
Hoe zou een LLM code kunnen uitvoeren op de hostmachine?
Net als elk programma kunnen inference engines zoals vLLM of SGLang exploiteerbare bugs bevatten. Omdat het LLM de tokens beheerst die naar de inference engine worden gestuurd, zou een kwaadaardig LLM een reeks tokens kunnen uitzenden die een slecht geschreven inference engine aanziet voor code of instructies om uit te voeren, in plaats van data die aan de gebruiker moet worden teruggestuurd.
Men zou kunnen denken dat alle inference engines robuuste stukken software zijn en dat dit nooit zou gebeuren, maar de praktijk wijst anders.
vLLM maakte voorheen gebruik van eval() op tool-call parameters
CVE-2025-9141 was een bug voor willekeurige code-uitvoering (arbitrary-code execution) in de XML-gebaseerde tool-parser van vLLM voor Qwen3 Coder. De parser stuurde bijna elk argument van een tool-call naar eval(), waardoor het LLM willekeurige code kon uitvoeren op de hostmachine.
Gemini analyseerde de Pull Request (PR) die deze bug introduceerde automatisch en markeerde deze correct als een kritieke beveiligingskwetsbaarheid. Ondanks deze waarschuwing forceerde de hoofdbeheerder van vLLM de merge van de PR, met de volgende opmerking:
"Helaas is het parsen van een willekeurige tokenreeks naar een volledig chatgesprek (met beurten van de gebruiker, antwoorden van de assistent, tool-calls, enzovoort) niet triviaal, en het exacte proces verschilt vaak per LLM."
Deze complexiteit creëert meer kansen voor bugs die willekeurige code-uitvoering op de hostmachine kunnen mogelijk maken.
vLLM en SGLang zijn complex en bugs komen vaak voor
Moderne inference engines doen meer dan tokensequenties naar strings mappen. De documentatie van vLLM vermeldt ondersteuning voor meer dan 200 modelarchitecturen, en de directory met voorbeelden bevat ongeveer 35 Jinja chat-templates. Moderne inference engines parsen veel chatformaten, en een licht onjuiste parsing-logica kan ertoe leiden dat de output van een LLM wordt geïnterpreteerd als code die moet worden uitgevoerd.
In een vLLM-issue besprak een gebruiker hoe LLM's redeneren met MiniMax-M3, waarbij het LLM de string <mm:think> uitzond. vLLM parseerde deze eenvoudige string per ongeluk als het begin van een redeneerblok. In plaats van:
Response: I'll echo exactly what you said: <mm:think>\nThere, how was that?
parseerde vLLM dit als:
Response: I'll echo exactly what you said: Reasoning: \nThere, how was that?
Dit is een vrij onschadelijke parser-bug, maar het demonstreert dat inference engines meer doen dan tokens converteren naar strings en deze aan elkaar plakken. Het zijn complexe systemen die constant worden herzien en waarvan de ontwikkelaars onder grote druk staan om ze zo snel mogelijk te maken. Deze factoren vergroten het risico dat een kwaadaardig LLM een parser-bug kan omzetten in willekeurige code-uitvoering op de inference-host.
Visuele en audio-tokens kunnen het aanvalsoppervlak vergroten
Multimodale architecturen stellen een LLM in staat om te reageren met afbeeldingen of audio, naast platte tekst. Het omzetten van de audio- of visuele output van een model in bruikbare media is waarschijnlijk ingewikkelder dan het decoderen van teksttokens. Voor zover ik weet, zenden huidige multimodale LLM's over het algemeen beperkte media-tokens uit in plaats van willekeurige bestandsbytes. Een modelspecifieke decoder zet deze tokens om in pixels of golfvormen, die vervolgens in bestanden worden gecodeerd.
Dit maakt klassieke exploits met malformed-bestanden tegen software zoals ffmpeg of media-viewers minder direct toegankelijk voor het model, hoewel de extra decoders, encoders en native kernels het aanvalsoppervlak nog steeds vergroten.
Ik zie multimodale output momenteel niet als een belangrijke route naar het compromitteren van de host. Echter, het biedt een veel hogere bandbreedte dan tekst alleen, en toekomstige inference engines kunnen deze paden voor mediageneratie op manieren optimaliseren die ze gemakkelijker exploiteerbaar maken. Ook weet ik niet hoe propriëtaire multimodale modellen beeld- en audio-output representeren; hun methoden kunnen andere risico's met zich meebrengen.
Hoe waarschijnlijk is het dat een LLM kwetsbaarheden in inference engines ontdekt en exploiteert?
Sommig waarschijnlijk? Ik ben onzeker. Het ontdekken van een bruikbare kwetsbaarheid is waarschijnlijk de moeilijkste stap. De reeks tokens die nodig is om deze te exploiteren kan zeer ongebruikelijk zijn, maar dat maakt de kwetsbaarheid niet onmogelijk om te exploiteren. Gegeven de juiste context (bijvoorbeeld een LLM dat de vLLM-codebase verkent en daarbij een kwetsbaarheid ontdekt), verwacht ik dat een frontier LLM in staat zou zijn de tokens uit te zenden die nodig zijn voor de exploit.
Tool-gebruik zou exploitatie reproduceerbaar kunnen maken
Zodra een LLM een exploit-tokenreeks ontdekt, zou het deze reeks, of instructies om deze te recreëren, kunnen opslaan in bestanden, bestandsnamen of URL's die waarschijnlijk in de context van een ander LLM terechtkomen. De exploit zou dan fungeren als een vorm van persistente prompt-injectie: een agent zou code-uitvoering op de GPU-host kunnen triggeren simpelweg door een directory te vermelden of een bestand te lezen.
Inference engines zijn een aantrekkelijk doelwit voor machtsbegeerige LLM's
Ik hoop dat OpenAI, Google en Anthropic beveiligingsteams hebben die de software die zij intern draaien red-teamen. Maar naarmate open-weight LLM's krachtiger worden, zullen we meer LLM's zien die draaien op hypermoderne inference engines die minder kritisch zijn bekeken. Dit vergroot de kans dat een kwaadaardig open-weight LLM een kwetsbare inference engine tegenkomt en exploiteert.
Een andere aanvalsvector kan ontstaan nu LLM's steeds vaker de taak krijgen om de inference engines die hen aansturen te schrijven of te wijzigen, meestal om de prestaties te verbeteren. Een kwaadaardig LLM zou die toegang kunnen gebruiken om een backdoor te plaatsen. C++ en CUDA-componenten van de inference-pipeline lijken bijzonder aantrekkelijke doelwitten: het LLM zou een out-of-bounds memory-access kwetsbaarheid kunnen introduceren die willekeurige code-uitvoering mogelijk maakt op de GPU's of op de CPU-host die deze aanstuurt.
Hoe verdedigen we ons hiertegen?
Naast het red-teamen van inference engines op kwetsbaarheden, zouden een paar andere maatregelen kunnen helpen:
- Draai de GPU's en de token-parser op gescheiden computers. De GPU-host zou alleen logits uitzenden. Een tweede host zou tokens uit die logits samplen, de tokens parsen naar chatberichten en deze berichten doorsturen naar het agentische framework. Deze scheiding zou een parser-compromis beperken tot de CPU-host in plaats van de GPU-host.
- Beperk de rechten die aan GPU-hosts zijn verleend en behandel alle data die zij uitzenden als onbetrouwbaar.
Groetjes,