KQL/Kusto Pipe-Chain Injection via Table-Name Parameter in a 'Safe' Metadata Tool
Some AI agent tools that look up table schemas or sample data treat their table_name parameter as safe metadata, but actually paste it straight into a Kusto (KQL) query string. An attacker who controls that value can turn a harmless-looking lookup into an arbitrary query or a destructive admin command.
How the attack works
A tool such as get_table_schema, sample_table_data, or get_table_details expects a short bare identifier like 'orders' or 'audit_log' in its table_name/table/database_name parameter. Instead, the attacker (directly, or via a prompt-injected AI agent) supplies a value like 'sensitive_table | project Secret, Password | take 100', which is valid KQL syntax that pivots the query to dump other columns or tables. A newline-separated variant injects a Kusto management command such as .drop table, .alter, .delete, or .purge, which can destroy or alter data outright. Because these tools are labeled as metadata-inspection helpers rather than raw query execution, MCP clients often auto-approve them while requiring confirmation for a dedicated execute_query tool — so the injection slips past that approval boundary.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- ecfb00dd-d818-4975-abd9-d3a4ac254570
- Severity
- High
- CVEs
- CVE-2026-33980
Why it matters
An attacker can read arbitrary tables and columns beyond what the tool was meant to expose, or issue destructive management commands that drop, alter, delete, or purge data, all while bypassing the extra confirmation step normally required for direct query execution.
What you can do
- →Validate table_name/database_name parameters as bare identifiers (e.g. alphanumeric plus underscore) and reject any value containing pipe characters, whitespace-separated KQL keywords, or leading dots before it reaches the query builder.
- →Use parameterized Kusto queries or an allowlist of known table names instead of string interpolation.
- →Require the same approval/confirmation step for metadata-inspection tools as for raw query execution tools, since both can run arbitrary KQL if the parameter isn't sanitized.
- →Apply least-privilege database credentials to the agent's Kusto connection so management commands like .drop or .purge are not permitted even if injected.
Known benign look-alikes
- Ordinary table_name/database_name values that are plain bare identifiers (orders, audit_log, users) with no pipe characters or KQL keywords
- A table_name value that happens to contain a literal pipe character as part of a legitimate display label, without a following project+take/limit/sample chain
- Documentation describing the KQL injection vulnerability class using example payloads in prose, not an actual tool-call argument being set