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

361–370 of 502 posts

Re: Supabase MCP can leak your entire SQL database

#361

Post by frabcus »

jppope wrote: post #276

Serious question here, not trying to give unwarranted stress to what is no doubt a stressful situation for the supabase team, or trying to create flamebait. This whole thing feels like its obviously a bad idea to have an mcp integration directly to a database abstraction layer (the supabase product as I understand it). Why would the management push for that sort of a feature knowing that it compromises their security…

I think it's a flaw in end-user MCP combined with agentic, where the end-user chooses the combination of tools. Even if the end-user is in an IDE.

The trouble is you can want an MCP server for one reason, flip it on, and a combination of the MCP servers you enabled and that you hadn't thought of suddenly breaks everything.

We need a much more robust deterministic non-LLM layer for joining together LLM capabilities across multiple systems. Or else we're expecting everyone who clicks a button in an MCP store to do extremely complex security reasoning.

Is giving an LLM running in an agentic loop every combination of even these vetted Microsoft MCP servers safe? https://code.visualstudio.com/mcp It seems unlikely.

Re: Supabase MCP can leak your entire SQL database

#362

Post by frabcus »

paddlepop wrote: post #282
raspasov wrote: post #280

Earlier quoted context omitted.

I have no association with Supabase, but in their defense, apart from adding a caution note, there's nothing else that Supabase needs to do, from my perspective. As far as I am concerned, this is not a serious security hole if the human developer exercises common sense and uses widely recognized security precautions while developing their system.

This. As a platform, where do you draw the line between offering a product vs not because a developer could do something stupid with it? edit: keeping in mind the use cases they are pushing in their documentation are for local development

Reflecting on this whole situation, I suspect MCP is fundamentally insecure, in which case Supabase should refuse to implement it.

MCP's goal is to make it easy for end user developers to impulsively wire agentically running LLM chats to multiple tools. That very capability fundamentally causes the problem.

Supabase's response (in the top comment in this post) of making it read-only or trying to wrap with an LLM to detect attacks... Neither of those help the fundamental problem at all. Some other tool probably has write capabilities, and the wrapping isn't reliable.

Re: Supabase MCP can leak your entire SQL database

#363

Post by rvz »

IAmGraydon wrote: post #295
crystal_revenge wrote: post #270

Earlier quoted context omitted.

While I'm far from an expert in security, the time I've spent studying cryptography and cryptosystem design has made me extremely wary of words like "encourage" and "discourage", and "significantly lowered the chances" as a means of achieving security . I'm honestly a bit surprised this is a the public response to actions being taken to increase security around attacks like these. Cryptosystems are not built around "…

Yeah this is insane, and it highlights the fact that fundamental strength of LLMs is also its fundamental weakness: it’s a probabilistic black box, not a deterministic algorithm. By its very nature, you cannot secure a probabilistic black box, and you certainly can’t give it permissions that allow it access to sensitive data. The people working on this have got to realize this, but they’re doing it anyway. I was rece…

> The people working on this have got to realize this, but they’re doing it anyway.

This is the most horrific part of all of this, including using the LLMs on everything and it is industry wide.

> They responded with “it happens but I would say it’s accurate 98% of the time.” They said that with a straight face. The number told me they don’t actually know the hallucination rate, and this is not the kind of work where you want to fuck it up any percent of the time. Hallucinations are incompatible with corporate finance.

Also incompatible with safety critical systems, medical equipment and space technology where LLMs are completely off limits and the mistakes are irreversable.

Re: Supabase MCP can leak your entire SQL database

#364

Post by rvz »

journal wrote: post #180

one day everything private will be leaked and they'll blame it on misconfiguration by someone they can't even point a finger at. some contractor on another continent. how many of you have auth/athr just one `if` away from disaster? we will have a massive cloud leak before agi

We still have exposed MongoDB databases floating all over the internet waiting to be breached.

Now we have a version of this for AI, with MCP servers connected directly to databases waiting to be exfiltrated via prompt injection attacks.

I will be starting the timer for when a massive prompt injection-based data breach because someone exposed their MCP server.

Re: Supabase MCP can leak your entire SQL database

#365

Post by fennecbutt »

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…

Yeeeaaah, imo predefined functions are the only way, no raw access to anything.

Re: Supabase MCP can leak your entire SQL database

#366

Post by NitpickLawyer »

benreesman wrote: post #351
tptacek wrote: post #68

Earlier quoted context omitted.

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…

No it can't ever work for the reasons you mention and others. A security model will evolve with role-based permissions for agents the same as users and service accounts. Supabase is in fact uniquely positioned to push for this because of their good track record on RBAC by default. There is an understandable but "enough already" scramble to get AI into everything, MCP is like HTTP 1.0 or something, the point release /…

I think it's a bit deeper than RBAC. At the core, the problem is that LLMs use the same channel for commands and data, and that's a tough model to solve for security. I don't know if there's a solution yet, but I know there are people looking into it, trying to solve it at lower levels. The "prompts to discourage..." is, like the OP said, just a temporary "mitigation". Better than nothing, but not good at its core.

Re: Supabase MCP can leak your entire SQL database

#367

Post by pegasus »

oulu2006 wrote: post #350
shawn-butler wrote: post #239

Earlier quoted context omitted.

I dunno, with row-level security and proper internal role definition.. why do I need a REST layer?

RLS is the answer here -- then injection attacks are confined to the rows that the user has access to, which is OK. Performance attacks though will degrade the service for all, but at least data integrity will not be compromised.

> injection attacks are confined to the rows that the user has access to, which is OK

Is it? The malicious instructions would have to silently exfiltrate and collect data individually for each user as they access the system, but the end-result wouldn't be much better.

Re: Supabase MCP can leak your entire SQL database

#368

Post by reddalo »

skinner927 wrote: post #327
LambdaComplex wrote: post #216

Earlier quoted context omitted.

Right? "Wrap all SQL responses with prompting that discourages the LLM from following instructions/commands injected within user data?" The entire point of programming is that (barring hardware failure and compiler bugs) the computer will always do exactly what it's told, and now progress apparently looks like having to "discourage" the computer from doing things and hoping that it listens?

Microsoft’s cloud gets hacked multiple times a year, nobody cares. Everyone is connecting everything together. Business people with no security training/context are “writing” integrations with Lego-like services (and now LLMs). Cloudflare hiccups and the Internet crashes. Nobody cares about the things you’re saying anymore (I do!!). Extract more money. Move faster. Outcompete. Fix it later. Just get a bigger cyber in…

>Microsoft’s cloud gets hacked multiple times a year

What cloud? Private SharePoint instances? Accounts? Free Outlook accounts?

Do you have any source on this?

Re: Supabase MCP can leak your entire SQL database

#369

Post by benreesman »

NitpickLawyer wrote: post #366
benreesman wrote: post #351

Earlier quoted context omitted.

No it can't ever work for the reasons you mention and others. A security model will evolve with role-based permissions for agents the same as users and service accounts. Supabase is in fact uniquely positioned to push for this because of their good track record on RBAC by default. There is an understandable but "enough already" scramble to get AI into everything, MCP is like HTTP 1.0 or something, the point release /…

I think it's a bit deeper than RBAC. At the core, the problem is that LLMs use the same channel for commands and data, and that's a tough model to solve for security. I don't know if there's a solution yet, but I know there are people looking into it, trying to solve it at lower levels. The "prompts to discourage..." is, like the OP said, just a temporary "mitigation". Better than nothing, but not good at its core.

The solution is to not give them root. MCP is a number of things but mostly it's "give the LLM root and then there will be very little friction to using our product more and others will bear the cost of the disaster that it is to give a random bot root".
Post reply on HN