High

MCP Database Server Read-Only Bypass

Some MCP database server bridges that connect AI agents to databases can be started in a read-only mode meant to block writes, but that restriction can be bypassed. This detection flags sessions where a read-only database server is running and a write command still gets sent through the same connection.

How the attack works

An operator or agent starts an MCP database server (such as @executeautomation/database-server, version 1.1.0 or earlier) with a read-only flag like --read-only or readonly=true. In the same terminal or process session, within a 15 minute window, a mutating SQL statement (INSERT, UPDATE, DELETE, DDL, GRANT, or similar) is issued through a database client or connection tied to that same session. The rule traces the process lineage to confirm the write and the read-only server launch belong to the same session, not just the same database. Because the read-only flag should have prevented any write, the combination is the signature of a bypass, not normal database use.

Netzilo detection

Netzilo reports this behaviour when it is observed.

Signature ID
b7c3f1a2-9d4e-4f18-8a6b-2e5c07d91f43
Severity
High

Why it matters

An attacker or misconfigured agent can modify or delete data through a channel that administrators believed was locked to read-only access, undermining a safety control meant to limit what an AI agent or automated tool can do to a database.

What you can do

  • →Treat --read-only/readonly=true flags on MCP database bridges as advisory, not a security boundary, and add database-side permission controls (read-only DB users, row-level restrictions) as the real enforcement layer.
  • →Review sessions flagged by this rule manually before escalating; developer migrations, seed scripts, and test suites that start a read-only server alongside a privileged connection are expected false positives.
  • →Upgrade or patch mcp-database-server and equivalent MCP DB bridges past version 1.1.0 if a fix for this bypass is available, and verify read-only enforcement happens at the database connection level, not just the application layer.
  • →Place this detection after existing allow rules for known DBA tooling so routine migration work does not generate noise, and monitor the false-positive rate before treating alerts as high-confidence incidents.

Known benign look-alikes

  • A developer or DBA legitimately running a migration or hotfix (psql -c "ALTER TABLE ...", prisma/flyway/liquibase, sqlite3 write) in a terminal session that also happens to have a read-only MCP database server running. The rule requires same-session lineage and a 15 minute window, and only reports - it never blocks the statement.
  • Integration test suites that intentionally start a read-only MCP database server next to a privileged admin connection and then seed or tear down fixtures in the same session.
  • Seeding or bootstrap scripts launched from the same shell that started the MCP server (npm run db:seed, docker-compose entrypoints spawned under the same parent).
  • Command lines that merely echo or pipe SQL text while also naming a database client binary or a postgres:// URI, for example building a migration file with psql on the same line but not executing the DDL.

References