CVE-2026-15829 in MCP Toolbox for Databases
Summary
by MITRE • 07/21/2026
A SQL injection (CWE-89) and security boundary bypass (CWE-863) vulnerability exists in the prebuilt BigQuery forecasting tool (bigquery-forecast) of googleapis/mcp-toolbox.
The tool accepts client-controlled parameters (data_col, timestamp_col, and id_cols) as plain strings and interpolates them unescaped via fmt.Sprintf directly into a generated AI.FORECAST table-valued SELECT statement. While MCP Toolbox utilizes an allowedDatasets mechanism to restrict queries, this defense only validates the history_data parameter; the final assembled query is executed without re-validation.
An attacker can break out of the string literal fields (such as timestamp_col) to inject a valid multi-statement or cross-dataset query block. This allows an unauthorized user to bypass the operator-configured allowedDatasets boundary and read arbitrary BigQuery tables.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 07/21/2026
The vulnerability under examination represents a critical security flaw in the googleapis/mcp-toolbox's bigquery-forecast prebuilt tool, manifesting as both SQL injection (CWE-89) and security boundary bypass (CWE-863) conditions that together create a severe privilege escalation vector. This issue stems from improper input validation and sanitization mechanisms within the tool's query construction process, where user-controllable parameters are directly interpolated into BigQuery SQL statements without adequate escaping or validation.
The technical implementation of this vulnerability occurs through the tool's handling of three specific client-controlled parameters: data_col, timestamp_col, and id_cols. These parameters are processed as plain strings and passed directly to fmt.Sprintf for interpolation into a generated AI.FORECAST table-valued SELECT statement. The absence of proper parameter sanitization or escaping allows malicious actors to manipulate these inputs to inject arbitrary SQL constructs. When an attacker supplies carefully crafted values containing SQL injection payloads within the timestamp_col field, they can effectively break out of the intended string literal context and inject multi-statement queries or cross-dataset references that would otherwise be prohibited.
The operational impact of this vulnerability extends beyond typical SQL injection scenarios due to the security boundary bypass component that enables unauthorized data access. While the MCP Toolbox does implement an allowedDatasets mechanism designed to restrict query execution to predefined datasets, this protective measure only validates the history_data parameter and fails to re-validate the final assembled query. This design flaw creates a critical gap where attackers can construct queries that bypass the configured dataset restrictions entirely, allowing them to read data from arbitrary BigQuery tables that should otherwise be inaccessible to unauthorized users.
The attack surface is particularly concerning because it leverages legitimate tool functionality to achieve unauthorized access rather than exploiting traditional application vulnerabilities. The combination of SQL injection and boundary bypass creates a multi-layered threat where attackers can not only execute malicious queries but also circumvent the very security controls designed to protect against such attacks. This vulnerability aligns with ATT&CK technique T1078 for Valid Accounts and T1566 for Phishing, as it enables unauthorized access through legitimate tool usage patterns while potentially requiring minimal reconnaissance to identify exploitable parameters.
Mitigation strategies should focus on implementing proper input validation and parameterized queries throughout the tool's execution pipeline. The most effective approach involves introducing comprehensive sanitization of all user-controllable parameters before interpolation, utilizing BigQuery's native parameter binding mechanisms instead of string concatenation, and ensuring that security boundary validations occur at multiple levels including pre-query construction and post-construction re-validation. Additionally, implementing principle of least privilege access controls for the tool's operational environment and regular audit logging of query execution patterns would help detect and prevent unauthorized access attempts while maintaining system integrity and data confidentiality standards.