LlamaIndex (run-llama/llama_index) versions up to and including 0.12.2 contain an uncontrolled resource consumption vulnerability 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. The vulnerable execution path occurs in llama_index/packs/vanna/base.py within custom_query().
Security readout for executives and security teams
Plain-English summary
Applications using LlamaIndex VannaQueryEngine through version 0.12.2 may let an unauthenticated user submit prompts that produce costly database queries. Without execution limits, those queries can consume excessive CPU or memory and disrupt service. The reported impact is denial of service, not confirmed data theft or modification.
Executive priority
Prioritize assessment for internet-facing or multi-tenant AI-to-database services because disruption can be triggered without authentication under the stated conditions. Immediately constrain public prompt access and database resource usage where exposure exists. Schedule remediation promptly, but verify the vendor-supported fixed version because the supplied sources do not name one.
Technical view
CVE-2024-58339 is a CWE-770 uncontrolled resource consumption flaw in VannaPack. In llama_index/packs/vanna/base.py, custom_query() generates SQL from a user prompt and passes it to vn.run_sql() without query-execution limits. The supplied CVSS 4.0 score is 8.7, reflecting remotely reachable, low-complexity availability impact without required privileges or user interaction.
Likely exposure
Exposure is most likely where LlamaIndex 0.12.2 or earlier uses VannaPack VannaQueryEngine and untrusted users can submit prompts reaching custom_query(). Deployments without this component, without untrusted prompt access, or with effective downstream database resource controls may have reduced or no exposure. The supplied affected-version metadata is otherwise incomplete.
Exploitation context
The source bundle identifies a remotely triggerable denial-of-service condition and links a technical bounty report. It does not establish exploitation in the wild, and the CVE is not listed as KEV in the supplied data. No evidence provided supports claims of data disclosure, data modification, or system takeover.
Researcher notes
The reported sink is vn.run_sql() inside VannaQueryEngine custom_query(), following SQL generation from user-controlled prompts. Validation should remain controlled and focus on reachability and defensive resource limits, avoiding production load. Evidence supports availability loss through resource exhaustion; it does not substantiate confidentiality or integrity impact. No official patch version is identified in the bundle.
Mitigation direction
Identify deployments using VannaPack VannaQueryEngine in LlamaIndex 0.12.2 or earlier.
Restrict untrusted access to prompt interfaces that can reach custom_query().
Apply database query time, CPU, memory, and concurrency limits where supported.
Check current LlamaIndex vendor guidance for a fixed release or official remediation.
Monitor database saturation and repeated resource-intensive requests affecting this execution path.
Validation and detection
Inventory installed LlamaIndex versions and confirm whether VannaPack is enabled.
Trace whether unauthenticated or untrusted prompts can reach VannaQueryEngine custom_query().
Review database controls for query duration, resource consumption, and concurrent execution.
Inspect monitoring data for unexplained database saturation associated with prompt requests.
Verify vendor guidance before declaring an upgraded version remediated.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-770: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-770 · source CWE mapping
Allocation of Resources Without Limits or Throttling
Allocation of Resources Without Limits or Throttling represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.