fix(mcp): close approval/read-only bypass in run_query#261
Merged
Conversation
The MCP run_query approval gate classified queries by their leading keyword, so a stacked payload (`SELECT 1; DROP TABLE users`) was tagged as a clean read and slipped past both the read-only and approval gates. An approver could also edit an approved SELECT into a DELETE/DROP, which was never re-validated. - classify_query_kind now fails closed on multi-statement payloads, stripping string literals under both the SQL-standard and MySQL backslash-escape readings so neither dialect can hide a `;` separator - tool_run_query re-classifies and re-enforces read-only on the approver-edited query before execution
Code Review SummaryStatus: No Issues Found | Recommendation: Merge Files Reviewed (3 files)
Reviewed by kimi-k2.6 · 426,420 tokens |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The MCP
run_queryapproval/read-only gates classify a query by its leading keyword, so a stacked payload such asSELECT 1; DROP TABLE userswas tagged as a clean read (select) and slipped past both the read-only gate and the approval gate. Separately, when an approver edited an approved query before confirming, the edit was executed without being re-classified — so an approvedSELECTcould be flipped into aDELETE/DROP.This PR makes the classifier fail closed on multi-statement payloads and re-enforces the gates on the approver-edited query.
The bypass
classify_query_kind("SELECT 1; DROP TABLE users")returned"select"because only the first keyword was inspected. Both gates rely onkind != "select"to block, so the write reached the driver.edited_queryreplaced the original query but the originalkindwas kept, so read-only was never re-checked against what actually runs.Changes
ai_activity.rs—classify_query_kindnow returns"unknown"(fail closed) when a;is followed by more SQL. String literals are stripped under both the SQL-standard ('') and MySQL backslash-escape (\') readings, and a trailing statement under either reading trips the gate — so a payload can't hide a;separator by exploiting whichever dialect we don't assume (e.g.SELECT '\''; DROP TABLE users).mcp/mod.rs—tool_run_queryre-classifies the approver-edited query and re-applies the read-only gate before execution, updating the audit record with the effective query/kind.Test plan
cargo test --lib ai_activity— 54 passing, incl. new cases:SELECT 1; DROP …/…; DELETE …/…; UPDATE …→unknown'\''; DROP …cannot hide the separator →unknown;inside string literals / comments /''escape boundary → staysselect;keeps its kindcargo check --libcleanNotes
Rebased on current
main(incl. #256). The execution layer's prepared-statement protocol already rejected most stacked queries, but the classifier is the documented fail-closed gate — this restores that contract.