CVE-2026-108604 in Tabularis
Summary
by MITRE • 10/10/2026
Tabularis through 0.27.0 contains an incorrect authorization vulnerability in the MCP run_query safety gate that allows prompt-injected agents or untrusted MCP clients to bypass read-only mode by submitting side-effecting SELECT statements. Attackers can run statements like SELECT setval, nextval, or PostgreSQL query_to_xml with embedded DELETE to modify data without approval prompts.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/10/2026
The vulnerability identified in Tabularis versions through 0.27.0 represents a critical failure in access control mechanisms within the Model Context Protocol implementation, specifically affecting the run_query safety gate. This flaw allows unauthorized actors, including prompt-injected agents or untrusted MCP clients, to circumvent read-only restrictions designed to protect database integrity. The core issue lies in the insufficient validation of SQL statements submitted through this interface, which fails to distinguish between benign data retrieval operations and those that induce side effects on the underlying database state. By exploiting this gap, attackers can execute commands such as SELECT setval or nextval, functions typically associated with sequence manipulation, or utilize PostgreSQL query_to_xml with embedded DELETE instructions. These actions effectively bypass the intended safety gates, enabling the modification of persistent data without triggering approval prompts or requiring elevated privileges that would normally be necessary for write operations.
From a technical perspective, this vulnerability is classified under CWE-269 Improper Privilege Management and CWE-749 Exposed Dangerous Method or Function. The root cause stems from an overly permissive interpretation of SQL syntax within the safety gate logic. While standard SELECT statements are generally considered safe for read-only modes, certain PostgreSQL functions invoked via SELECT can perform write operations as a side effect. For instance, setval and nextval modify sequence values which directly impact future insertions or updates, effectively altering database state. Similarly, query_to_xml is not merely a formatting function but an executable command that can contain arbitrary SQL logic within its arguments, including destructive commands like DELETE. The safety gate fails to parse the semantic intent of these nested functions, treating them as simple data retrieval operations rather than potential vectors for unauthorized modification. This oversight highlights a common challenge in integrating large language models with structured query languages, where syntactic validity does not equate to operational safety.
The operational impact of this vulnerability is severe, particularly in environments where Tabularis serves as an intermediary between AI agents and critical data repositories. An attacker who successfully exploits this flaw can alter database sequences, leading to potential primary key collisions or data inconsistency issues when new records are created. More critically, the ability to embed DELETE statements within XML conversion functions allows for the silent removal of sensitive information without leaving obvious traces in standard audit logs that might only monitor explicit UPDATE or DELETE commands issued directly by users. This capability undermines the fundamental security principle of least privilege and compromises the integrity of data managed through Tabularis. In scenarios involving prompt injection, where an attacker manipulates the input to an AI agent to perform unintended actions, this vulnerability provides a direct path from natural language manipulation to database compromise. The lack of approval prompts for these side-effecting operations further exacerbates the risk by removing human oversight that might otherwise catch malicious intent before execution.
To mitigate this vulnerability, immediate updates to Tabularis beyond version 0.27.0 are required if patches have been released addressing this specific logic flaw. In the interim, organizations should implement strict input validation and sanitization layers at the application level rather than relying solely on database-side safety gates. It is advisable to restrict the execution of potentially dangerous PostgreSQL functions such as setval, nextval, query_to_xml with complex arguments, or any function known to have side effects within read-only contexts. Database roles assigned to MCP clients should be configured with minimal permissions, ensuring that even if a malicious SQL statement bypasses application-level checks, it cannot execute write operations due to insufficient database privileges. Additionally, enabling comprehensive audit logging for all sequence modifications and XML conversions can aid in detecting exploitation attempts post-incident. Security teams should also review prompt engineering practices to prevent injection attacks that could leverage this vulnerability, ensuring that AI agents are constrained from executing arbitrary SQL commands without explicit, verified user consent or administrative override mechanisms. This multi-layered approach aligns with ATT&CK techniques related to Command and Scripting Interpreter abuse and Data Manipulation, emphasizing the need for defense in depth when integrating intelligent systems with persistent data stores.