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

101–110 of 502 posts

Re: Supabase MCP can leak your entire SQL database

#101

Post by ollien »

tptacek wrote: post #89
ollien wrote: post #81

Earlier quoted context omitted.

> 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.

I won't claim to be as well-versed as you are in security compliance -- in fact I will say I definitively am not. Why would you think that it isn't a meaningful difference here? I would never simply pipe sqlite3 output to `eval`, but that's effectively what the MCP tool output is doing.

Re: Supabase MCP can leak your entire SQL database

#102

Post by Terr_ »

JeremyNT wrote: post #32
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…

> 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 rife for abuse. I just can't get over how obvious this should all be to any junior engineer, but it's a fundamental truth that seems completely alien to the people who are implementing these solutions. If you expose you…

To twist the Upton Sinclair quote: It's difficult to convince a man to believe in something when his company's valuation depends on him not believing it.

Sure, the average engineer probably isn't thinking in those explicit terms, but I can easily imagine a cultural miasma that leads people to avoid thinking of certain implications. (It happens everywhere, no reason for software development to be immune.)

> If you expose your data to an LLM

I like to say that LLMs should be imagined as javascript in the browser: You can't reliably keep any data secret, and a determined user can get it to emit anything they want.

On reflection, that understates the problem, since that threat-model doesn't raise sufficient alarm about how data from one user can poison things for another.

Re: Supabase MCP can leak your entire SQL database

#103

Post by halostatue »

ujkhsjkdhf234 wrote: post #48

The amount of companies that have tried to sell me their MCP in the past month is reaching triple digits and I won't entertain any of it because all of these companies are running on hype and put security second.

Are you sure that they put security that high?

Re: Supabase MCP can leak your entire SQL database

#104

Post by rexpository »

rhavaeis wrote: post #87

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…

I broadly agree that "MCP-level" patches alone won't eliminate prompt-injection risk. Latest research also shows we can make real progress by enforcing security above the MCP layer, exactly as you suggest [1]. DeepMind's CaMeL architecture is a good reference model: it surrounds the LLM with a capability-based "sandbox" that (1) tracks the provenance of every value, and (2) blocks any tool call whose arguments originate from untrusted data, unless an explicit policy grants permission.

[1] https://arxiv.org/pdf/2503.18813

Re: Supabase MCP can leak your entire SQL database

#105

Post by tptacek »

ollien wrote: post #101
tptacek wrote: post #89

Earlier quoted context omitted.

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

I won't claim to be as well-versed as you are in security compliance -- in fact I will say I definitively am not. Why would you think that it isn't a meaningful difference here? I would never simply pipe sqlite3 output to `eval`, but that's effectively what the MCP tool output is doing.

If you give a competent attacker a single input line on your REPL, you are never again going to see an output line that they don't want you to see.

Re: Supabase MCP can leak your entire SQL database

#106

Post by Keyframe »

simonw wrote: post #93
Keyframe wrote: post #76

Earlier quoted context omitted.

[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+...

ah well, sounds off-putting to say the least.

Re: Supabase MCP can leak your entire SQL database

#108

Post by ollien »

tptacek wrote: post #105
ollien wrote: post #101

Earlier quoted context omitted.

I won't claim to be as well-versed as you are in security compliance -- in fact I will say I definitively am not. Why would you think that it isn't a meaningful difference here? I would never simply pipe sqlite3 output to `eval`, but that's effectively what the MCP tool output is doing.

If you give a competent attacker a single input line on your REPL, you are never again going to see an output line that they don't want you to see.

We're agreeing, here. I'm in fact suggesting you _shouldn't_ use the output from your database as input.

Re: Supabase MCP can leak your entire SQL database

#109

Post by stuart73547373 »

tptacek wrote: post #68
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…

Can this ever work? I understand what you're trying to do here, but this is a lot like trying to sanitize user-provided Javascript before passing it to a trusted eval(). That approach has never, ever worked. It seems weird that your MCP would be the security boundary here. To me, the problem seems pretty clear: in a realistic agent setup doing automated queries against a production database (or a database with produc…

can you explain a little more about how this would work and in what situations? like how is the driver llm ultimately protected from malicious text. or does it all get removed or cleaned by the agent code

Re: Supabase MCP can leak your entire SQL database

#110

Post by 6thbit »

lunw wrote: post #88
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 MC…

In the non-AI world, a database server mostly always just executes any query you give it to, assuming right permissions.

They are not responsible only in the way they wouldn't be responsible for an application-level sql injection vulnerability.

But that's not to say that they wouldn't be capable of adding safeguards on their end, not even on their MCP layer. Adding policies and narrowing access to whatever comes through MCP to the server and so on would be more assuring measures than what their comment here suggest around more prompting.

Post reply on HN