CVE-2024-58339: LlamaIndex VannaPack DoS Vulnerability

CVE-2024-58339 Overview

LlamaIndex (run-llama/llama_index) versions up to and including 0.12.2 contain an uncontrolled resource consumption vulnerability (CWE-770) in the VannaPack VannaQueryEngine implementation. The custom_query() logic generates SQL statements from a user-supplied prompt and executes them via vn.run_sql() without enforcing query execution limits. In downstream deployments where untrusted users can supply prompts, an attacker can trigger expensive or unbounded SQL operations that exhaust CPU or memory resources, resulting in a denial-of-service condition.

Critical Impact

This vulnerability allows remote unauthenticated attackers to cause denial-of-service conditions by submitting crafted prompts that generate resource-intensive SQL queries, potentially exhausting server CPU and memory resources.

Affected Products

• LlamaIndex (run-llama/llama_index) versions up to and including 0.12.2
• Applications using VannaPack VannaQueryEngine with untrusted user input
• Downstream deployments accepting user-supplied prompts for SQL generation

Discovery Timeline

• 2026-01-12 - CVE CVE-2024-58339 published to NVD
• 2026-01-13 - Last updated in NVD database

Technical Details for CVE-2024-58339

Vulnerability Analysis

The vulnerability resides in the VannaPack VannaQueryEngine component of LlamaIndex, specifically within the custom_query() function located in llama_index/packs/vanna/base.py. This function accepts user-provided natural language prompts, translates them into SQL statements using the Vanna text-to-SQL engine, and then executes those statements directly against the underlying database via the vn.run_sql() method.

The core security flaw is the absence of any query execution limits, timeouts, or resource consumption controls when processing user input. This design allows malicious actors to craft prompts that generate computationally expensive SQL operations such as full table scans, complex JOIN operations across large datasets, recursive queries, or operations that return massive result sets.

When deployed in environments where untrusted users have access to the prompt interface, an attacker can systematically submit prompts designed to trigger these resource-intensive database operations. The resulting SQL execution can rapidly consume available CPU cycles and memory, effectively denying service to legitimate users.

Root Cause

The root cause is improper implementation of resource management controls in the custom_query() function. The code path from user prompt to SQL execution lacks:

• Query timeout enforcement
• Result set size limits
• CPU/memory consumption boundaries
• Query complexity analysis or rejection
• Rate limiting on query submissions

This is classified as CWE-770 (Allocation of Resources Without Limits or Throttling), where the application fails to restrict the amount of resources consumed when processing external input.

Attack Vector

The attack vector is network-based, requiring no authentication and no user interaction. An attacker with network access to a LlamaIndex deployment using VannaQueryEngine can exploit this vulnerability by:

1. Identifying an application endpoint that accepts natural language prompts for SQL generation
2. Crafting prompts that will generate resource-intensive SQL operations (e.g., "Show me all possible combinations of all records across all tables")
3. Submitting multiple such prompts to amplify the resource exhaustion effect
4. Causing denial-of-service to legitimate users as the database and application resources become exhausted

The vulnerability exists in the custom_query() function in llama_index/packs/vanna/base.py, where SQL statements generated from user prompts are executed without any protective measures against resource abuse.

Detection Methods for CVE-2024-58339

Indicators of Compromise

• Unusual spikes in database CPU or memory utilization correlated with VannaQueryEngine activity
• Long-running SQL queries originating from LlamaIndex application processes
• Increased frequency of prompt submissions from single sources or IP addresses
• Database connection pool exhaustion or timeout errors
• Application performance degradation coinciding with prompt processing

Detection Strategies

• Monitor database query execution times and set alerts for queries exceeding reasonable thresholds
• Implement logging for all prompts submitted to VannaQueryEngine and review for suspicious patterns
• Track resource consumption metrics for application processes using VannaPack components
• Configure database-level query timeouts and monitor for timeout events
• Use application performance monitoring (APM) tools to identify abnormal resource consumption patterns

Monitoring Recommendations

• Enable detailed query logging in the database backend to capture all executed SQL statements
• Set up alerts for CPU and memory utilization thresholds on servers running LlamaIndex applications
• Monitor for unusual patterns in prompt length, complexity, or submission frequency
• Implement connection and query metrics collection for VannaQueryEngine database interactions

How to Mitigate CVE-2024-58339

Immediate Actions Required

• Review deployments using LlamaIndex VannaPack VannaQueryEngine for exposure to untrusted user input
• Implement database-level query timeouts and resource limits as a defense-in-depth measure
• Add rate limiting on endpoints that accept user prompts for SQL generation
• Restrict access to VannaQueryEngine-powered features to authenticated and authorized users only
• Monitor for updates from the LlamaIndex project addressing this vulnerability

Patch Information

As of the last NVD update on 2026-01-13, organizations should monitor the LlamaIndex GitHub repository for security updates addressing this vulnerability. Review the VulnCheck Advisory and Huntr Vulnerability Report for the latest remediation guidance.

Workarounds

• Implement a wrapper around custom_query() that enforces query execution timeouts
• Add input validation and prompt sanitization before passing to VannaQueryEngine
• Deploy database-level query governors to limit execution time and resource consumption
• Use network-level rate limiting to prevent rapid submission of malicious prompts
• Consider using a read replica or separate database instance for VannaQueryEngine queries to isolate potential impact

# Example database-level timeout configuration (PostgreSQL)
# Set statement timeout to prevent long-running queries
ALTER DATABASE llama_db SET statement_timeout = '30s';

# Set work_mem to limit memory per operation
ALTER DATABASE llama_db SET work_mem = '64MB';

# Enable query logging for monitoring
ALTER DATABASE llama_db SET log_min_duration_statement = 1000;