Summary
A SQL injection vulnerability in the BigQuery forecasting tool of MCP Toolbox allows client-controlled column parameters to be inserted into generated SQL without adequate escaping. An attacker who can invoke the tool may bypass the configured dataset boundary and read BigQuery tables outside the approved scope.
Affected context
The vulnerability occurs in the prebuilt bigquery-forecast tool when
client-supplied values such as data_col, timestamp_col, and id_cols are
treated as trusted SQL fragments. The risk is greater when the tool is
exposed to untrusted MCP clients and relies on allowedDatasets as the
primary restriction on accessible BigQuery data. The boundary may be
ineffective if it validates only the original history_data value rather
than the fully assembled query.
Exploit preconditions
- Attack surface: The MCP Toolbox
bigquery-forecasttool and its
generated BigQuery statement
- Required access: Ability to invoke the tool with client-controlled
forecasting parameters
- Trigger point: Construction and execution of the AI.FORECAST table-valued
SELECT statement
- Why exploitation is possible: User-controlled identifiers are
interpolated into SQL without safe structural validation, while the final
query is executed without rechecking the configured dataset boundary
Why this happens
The underlying issue is construction of SQL with direct string interpolation
of client-controlled values. Treating column names and related parameters as
plain strings allows input to alter the structure and scope of the generated
statement rather than remaining limited to an intended identifier.
This maps primarily to CWE-89: Improper Neutralization of Special Elements used in an SQL Command (SQL Injection). The incomplete enforcement of the
allowedDatasets policy also maps to CWE-863: Incorrect Authorization,
because the effective authorization check does not cover the final operation
performed by the generated query.
Potential impact
- An attacker may read arbitrary BigQuery tables accessible to the service
identity.
- The configured
allowedDatasetsboundary could be bypassed. - Sensitive analytical, operational, or customer data could be disclosed.
- Additional query behavior may be introduced if the execution environment
permits multi-statement or cross-dataset operations.
- Audit records may attribute unauthorized access to the forecasting tool.
General mitigation guidance
Mitigation generally focuses on eliminating SQL string construction from
untrusted values and enforcing authorization on the complete operation.
Common defensive patterns include:
- Representing columns and datasets with structured, validated identifiers
rather than interpolated strings.
- Allowing only explicitly approved column names and dataset references from
server-side metadata.
- Using query parameters for values and safe builder APIs for SQL structure
where supported.
- Re-validating the fully assembled query or its referenced resources before
execution.
- Enforcing dataset and table authorization independently through BigQuery
permissions and service-account least privilege.
- Disabling unnecessary multi-statement behavior and restricting cross-dataset
access by policy.
- Treating all MCP client parameters as untrusted, including values that
appear to be column or schema names.
How teams detect issues like this
Detection approaches may include:
- Static analysis rules for
fmt.Sprintf, concatenation, or templating used
to construct SQL from request parameters.
- Code review checks for dynamic identifiers that lack allowlists or
structured parsing.
- Tests that verify authorization is applied to the final generated query
and every referenced dataset.
- Runtime monitoring for unexpected dataset references, multi-statement
queries, and access patterns outside the forecasting tool's normal scope.
- BigQuery audit-log policies that alert when the tool's service identity
reads resources beyond its approved datasets.
- Automated security review tools can help identify SQL sinks and incomplete
authorization checks during development.
