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

51–60 of 502 posts

Re: Supabase MCP can leak your entire SQL database

#51

Post by OtherShrezzing »

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…

Pragmatically, does your responsible disclosure processes matter, when the resolution is “ask the LLM more times to not leak data, and add disclosures to the documentation”?

Re: Supabase MCP can leak your entire SQL database

#52

Post by mort96 »

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

#53

Post by troupo »

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…

> Wrap all SQL responses with prompting that discourages the LLM from following instructions/commands injected within user data

I think this article of mine will be evergreen and relevant: https://dmitriid.com/prompting-llms-is-not-engineering

> Write E2E tests to confirm that even less capable LLMs don't fall for the attack [2]

> We noticed that this significantly lowered the chances of LLMs falling for attacks - even less capable models like Haiku 3.5.

So, you didn't even mitigate the attacks crafted by your own tests?

> e.g. model to detect prompt injection attempts

Adding one bullshit generator on top another doesn't mitigate bullshit generation

Re: Supabase MCP can leak your entire SQL database

#54

Post by troupo »

prmph wrote: post #46
matsemann wrote: post #10

Earlier quoted context omitted.

There are no prepared statements for LLMs. It can't distinguish between your instructions and the data you provide it. So if you want the bot to be able to do certain actions, no prompt engineering can ever keep you safe. Of course, it probably shouldn't be connected and able to read random tables. But even if you want the bot to "only" be able to do stuff in the ticket system (for instance setting a priority) you're…

Why can't the entire submitted text be given to an LLM with the query: Does this contain any Db commands?"?

because the models don't reason. They may or may not answer this question correctly, and there will immediately be an attack vector that bypasses their "reasoning"

Re: Supabase MCP can leak your entire SQL database

#55

Post by btown »

It’s a great reminder that (a) your prod database likely contains some text submitted by users that tries a prompt injection attack, and (b) at some point some developer is going to run something that feeds that text to an LLM that has access to other tools.

It should be a best practice to run any tool output - from a database, from a web search - through a sanitizer that flags anything prompt-injection-like for human review. A cheap and quick LLM could do screening before the tool output gets to the agent itself. Surprised this isn’t more widespread!

Re: Supabase MCP can leak your entire SQL database

#56

Post by ang_cire »

0cf8612b2e1e wrote: post #24
simonw wrote: post #11

Earlier quoted context omitted.

Yeah, I am surprised at the lack of real-world exploits too. I think it's because MCPs still aren't widely enough used that attackers are targeting them. I don't expect that will stay true for much longer.

Could be that the people most likely to mainline MCP hype with full RW permissions are the least likely to have any auditing controls to detect the intrusion.

Yep, the "we don't have a dedicated security team, but we've never had an intrusion anyways!" crowd.

Re: Supabase MCP can leak your entire SQL database

#57

Post by jchanimal »

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…

This is a reason to prefer embedded databases that only contain data scoped to a single user or group.

Then MCP and other agents can run wild within a safer container. The issue here comes from intermingling data.

Re: Supabase MCP can leak your entire SQL database

#58

Post by otterley »

tptacek wrote: post #39

This is just XSS mapped to LLMs. The problem, as is so often the case with admin apps (here "Cursor and the Supabase MCP" is an ad hoc admin app), is that they get a raw feed of untrusted user-generated content (they're internal scaffolding, after all). In the classic admin app XSS, you file a support ticket with HTML and injected Javascript attributes. None of it renders in the customer-facing views, but the admin v…

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

Re: Supabase MCP can leak your entire SQL database

#59

Post by otterley »

troupo wrote: post #53
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…

> Wrap all SQL responses with prompting that discourages the LLM from following instructions/commands injected within user data I think this article of mine will be evergreen and relevant: https://dmitriid.com/prompting-llms-is-not-engineering > Write E2E tests to confirm that even less capable LLMs don't fall for the attack [2] > We noticed that this significantly lowered the chances of LLMs falling for attacks - ev…

> Adding one bullshit generator on top another doesn't mitigate bullshit generation

It's bullshit all the way down. (With apologies to Bertrand Russell)

Re: Supabase MCP can leak your entire SQL database

#60

Post by ollien »

tptacek wrote: post #39

This is just XSS mapped to LLMs. The problem, as is so often the case with admin apps (here "Cursor and the Supabase MCP" is an ad hoc admin app), is that they get a raw feed of untrusted user-generated content (they're internal scaffolding, after all). In the classic admin app XSS, you file a support ticket with HTML and injected Javascript attributes. None of it renders in the customer-facing views, but the admin v…

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, it is fundamentally unsafe to feed _any_ untrusted input into an LLM that has access to privileged information.

Post reply on HN