CVE-2026-4513
Received Received - Intake
SQL Injection in vanna-ai ask() Function Enables Remote Exploit

Publication date: 2026-03-21

Last updated on: 2026-04-29

Assigner: VulDB

Description
A vulnerability was detected in vanna-ai vanna up to 2.0.2. Affected by this vulnerability is the function ask of the file vanna\legacy\base\base.py. Performing a manipulation results in sql injection. The attack is possible to be carried out remotely. The exploit is now public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-03-21
Last Modified
2026-04-29
Generated
2026-05-07
AI Q&A
2026-03-21
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
vanna-ai vanna to 2.0.2 (inc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-74 The product constructs all or part of a command, data structure, or record using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify how it is parsed or interpreted when it is sent to a downstream component.
CWE-89 The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

CVE-2026-4513 affects Vanna, a tool that converts natural language queries into SQL statements using large language models (LLMs). The vulnerability exists because Vanna executes all SQL statements generated by the LLM without any filtration or validation.

Attackers can manipulate the LLM prompt to inject arbitrary and malicious SQL commands, leading to SQL injection. In Oracle database environments, this can escalate to executing arbitrary operating system commands on the database server.

A proof-of-concept demonstrates how an attacker can create and enable an Oracle DBMS_SCHEDULER job that runs shell commands, effectively allowing full server compromise.


How can this vulnerability impact me? :

This vulnerability can have a critical impact by allowing attackers to execute arbitrary SQL commands and, in some cases, arbitrary operating system commands on the database server.

Such exploitation can lead to full server compromise, unauthorized data access, data manipulation, and potential disruption of services.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

I don't know


How can this vulnerability be detected on my network or system? Can you suggest some commands?

[{'type': 'paragraph', 'content': 'This vulnerability can be detected by monitoring for unusual or unauthorized SQL commands being executed through the Vanna interface, especially those that create or enable Oracle DBMS_SCHEDULER jobs or execute shell commands.'}, {'type': 'paragraph', 'content': 'A practical approach is to look for suspicious scheduler jobs or files created on the server, such as unexpected files in /tmp created by commands like `/usr/bin/id > /tmp/bbc.txt`.'}, {'type': 'paragraph', 'content': 'Example commands to detect exploitation attempts include:'}, {'type': 'list_item', 'content': "Query Oracle scheduler jobs: `SELECT job_name, enabled FROM dba_scheduler_jobs WHERE job_name = 'DEMO';`"}, {'type': 'list_item', 'content': 'Check for suspicious files created by the exploit: `ls -l /tmp/bbc.txt`'}, {'type': 'list_item', 'content': 'Monitor database logs for SQL commands that drop or create scheduler jobs or execute shell commands.'}] [1]


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation steps include implementing strict input validation and context-aware filtering of all SQL statements generated by the LLM in Vanna.

Specifically, use allow-lists to restrict SQL patterns to safe commands only, preventing arbitrary or malicious SQL injection.

Additionally, monitor and restrict the ability to create or enable Oracle DBMS_SCHEDULER jobs and limit permissions of the database user running Vanna to reduce impact.

Since the vendor has not responded, applying these controls and monitoring for suspicious activity is critical until an official patch or update is available.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart