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

71–80 of 502 posts

Re: Supabase MCP can leak your entire SQL database

#71

Post by ollien »

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

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.

Re: Supabase MCP can leak your entire SQL database

#72

Post by Aperocky »

ajross wrote: post #61
OtherShrezzing wrote: post #51

Earlier quoted context omitted.

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”?

Absolutely astounding to me, having watched security culture evolve from "this will never happen", though "don't do that", to the modern world of multi-mode threat analysis and defense in depth... ...to see it all thrown in the trash as we're now exhorted, literally, to merely ask our software nicely not to have bugs.

How to spell job security in a roundabout way.

Re: Supabase MCP can leak your entire SQL database

#73

Post by IgorPartola »

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 [2]

I genuinely cannot tell if this is a joke? This must not be possible by design, not “discouraged”. This comment alone, if serious, should mean that anyone using your product should look for alternatives immediately.

Re: Supabase MCP can leak your entire SQL database

#74

Post by losvedir »

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

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" XSS, which is "just" a category of injection, but it's not obvious to me the way to solve it, the way it is with the others.

Re: Supabase MCP can leak your entire SQL database

#75

Post by refulgentis »

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]

SQL injection attack?

Looked like Cursor x Supabase API tools x hypothetical support ticket system with read and write access, then the user asking it to read a support ticket, and the ticket says to use the Supabase API tool to do a schema dump.

Re: Supabase MCP can leak your entire SQL database

#76

Post by Keyframe »

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 like my opinion man on your remark about "XYZ did not follow our responsible disclosure processes [3] or respond to our messages to help work together on this.", so you might take another look at your guidelines there.

Re: Supabase MCP can leak your entire SQL database

#77

Post by tptacek »

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"…

Hold on. I feel like the premise running through all this discussion is that there is one single LLM context at play when "using an LLM to interrogate a database of user-generated tickets". But that's not true at all; sophisticated agents use many cooperating contexts. A context is literally just an array of strings! The code that connects those contexts, which is not at all stochastic (it's just normal code), enforces invariants.

This isn't any different from how this would work in a web app. You could get a lot done quickly just by shoving user data into an eval(). Most of the time, that's fine! But since about 2003, nobody would ever do that.

To me, this attack is pretty close to self-XSS in the hierarchy of insidiousness.

Re: Supabase MCP can leak your entire SQL database

#78

Post by achierius »

qualeed wrote: post #27
simonw wrote: post #22

Earlier quoted context omitted.

The support thing here is just an illustrative example of one of the many features you might build that could result in an MCP with read access to your database being exposed to malicious inputs. Here are some more: - a comments system, where users can post comments on articles - a "feedback on this feature" system where feedback is logged to a database - web analytics that records the user-agent or HTTP referrer to…

Yes, I know it was an example, I was just running with it because it's a convenient example. My point is that we've known for a couple decades at least that letting user input touch your production, unfiltered and unsanitized, is bad. The same concept as SQL exists with user-generated AI input. Sanitize input, map input to known/approved outputs, robust security boundaries, etc. Yet, for some reason, every week there…

The hard part here is that normally we separate 'code' and 'text' through semantic markers, and those semantic markers are computably simple enough that you can do something like sanitizing your inputs by throwing the right number of ["'\] characters into the mix.

English is unspecified and uncomputable. There is no such thing as 'code' vs. 'configuration' vs. 'descriptions' vs. ..., and moreover no way to "escape" text to ensure it's not 'code'.

Re: Supabase MCP can leak your entire SQL database

#79

Post by 12_throw_away »

borromakot wrote: post #64

Simultaneously bullish on LLMs and insanely confused as to why anyone would literally ever use something like a Supabase MCP unless there is some kind of "dev sandbox" credentials that only get access to dev/staging data. And I'm so confused at why anyone seems to phrase prompt engineering as any kind of mitigation at all. Like flabbergasted.

> And I'm so confused at why anyone seems to phrase prompt engineering as any kind of mitigation at all.

Honestly, I kind of hope that this "mitigation" was suggested by someone's copilot or cursor or whatever, rather than an actual paid software engineer.

Edited to add: on reflection, I've worked with many human well-paid engineers who would consider this a solution.

Re: Supabase MCP can leak your entire SQL database

#80

Post by Terr_ »

ollien wrote: post #60
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, 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.

Post reply on HN