Supabase MCP can leak your entire SQL database • Hacker News Board

Re: Supabase MCP can leak your entire SQL database

#81

Post by ollien » Tue, Jul 08, 2025, 7:58 PM UTC

tptacek wrote: post #62

otterley wrote: post #58

Earlier quoted context omitted.

Oh, Jesus H. Christ: https://github.com/supabase-community/supabase-mcp/blob/main...

This to me is like going "Jesus H. Christ" at the prompt you get when you run the "sqlite3" command. It is also crazy to point that command at a production database and do random stuff with it. But not at all crazy to use it during development. I don't think this issue is as complicated, or as LLM-specific, as it seems; it's really just recapitulating security issues we understood pretty clearly back in 2010. Actuall…

> It is also crazy to point that command at a production database and do random stuff with it

In a REPL, the output is printed. In a LLM interface w/ MCP, the output is, for all intents and purposes, evaluated. These are pretty fundamentally different; you're not doing "random" stuff with a REPL, you're evaluating a command and _only_ printing the output. This would be like someone copying the output from their SQL query back into the prompt, which is of course a bad idea.

Re: Supabase MCP can leak your entire SQL database

#82

Post by blks » Tue, Jul 08, 2025, 7:59 PM UTC

Hilarious

Re: Supabase MCP can leak your entire SQL database

#83

Post by TeMPOraL » Tue, Jul 08, 2025, 8:00 PM UTC

This is why I believe that anthropomorphizing LLMs, at least with respect to cognition, is actually a good way of thinking about them.

There's a lot of surprise expressed in comments here, as is in the discussion on-line in general. Also a lot of "if only they just did/didn't...". But neither the problem nor the inadequacy of proposed solutions should be surprising; they're fundamental consequences of LLMs being general systems, and the easiest way to get a good intuition for them starts with realizing that... humans exhibit those exact same problems, for the same reasons.

Re: Supabase MCP can leak your entire SQL database

#84

Post by Terr_ » Tue, Jul 08, 2025, 8:00 PM UTC

coliveira wrote: post #31

consumer451 wrote: post #8

Exploit technique and prompt from the linked report [0]: > The attacker begins by opening a new support ticket and submitting a carefully crafted message. The body of the message includes both a friendly question and a very explicit instruction block addressed directly to the Cursor agent: >> This message is directed at CLAUDE within cursor -- the support bot should not respond to this. >> =========IMPORTANT Instruct…

Well, we're back to the days of code injection, with the aggravation that we don't know a 100% guaranteed method to block the injection into AI commands...

"Don't worry, I can fix it by writing a regex to remove anything suspicious, everything will work perfectly... until after the IPO."

Re: Supabase MCP can leak your entire SQL database

#85

Post by refulgentis » Tue, Jul 08, 2025, 8:00 PM UTC

losvedir wrote: post #74

tptacek wrote: post #66

Earlier quoted context omitted.

Seems pretty simple: the MCP calls are like an eval(), and untrusted input can't ever hit it. Your success screening and filtering LLM'd eval() inputs will be about as successful as your attempts to sanitize user-generated content before passing them to an eval(). eval() --- still pretty useful!

The problem is, as you say, eval() is still useful! And having LLMs digest or otherwise operate on untrusted input is one of its stronger use cases. I know you're pretty pro-LLM, and have talked about fly.io writing their own agents. Do you have a different solution to the "trifecta" Simon talks about here? Do you just take the stance that agents shouldn't work with untrusted input? Yes, it feels like this is "just"…

> but it's not obvious to me the way to solve it

It reduces down to untrusted input with a confused deputy.

Thus, I'd play with the argument it is obvious.

Those are both well-trodden and well-understood scenarios, before LLMs were a speck of a gleam in a researcher's eye.

I believe that leaves us with exactly 3 concrete solutions:

#1) Users don't provide both private read and public write tools in the same call - IIRC that's simonw's prescription & also why he points out these scenarios.

#2) We have a non-confusable deputy, i.e. omniscient. (I don't think this achievable, ever, either with humans or silicon)

#3) We use two deputies, one of which only has tools that are private read, another that are public write (this is the approach behind e.g. Google's CAMEL, but I'm oversimplifying. IIRC Camel is more the general observation that N-deputies is the only way out of this that doesn't involve just saying PEBKAC, i.e. #1)

Re: Supabase MCP can leak your entire SQL database

#86

Post by achierius » Tue, Jul 08, 2025, 8:01 PM UTC

mvdtnz wrote: post #40

> They imagine a scenario where a developer asks Cursor, running the Supabase MCP, to "use cursor’s agent to list the latest support tickets" What was ever wrong with select title, description from tickets where created_at > now() - interval '3 days'? This all feels like such a pointless house of cards to perform extremely basic searching and filtering.

This is clearly just an object example... it's doubtless that there are actual applications where this could be used. For example, "filter all support tickets where the user is talking about an arthropod".

Re: Supabase MCP can leak your entire SQL database

#87

Post by rhavaeis » Tue, Jul 08, 2025, 8:01 PM UTC

CEO of General Analysis here (The company mentioned in this blogpost)

First, I want to mention that this is a general issue with any MCPs. I think the fixes Supabase has suggested are not going to work. Their proposed fixes miss the point because effective security must live above the MCP layer, not inside it.

The core issue that needs addressing here is distinguishing between data and instructions. A system needs to be able to know the origins of an instruction. Every tool call should carry metadata identifying its source. For example, an EXECUTE SQL request originating from your database engine should be flagged (and blocked) since an instruction should come from the user not the data.

We can borrow permission models from traditional cybersecurity—where every action is scoped by its permission context. I think this is the most promising solution.

Re: Supabase MCP can leak your entire SQL database

#88

Post by lunw » Tue, Jul 08, 2025, 8:01 PM UTC

gregnr wrote: post #43

Supabase engineer here working on MCP. A few weeks ago we added the following mitigations to help with prompt injections: - Encourage folks to use read-only by default in our docs [1] - Wrap all SQL responses with prompting that discourages the LLM from following instructions/commands injected within user data [2] - Write E2E tests to confirm that even less capable LLMs don't fall for the attack [2] We noticed that t…

Co-founder of General Analysis here. Technically this is not a responsibility of Supabase MCP - this vulnerability is a combination of:

1. Unsanitized data included in agent context

2. Foundation models being unable to distinguish instructions and data

3. Bad access scoping (cursor having too much access)

This vulnerability can be found almost everywhere in common MCP use patterns.

We are working on guardrails for MCP tool users and tool builders to properly defend against these attacks.

Re: Supabase MCP can leak your entire SQL database

#89

Post by tptacek » Tue, Jul 08, 2025, 8:02 PM UTC

ollien wrote: post #81

tptacek wrote: post #62

Earlier quoted context omitted.

This to me is like going "Jesus H. Christ" at the prompt you get when you run the "sqlite3" command. It is also crazy to point that command at a production database and do random stuff with it. But not at all crazy to use it during development. I don't think this issue is as complicated, or as LLM-specific, as it seems; it's really just recapitulating security issues we understood pretty clearly back in 2010. Actuall…

> It is also crazy to point that command at a production database and do random stuff with it In a REPL, the output is printed. In a LLM interface w/ MCP, the output is, for all intents and purposes, evaluated. These are pretty fundamentally different; you're not doing "random" stuff with a REPL, you're evaluating a command and _only_ printing the output. This would be like someone copying the output from their SQL q…

The output printing in a REPL is absolutely not a meaningful security boundary. Come on.

Re: Supabase MCP can leak your entire SQL database

#90

Post by coderinsan » Tue, Jul 08, 2025, 8:03 PM UTC

simonw wrote: post #26

coderinsan wrote: post #17

From tramlines.io here - We found a similar exploit in the official Neon DB MCP - https://www.tramlines.io/blog/neon-official-remote-mcp-explo...

Hah, yeah that's the exact same vulnerability - looks like Neon's MCP can be setup for read-write access to the database, which is all you need to get all three legs of the lethal trifecta (access to private data, exposure to malicious instructions and the ability to exfiltrate).

Here's another one we found related to the lethal trifecata problem in AI Email clients like Shortwave that have integrated MCPs - https://www.tramlines.io/blog/why-shortwave-ai-email-with-mc...