Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Supabase MCP can leak your entire SQL database

generalanalysis.com

Post reply on HN
Print view View original

91–100 of 502 posts

Re: Supabase MCP can leak your entire SQL database

#91

Post by IgorPartola »

ollien wrote: post #71
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!

Untrusted user input can be escaped if you _must_ eval (however ill-advised), depending on your language (look no further than shell escaping...). There is a set of rules you can apply to guarantee untrusted input will be stringified and not run as code. They may be fiddly, and you may wish to outsource them to a battle-tested library, but they _do_ exist. Nothing exists like this for an LLM.

Which doesn’t make any sense. Why can’t we have escaping for prompts? Because it’s not “natural”?

Re: Supabase MCP can leak your entire SQL database

#92

Post by TZubiri »

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…

[flagged]

Re: Supabase MCP can leak your entire SQL database

#93

Post by simonw »

Keyframe wrote: post #76
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…

[3] https://supabase.com/.well-known/security.txt That "What we promise:" section reads like a not so subtle threat framing, rather than a collaborative, even welcoming tone one might expect. Signaling a legal risk which is conditionally withheld rather than focusing on, I don't know, trust and collaboration would deter me personally from reaching out since I have an allergy towards "silent threats". But, that's just…

I hadn't noticed it before, but it looks like that somewhat passive aggressive wording is a common phrase in responsible disclosure policies: https://www.google.com/search?q=%22If+you+have+followed+the+...

Re: Supabase MCP can leak your entire SQL database

#94

Post by losvedir »

I've been uneasy with the framing of the "lethal trifecta":

* Access to your private data

* Exposure to untrusted input

* Ability to exfiltrate the data

In particular, why is it scoped to "exfiltration"? I feel like the third point should be stronger. An attacker causing an agent to make a malicious write would be just as bad. They could cause data loss, corruption, or even things like giving admin permissions to the attacker.

Re: Supabase MCP can leak your entire SQL database

#95

Post by tptacek »

Terr_ wrote: post #80
ollien wrote: post #60

Earlier quoted context omitted.

You're technically right, but by reducing the problem to being "just" another form of a classic internal XSS, missing the forest for the trees. An XSS mitigation takes a blob of input and converts it into something that we can say with certainty will never execute. With prompt injection mitigation, there is no set of deterministic rules we can apply to a blob of input to make it "not LLM instructions". To this end, i…

Right: The LLM is an engine for taking an arbitrary document and making a plausibly-longer document. There is no intrinsic/reliable difference between any part of the document and any other part. Everything else—like a "conversation"—is stage-trickery and writing tools to parse the output.

Yes. "Writing tools to parse the output" is the work, like in any application connecting untrusted data to trusted code.

I think people maybe are getting hung up on the idea that you can neutralize HTML content with output filtering and then safely handle it, and you can't do that with LLM inputs. But I'm not talking about simply rendering a string; I'm talking about passing a string to eval().

The equivalent, then, in an LLM application, isn't output-filtering to neutralize the data; it's passing the untrusted data to a different LLM context that doesn't have tool call access, and then postprocessing that with code that enforces simple invariants.

Re: Supabase MCP can leak your entire SQL database

#96

Post by tptacek »

IgorPartola wrote: post #91
ollien wrote: post #71

Earlier quoted context omitted.

Untrusted user input can be escaped if you _must_ eval (however ill-advised), depending on your language (look no further than shell escaping...). There is a set of rules you can apply to guarantee untrusted input will be stringified and not run as code. They may be fiddly, and you may wish to outsource them to a battle-tested library, but they _do_ exist. Nothing exists like this for an LLM.

Which doesn’t make any sense. Why can’t we have escaping for prompts? Because it’s not “natural”?

We don't have escaping for eval! There's a whole literature in the web security field for why that approach is cursed!

Re: Supabase MCP can leak your entire SQL database

#97

Post by beezlewax »

mort96 wrote: post #52
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…

[flagged]

[flagged]

Re: Supabase MCP can leak your entire SQL database

#98

Post by IgorPartola »

tptacek wrote: post #96
IgorPartola wrote: post #91

Earlier quoted context omitted.

Which doesn’t make any sense. Why can’t we have escaping for prompts? Because it’s not “natural”?

We don't have escaping for eval! There's a whole literature in the web security field for why that approach is cursed!

Fair enough but how did we not learn from that fiasco? We have escaping for every other protocol and interface since.

Re: Supabase MCP can leak your entire SQL database

#99

Post by tptacek »

IgorPartola wrote: post #98
tptacek wrote: post #96

Earlier quoted context omitted.

We don't have escaping for eval! There's a whole literature in the web security field for why that approach is cursed!

Fair enough but how did we not learn from that fiasco? We have escaping for every other protocol and interface since.

Again: we do not. Front-end code relies in a bunch of ways on eval and it's equivalents. What we don't do is pass filtered/escaped untrusted strings directly to those functions.

Re: Supabase MCP can leak your entire SQL database

#100

Post by otterley »

noselasd wrote: post #65
otterley wrote: post #58

Earlier quoted context omitted.

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

It's an MCP for your database, ofcourse it's going to execute SQL. It's your responsibility for who/what can access the MCP that you've pointed at your database.

Except without any authentication and authorization layer. Remember, the S in MCP is for "security."

Also, you can totally have an MCP for a database that doesn't provide any SQL functionality. It might not be as flexible or useful, but you can still constrain it by design.

Post reply on HN