-
Notifications
You must be signed in to change notification settings - Fork 104
Description
Hey Neon team — I reviewed mcp-server-neon and wanted to share a few security observations. I see you've already put thought into this (tool annotations, read-only mode, migration safety workflow) — these findings are about gaps in the current implementation.
TL;DR
run_sql accepts arbitrary SQL with no server-side statement validation. Destructive project operations execute immediately. Connection strings with embedded passwords flow into the LLM context.
Findings
1. Unrestricted SQL execution (CRITICAL)
run_sql and run_sql_transaction pass SQL strings directly to the database with no statement-type filtering. An agent can execute DROP, TRUNCATE, GRANT, or COPY TO PROGRAM.
The readOnlySafe: true flag on both tools is misleading — they remain available in read-only mode, and the only enforcement is a runtime SET TRANSACTION READ ONLY. Your README acknowledges this: "Read-only mode restricts which tools are available, not the SQL content."
2. Project/branch deletion without confirmation (HIGH)
delete_project permanently destroys everything — branches, databases, roles, compute endpoints — in a single tool call with no confirmation gate or undo. Same for delete_branch and reset_from_parent. The destructiveHint annotation is correct but advisory only.
3. Connection strings with embedded passwords in responses (HIGH)
get_connection_string and create_project return full Postgres URIs including the password directly in the tool response. These credentials then live in the LLM's context window and conversation logs.
4. Migration SQL integrity gap (MEDIUM)
The migration workflow is stateless — prepare_database_migration returns the SQL to the LLM, which passes it back to complete_database_migration. There's no HMAC or signature binding the SQL to the migration ID. A prompt injection between the two steps could substitute destructive SQL.
Suggestions
- SQL statement classification — at minimum, offer a
query_onlymode that rejects non-SELECT at the server level - Redact passwords from connection string responses — return host/database/role without the embedded credential
- Migration integrity binding — sign the SQL content with the migration ID
- Project scoping — allow configuring an allowlist of project IDs per session
Good security foundation already in place. These would close the remaining structural gaps.
Found using AgentWard — open-source permission control plane for AI agents.