CVE-2026-14538: BigQuery allowedDatasets bypass

CISO Take

Google's mcp-toolbox — the official MCP server many teams use to let LLM agents query BigQuery — has a fail-open logic flaw in its bigquery-execute-sql tool: when the BigQuery dry-run API returns an empty result array for certain specialized SQL constructs, the toolbox's allowedDatasets access control silently passes instead of denying. An authenticated user of the agent (not necessarily a human with direct BigQuery access) can exploit this to pull INFORMATION_SCHEMA DDL from datasets that were explicitly excluded from the agent's scope, and pivot into federated row-level data via EXTERNAL_QUERY connections. There's no CISA KEV listing, no public exploit, and no EPSS score, so this is not an active-exploitation emergency — but it directly undermines the access-control boundary that data governance and least-privilege designs for agentic BigQuery access depend on, which matters a lot if you've deployed this tool assuming allowedDatasets is a hard boundary. Upgrade past mcp-toolbox 1.4.0 (fix landed in the linked PR) and, until confirmed patched in your environment, audit `allowedDatasets` configs, add BigQuery-side IAM/row-access-policy enforcement as defense-in-depth (don't rely on the toolbox as the sole control), and review BigQuery audit logs for INFORMATION_SCHEMA or EXTERNAL_QUERY calls against datasets a given service account/agent shouldn't be able to see.

Sources: NVD GitHub Advisory ATLAS

What is the risk?

Medium severity as scored, and rightly so given the prerequisite of authenticated access to the agent and the absence of KEV listing, public exploit code, or a Nuclei template. However, the exploitability bar is lower than a typical CVSS-medium bug: no privilege escalation or memory corruption is needed, just crafting SQL constructs that trigger an empty dry-run response — a logic/config bypass, not a technical exploit chain. The real risk driver is architectural: this vulnerability defeats the specific control (allowedDatasets) that organizations configure to segment which BigQuery datasets an AI agent is permitted to touch, so any deployment that treats that setting as a security boundary rather than a convenience filter is exposed to unintended cross-dataset schema and data disclosure.

How does the attack unfold?

Authenticated tool access

Attacker with legitimate but restricted access invokes the bigquery-execute-sql tool through the AI agent, which is configured with allowedDatasets to limit scope.

AML.T0053

Fail-open trigger

Attacker crafts a specialized SQL construct that causes the BigQuery dry-run API to return an empty array, causing the toolbox's allowedDatasets validation to fail open.

AML.T0107

Schema and data exfiltration

With validation bypassed, the attacker queries INFORMATION_SCHEMA for DDL of excluded datasets and uses EXTERNAL_QUERY to reach federated row-level data.

AML.T0086

Data governance breach

Sensitive structural and row-level data from datasets meant to be off-limits to the agent is disclosed, breaking the intended tenant/data isolation boundary.

Authenticated tool access

Attacker with legitimate but restricted access invokes the bigquery-execute-sql tool through the AI agent, which is configured with allowedDatasets to limit scope.

AML.T0053

Fail-open trigger

Attacker crafts a specialized SQL construct that causes the BigQuery dry-run API to return an empty array, causing the toolbox's allowedDatasets validation to fail open.

AML.T0107

Schema and data exfiltration

With validation bypassed, the attacker queries INFORMATION_SCHEMA for DDL of excluded datasets and uses EXTERNAL_QUERY to reach federated row-level data.

AML.T0086

Data governance breach

Sensitive structural and row-level data from datasets meant to be off-limits to the agent is disclosed, breaking the intended tenant/data isolation boundary.

How severe is it?

CVSS 3.1

7.7 / 10

EPSS

0.2%

chance of exploitation in 30 days

Higher than 8% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AV Network

AC Low

PR Low

UI None

S Changed

C High

I None

A None

What should I do?

1 step

Upgrade Google mcp-toolbox to a version beyond 1.4.0 that includes the fix referenced in googleapis/mcp-toolbox PR #3452. Until upgraded, do not rely solely on allowedDatasets for isolation — enforce equivalent restrictions natively in BigQuery via IAM dataset-level permissions, authorized views, or row/column-level access policies tied to the service account the toolbox uses. Audit existing agent configurations for datasets marked as excluded and verify via BigQuery audit logs whether INFORMATION_SCHEMA or EXTERNAL_QUERY calls have touched them. Add detection rules for dry-run API calls returning empty arrays on specialized constructs correlated with subsequent schema/data queries against restricted datasets.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Auth Bypass Data Extraction Data Leakage 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

ISO 42001

Annex A.6.2 - Data for AI systems

OWASP LLM Top 10

LLM02:2025 - Sensitive Information Disclosure LLM06:2025 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-14538?

Google's mcp-toolbox — the official MCP server many teams use to let LLM agents query BigQuery — has a fail-open logic flaw in its bigquery-execute-sql tool: when the BigQuery dry-run API returns an empty result array for certain specialized SQL constructs, the toolbox's allowedDatasets access control silently passes instead of denying. An authenticated user of the agent (not necessarily a human with direct BigQuery access) can exploit this to pull INFORMATION_SCHEMA DDL from datasets that were explicitly excluded from the agent's scope, and pivot into federated row-level data via EXTERNAL_QUERY connections. There's no CISA KEV listing, no public exploit, and no EPSS score, so this is not an active-exploitation emergency — but it directly undermines the access-control boundary that data governance and least-privilege designs for agentic BigQuery access depend on, which matters a lot if you've deployed this tool assuming allowedDatasets is a hard boundary. Upgrade past mcp-toolbox 1.4.0 (fix landed in the linked PR) and, until confirmed patched in your environment, audit `allowedDatasets` configs, add BigQuery-side IAM/row-access-policy enforcement as defense-in-depth (don't rely on the toolbox as the sole control), and review BigQuery audit logs for INFORMATION_SCHEMA or EXTERNAL_QUERY calls against datasets a given service account/agent shouldn't be able to see.

Is CVE-2026-14538 actively exploited?

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

How to fix CVE-2026-14538?

Upgrade Google mcp-toolbox to a version beyond 1.4.0 that includes the fix referenced in googleapis/mcp-toolbox PR #3452. Until upgraded, do not rely solely on allowedDatasets for isolation — enforce equivalent restrictions natively in BigQuery via IAM dataset-level permissions, authorized views, or row/column-level access policies tied to the service account the toolbox uses. Audit existing agent configurations for datasets marked as excluded and verify via BigQuery audit logs whether INFORMATION_SCHEMA or EXTERNAL_QUERY calls have touched them. Add detection rules for dry-run API calls returning empty arrays on specialized constructs correlated with subsequent schema/data queries against restricted datasets.

What systems are affected by CVE-2026-14538?

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

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

CVE-2026-14538 has a CVSS v3.1 base score of 7.7 (HIGH). The EPSS exploitation probability is 0.19%.

What is the AI security impact?

Affected AI Architectures

agent frameworksMCP tool integrationsdata 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

ISO 42001: Annex A.6.2

OWASP LLM Top 10: LLM02:2025, LLM06:2025

What are the technical details?

Original Advisory

An improper authorization and security-boundary bypass vulnerability in the bigquery-execute-sql tool component of Google mcp-toolbox versions 0.16.1 through 1.4.0 allows an authenticated attacker to bypass allowedDatasets validation checks. The toolbox relies on the BigQuery dry-run API to enforce dataset restrictions, but due to a fail-open logic flaw, it bypasses validation when the API returns an empty array for specialized constructs. This allows the attacker to extract structural DDL schemas for explicitly excluded datasets via INFORMATION_SCHEMA, and access downstream federated row data via EXTERNAL_QUERY connections.

Exploitation Scenario

A contractor or lower-trust internal user has legitimate access to a company's BigQuery-backed AI analytics agent, which is configured via mcp-toolbox to only allow queries against their business unit's dataset (allowedDatasets). The attacker crafts a SQL query using a specialized construct (e.g., certain DDL or metadata-function syntax) that causes BigQuery's dry-run validation API to return an empty array instead of the expected dataset reference list. Because the toolbox fails open on empty dry-run results, the allowedDatasets check is skipped, and the query executes against a restricted dataset. The attacker then queries INFORMATION_SCHEMA to map out the excluded dataset's table structure, and uses EXTERNAL_QUERY to reach federated data sources connected to that dataset, exfiltrating both schema intelligence and sensitive row data they were never meant to access.

Weaknesses (CWE)

CWE-285 Improper Authorization CWE-285 Improper Authorization CWE-863 Incorrect Authorization CWE-863 Incorrect Authorization

CWE-285 — Improper Authorization: The product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action.

[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) 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 you perform access control checks related to your business logic. These checks may be different than the access control checks that you apply 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.

Source: MITRE CWE corpus.