MCP SQL execution falsely flags identifiers containing disallowed function names

[luoianun]

Bug description

When using Superset MCP / Database.execute() with a MySQL-compatible database, the SQL security check for DISALLOWED_SQL_FUNCTIONS appears to match disallowed function names by substring against the full SQL statement.

As a result, normal identifiers that contain words such as user or schema are falsely rejected, even when they are not function calls.

Example sanitized query:

SELECT
  event_date,
  SUM(metric_user_count) AS total_users
FROM some_metrics_table
WHERE event_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY)
GROUP BY event_date
LIMIT 5;

Actual result:

Disallowed SQL functions: user

Another generic example is querying MySQL metadata:

SELECT table_name
FROM information_schema.tables
WHERE table_schema = 'example_schema'
LIMIT 3;

This can be falsely rejected as:

Disallowed SQL functions: schema

Expected behavior:

Superset should only reject real SQL function calls such as:

SELECT USER();
SELECT SCHEMA();

It should not reject column names, table names, schema names, or aliases that merely contain those substrings.

Root cause

In superset/sql/execution/executor.py, _check_disallowed_functions() appears to check each disallowed function with substring matching against the statement string:

statement_str = str(statement).upper()
for func in engine_disallowed:
    if func.upper() in statement_str:
        found.add(func)

This causes false positives for identifiers such as:

metric_user_count
information_schema
table_schema

Superset already has AST-based function detection in the SQL parsing layer, for example script.check_functions_present(...), which checks actual function nodes instead of arbitrary substrings.

Suggested fix

Use AST-based function detection instead of substring matching. For example:

found = {
    func
    for func in engine_disallowed
    if script.check_functions_present({func})
}

This keeps the intended protection for real disallowed function calls, while avoiding false positives on identifiers.

Environment

Superset version: 6.1.0
Python version: 3.10
Node version: Not applicable
Browser: Not applicable
Database engine: MySQL-compatible database
Component: Superset MCP SQL execution / Database.execute()

Additional context

This was observed while using Superset MCP to execute read-only SQL and create virtual datasets/charts from a MySQL-compatible database.

A local patch using script.check_functions_present({func}) fixed the false positives:

• Queries with identifiers containing user succeeded.
• Queries with information_schema / table_schema succeeded.
• A real USER() function call was still rejected with Disallowed SQL functions: user.

So the issue seems isolated to function detection using substring matching instead of AST function-call detection.

Checklist

• I have searched Superset docs and Slack and didn't find a solution to my problem.
• I have searched the GitHub issue tracker and didn't find a similar bug report.
• I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.

[dosubot]

Hi @luoianun! I'm Dosu and I'm helping the Apache Superset team.

Your analysis is spot on. The substring matching in _check_disallowed_functions() does cause false positives for identifiers like metric_user_count or table_schema.

This bug is addressed in PR #40963, which introduces a two-layer fix in the SQL executor:

1. Primary check — AST-based detection via a new get_present_functions() method that walks sqlglot's parsed AST (find_all(exp.Func)) to identify actual function call nodes, avoiding false matches on column names, aliases, or schema references.
2. Fallback check — for SQL that fails to parse entirely, a word-boundary regex (\b...\b) is used instead of substring matching, so e.g. skilllevel won't trigger kill.

Worth noting: the existing SQL Lab code path in superset/sql_lab.py already uses the AST-based check_functions_present() method [1], which is essentially the approach you suggested. The bug is isolated to the newer executor code path that your MCP queries are hitting.

Your suggested fix of using script.check_functions_present({func}) aligns exactly with what the PR implements. That PR is open but not yet merged — you may want to track it or continue using your local patch in the meantime.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.