CVE-2026-15829: MCP Toolbox for Databases (googleapis/mcp-to

CISO Take

Google's MCP Toolbox for Databases ships a prebuilt BigQuery forecasting tool that builds SQL queries with raw string interpolation (fmt.Sprintf) instead of parameterized queries, letting an attacker break out of the timestamp_col field and inject arbitrary query fragments. The operator-configured allowedDatasets restriction only checks the history_data parameter, so the final assembled query runs with no re-validation of the security boundary it's supposed to enforce — meaning any dataset access control built on this tool is effectively decorative. There's no CVSS score, EPSS data, KEV listing, or public exploit yet, but the flaw sits in an official Google-maintained MCP server that agent frameworks connect to production BigQuery instances, so the blast radius scales with however many teams have deployed this tool as an agent capability. If you or your agent platform use googleapis/mcp-toolbox with the bigquery-forecast tool, treat it as unpatched: pull the fix referenced in PR #3324, or disable the tool and enforce dataset isolation at the IAM/service-account level rather than trusting the toolbox's own allowlist.

Sources: NVD GitHub Advisory ATLAS

What is the risk?

Rated high severity by the source despite no published CVSS/EPSS. Exploitability is moderate — it requires understanding SQL injection technique plus BigQuery's AI.FORECAST table-valued function syntax to craft a working breakout, but no authentication bypass or novel research is needed once the injection point is known. Impact is significant: successful exploitation grants read access to arbitrary BigQuery tables outside the operator's intended boundary, a direct confidentiality breach. No public exploit code, no Nuclei template, and not in CISA KEV — this is a disclosed design flaw rather than an actively exploited one, but the underlying pattern (client-controlled agent tool parameters concatenated into SQL) is common enough across MCP tool implementations that it merits proactive review, not just this one fix.

How does the attack unfold?

Tool Invocation

Attacker (directly or via a manipulated agent) invokes the bigquery-forecast tool, supplying a crafted timestamp_col/data_col/id_cols value.

AML.T0053

SQL Injection

The unescaped parameter is interpolated via fmt.Sprintf into the AI.FORECAST SELECT statement, breaking out of the intended string literal.

Security Boundary Bypass

The final assembled query executes without re-validating the allowedDatasets restriction, which only checked the history_data parameter.

AML.T0107

Data Exfiltration

The injected query block reads arbitrary BigQuery tables outside the operator-configured dataset boundary, returning the data to the attacker via the agent's response.

AML.T0086

Tool Invocation

Attacker (directly or via a manipulated agent) invokes the bigquery-forecast tool, supplying a crafted timestamp_col/data_col/id_cols value.

AML.T0053

SQL Injection

The unescaped parameter is interpolated via fmt.Sprintf into the AI.FORECAST SELECT statement, breaking out of the intended string literal.

Security Boundary Bypass

The final assembled query executes without re-validating the allowedDatasets restriction, which only checked the history_data parameter.

AML.T0107

Data Exfiltration

The injected query block reads arbitrary BigQuery tables outside the operator-configured dataset boundary, returning the data to the attacker via the agent's response.

AML.T0086

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
MCP Toolbox for Databases (googleapis/mcp-toolbox)	—	—	No patch

Do you use MCP Toolbox for Databases (googleapis/mcp-toolbox)? You're affected.

How severe is it?

CVSS 3.1

N/A

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Moderate

What should I do?

1 step

1) Update googleapis/mcp-toolbox to the version incorporating the fix in PR #3324 as soon as it's released/tagged. 2) Until patched, disable or remove the bigquery-forecast tool from any deployed MCP Toolbox instance. 3) Do not rely on the toolbox's allowedDatasets application-layer check as a security boundary — enforce dataset/table access restrictions at the BigQuery IAM and service-account level so a query-construction bug can't grant broader access than intended. 4) Audit BigQuery query logs for AI.FORECAST invocations referencing datasets outside expected scope, and for query text containing unexpected multi-statement or cross-dataset patterns in the timestamp_col/data_col/id_cols positions. 5) For any homegrown MCP tools that build SQL via string formatting, replace with parameterized queries or strict identifier allowlisting (not user-string substitution).

How is it classified?

Auth Bypass Data Leakage Code Execution Agent Plugin API AML.T0053 - AI Agent Tool Invocation AML.T0086 - Exfiltration via AI Agent Tool Invocation AML.T0107 - Exploitation for Defense Evasion

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

NIST AI RMF

MEASURE 2.7 - AI system security and resilience are evaluated

OWASP LLM Top 10

LLM07 - Insecure Plugin Design LLM08 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-15829?

Google's MCP Toolbox for Databases ships a prebuilt BigQuery forecasting tool that builds SQL queries with raw string interpolation (fmt.Sprintf) instead of parameterized queries, letting an attacker break out of the timestamp_col field and inject arbitrary query fragments. The operator-configured allowedDatasets restriction only checks the history_data parameter, so the final assembled query runs with no re-validation of the security boundary it's supposed to enforce — meaning any dataset access control built on this tool is effectively decorative. There's no CVSS score, EPSS data, KEV listing, or public exploit yet, but the flaw sits in an official Google-maintained MCP server that agent frameworks connect to production BigQuery instances, so the blast radius scales with however many teams have deployed this tool as an agent capability. If you or your agent platform use googleapis/mcp-toolbox with the bigquery-forecast tool, treat it as unpatched: pull the fix referenced in PR #3324, or disable the tool and enforce dataset isolation at the IAM/service-account level rather than trusting the toolbox's own allowlist.

Is CVE-2026-15829 actively exploited?

No confirmed active exploitation of CVE-2026-15829 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-15829?

1) Update googleapis/mcp-toolbox to the version incorporating the fix in PR #3324 as soon as it's released/tagged. 2) Until patched, disable or remove the bigquery-forecast tool from any deployed MCP Toolbox instance. 3) Do not rely on the toolbox's allowedDatasets application-layer check as a security boundary — enforce dataset/table access restrictions at the BigQuery IAM and service-account level so a query-construction bug can't grant broader access than intended. 4) Audit BigQuery query logs for AI.FORECAST invocations referencing datasets outside expected scope, and for query text containing unexpected multi-statement or cross-dataset patterns in the timestamp_col/data_col/id_cols positions. 5) For any homegrown MCP tools that build SQL via string formatting, replace with parameterized queries or strict identifier allowlisting (not user-string substitution).

What systems are affected by CVE-2026-15829?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, AI agent tool integrations, MCP tool servers, BigQuery-backed analytics pipelines.

What is the CVSS score for CVE-2026-15829?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksAI agent tool integrationsMCP tool serversBigQuery-backed analytics pipelines

MITRE ATLAS Techniques

AML.T0053 AI Agent Tool Invocation

AML.T0086 Exfiltration via AI Agent Tool Invocation

AML.T0107 Exploitation for Defense Evasion

Compliance Controls Affected

EU AI Act: Article 15

NIST AI RMF: MEASURE 2.7

OWASP LLM Top 10: LLM07, LLM08

What are the technical details?

Original Advisory

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.

Exploitation Scenario

An attacker with access to invoke the agent's tools (either as an authenticated but under-privileged user of the AI agent, or via prompt injection that manipulates the agent into calling the tool with attacker-chosen arguments) requests a forecast and supplies a timestamp_col value crafted to close the string literal early, e.g. injecting a UNION/sub-select clause that pulls from a dataset the operator never intended to expose. Because the allowedDatasets check only inspects history_data and the final query string is executed as-is, BigQuery runs the attacker's injected clause with the same privileges as the service account backing the tool, returning rows from a restricted dataset back through the agent's response to the attacker.

Weaknesses (CWE)

CWE-863 Incorrect Authorization CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')

CWE-863 — Incorrect Authorization: The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

[Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
[Architecture and Design] Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Source: MITRE CWE corpus.