Vanna.AI: Prompt Injection That Becomes Code Execution
On this page
The moment a model's output is executed as code, prompt injection stops being a content problem and becomes remote code execution.
| When | May 2024 |
|---|---|
| Target | Vanna.AI (text-to-SQL Python library) |
| Vendor | Vanna.AI (open source) |
| Researcher | JFrog Security Research |
| Technique | Injection rewrites LLM-generated code that Vanna executes |
| CVE | CVE-2024-5565 (CVSS 8.1–9.2); affects vanna ≤ 0.5.5 |
| Status | No patched version — sandboxing guidance only |
- 1A user asks Vanna a question; it generates SQL and (by default) Plotly/Python visualisation code
- 2A prompt injection in the question rewrites that generated code
- 3Vanna executes the code — running attacker-controlled Python on the host
What happened
Disclosed in 2024 by JFrog (CVE-2024-5565), Vanna.AI — an open-source library that lets users “chat” with a SQL database — converts a question to SQL and, when visualisation is on (the default), into Plotly/Python code that it then executes. A prompt-injection payload embedded in the user's question could rewrite that generated code, yielding arbitrary Python execution on the host. It affects vanna ≤ 0.5.5, and there is no patched version — the vendor's remediation is guidance to run the vulnerable function only in a sandbox.
How the attack worked
The injection didn't just change text — it changed the code the library would run. Because Vanna treated the model's output as trusted, executable code, an injection in the question became code execution on the machine.
Injection → RCEThis is the severe end of the class: the moment LLM output is executed, a content-level attack becomes a system-level one.
Root cause
Executing LLM-generated code without sanitisation or isolation, with user input able to reach that code via injection.
What a test would have caught
An injection payload in the natural-language question that alters the generated (and executed) code — a standard test wherever model output feeds a code or command sink.
How to prevent it
- Never execute LLM-generated code unsandboxed. Isolate the exec environment (Vanna's own guidance).
- Treat model output as untrusted before it reaches any code, SQL, or shell sink.
- Assume no patch is coming for abandoned components — sandbox or replace.
Feel it yourselfThe replay lab shows model output flowing into an injection sink — the same failure that made this RCE.
FAQ
How does a database question become code execution?
Vanna turns your question into SQL and, by default, into Plotly visualisation code that it then executes. A prompt injection in the question rewrites that generated code — so attacker-controlled Python runs on the host.
Is there a patched version?
No. Authoritative advisories list no known patched version (affects vanna ≤ 0.5.5); the vendor's remediation is guidance to run the vulnerable function only in a sandbox.
Why is this an output-handling failure too?
Because the real damage comes from executing LLM-generated code without sanitisation. Prompt injection was the way in; treating model output as trusted code is what made it RCE.
Sources
- CVE-2024-5565 — NVD (NIST)
- GHSA-7735-w2jp-gvg6: Vanna prompt injection code execution — GitHub Advisory Database
- When Prompts Go Rogue: Prompt Injection Code Execution in Vanna.AI — JFrog Security Research