Summary
Tabularis before 0.28.0 contains an SQL injection vulnerability in its SQLite driver through the describe_table tool. An attacker, or an AI agent influenced by untrusted content, may provide a crafted table_name that appends SQLite statements, enabling data access or modification and potentially bypassing read-only controls.
Tabularis before 0.28.0 contains an SQL injection vulnerability in its SQLite driver through the describe_table tool. An attacker, or an AI agent influenced by untrusted content, may provide a crafted table_name that appends SQLite statements, enabling data access or modification and potentially bypassing read-only controls.
Affected context
The vulnerability occurs in Tabularis deployments using the SQLite driver and exposing the MCP describe_table tool. It becomes risky when the tool incorporates an untrusted table_name into a quoted SQLite PRAGMA expression without safely separating data from SQL syntax. Configurations that rely on read-only mode or write approval may still be exposed if stacked statements are accepted before those controls take effect.
The vulnerability occurs in Tabularis deployments using the SQLite driver and exposing the MCP describe_table tool. It becomes risky when the tool incorporates an untrusted table_name into a quoted SQLite PRAGMA expression without safely separating data from SQL syntax. Configurations that rely on read-only mode or write approval may still be exposed if stacked statements are accepted before those controls take effect.
Exploit preconditions
- Attack surface: MCP
describe_tabletool backed by the SQLite driver - Required access: Ability to invoke the MCP tool, directly or through an AI agent or integration
- Trigger point: Processing a crafted
table_nameargument - Why exploitation is possible: The value is incorporated into a quoted PRAGMA argument in a way that may allow the quote to be closed and additional SQLite statements to execute
- Control limitation: Read-only settings or write approval mechanisms may not prevent statements injected into the database request
- Attack surface: MCP
describe_tabletool backed by the SQLite driver - Required access: Ability to invoke the MCP tool, directly or through an AI agent or integration
- Trigger point: Processing a crafted
table_nameargument - Why exploitation is possible: The value is incorporated into a quoted PRAGMA argument in a way that may allow the quote to be closed and additional SQLite statements to execute
- Control limitation: Read-only settings or write approval mechanisms may not prevent statements injected into the database request
Why this happens
The underlying bug is improper neutralization of user-controlled input used in an SQL statement. The SQLite driver treats the table_name value as part of SQL syntax instead of strictly as data, allowing a crafted value to alter the intended PRAGMA operation and introduce stacked statements. This behavior maps to CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection').
The underlying bug is improper neutralization of user-controlled input used in an SQL statement. The SQLite driver treats the table_name value as part of SQL syntax instead of strictly as data, allowing a crafted value to alter the intended PRAGMA operation and introduce stacked statements. This behavior maps to CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection').
Potential impact
- An attacker may read SQLite tables or sensitive application data
- An attacker could modify or delete stored records
- Database schema or metadata could be altered
- Read-only expectations and write approval controls may be bypassed
- Application integrity, auditability, or downstream AI-agent behavior may be affected
- An attacker may read SQLite tables or sensitive application data
- An attacker could modify or delete stored records
- Database schema or metadata could be altered
- Read-only expectations and write approval controls may be bypassed
- Application integrity, auditability, or downstream AI-agent behavior may be affected
General mitigation guidance
Mitigation generally focuses on ensuring that database identifiers and metadata inputs cannot become executable SQL syntax.
Common defensive patterns include:
- Use parameterized APIs or dedicated SQLite metadata interfaces wherever supported
- Apply strict allowlists and canonical validation for table names and other identifiers
- Avoid constructing PRAGMA statements through string interpolation
- Separate read-only metadata operations from mutation-capable database connections
- Enforce least-privilege database permissions and restrict write capabilities by default
- Treat AI-agent-provided and externally sourced tool arguments as untrusted
- Apply independent authorization and transaction controls rather than relying only on approval prompts
Mitigation generally focuses on ensuring that database identifiers and metadata inputs cannot become executable SQL syntax.
Common defensive patterns include:
- Use parameterized APIs or dedicated SQLite metadata interfaces wherever supported
- Apply strict allowlists and canonical validation for table names and other identifiers
- Avoid constructing PRAGMA statements through string interpolation
- Separate read-only metadata operations from mutation-capable database connections
- Enforce least-privilege database permissions and restrict write capabilities by default
- Treat AI-agent-provided and externally sourced tool arguments as untrusted
- Apply independent authorization and transaction controls rather than relying only on approval prompts
How teams detect issues like this
Detection approaches may include:
- Static analysis for SQL strings built through concatenation, interpolation, or formatting with tool arguments
- Code review checks for unvalidated identifiers used in PRAGMA statements or other metadata queries
- Runtime logging of rejected identifier values, unexpected statement counts, and database mutations during metadata operations
- Policy enforcement requiring parameterized database access and approved identifier-validation helpers
- Integration tests that verify metadata tools cannot execute multiple statements or perform writes
Automated security review tools can help identify unsafe SQL construction patterns, but findings should be validated against the actual database API and authorization model.
Detection approaches may include:
- Static analysis for SQL strings built through concatenation, interpolation, or formatting with tool arguments
- Code review checks for unvalidated identifiers used in PRAGMA statements or other metadata queries
- Runtime logging of rejected identifier values, unexpected statement counts, and database mutations during metadata operations
- Policy enforcement requiring parameterized database access and approved identifier-validation helpers
- Integration tests that verify metadata tools cannot execute multiple statements or perform writes
Automated security review tools can help identify unsafe SQL construction patterns, but findings should be validated against the actual database API and authorization model.
