The MCP hype is real, but top of HN?
That's like saying that if anyone can submit random queries to a Postgres database with full access, it can leak the database.
That's like middle-school-level SQL trivia.
Supabase MCP can leak your entire SQL database
201–210 of 502 posts
Re: Supabase MCP can leak your entire SQL database
#202The MCP hype is real, but top of HN? That's like saying that if anyone can submit random queries to a Postgres database with full access, it can leak the database. That's like middle-school-level SQL trivia.
Yes, but some lessons need to be re-learned over and over so it's seems totally fine that this is here considering how MCP is being promoted as the "integration to rule them all".
Re: Supabase MCP can leak your entire SQL database
#203Earlier quoted context omitted.
That "problem" remains unsolved because it's actually a fundamental aspect of reality. There is no natural separation between code and data. They are the same thing. What we call code, and what we call data, is just a question of convenience. For example, when editing or copying WMF files, it's convenient to think of them as data (mix of raster and vector graphics) - however, at least in the original implementation,…
Well, that's why REST api's exist. You don't expose your database to your clients. You put a layer like REST to help with authorization. But everyone needs to have an MCP server now. So Supabase implements one, without that proper authorization layer which knows the business logic, and voila. It's exposed. Code _is_ the security layer that sits between database and different systems.
I was thinking the same thing.
Who, except for a total naive beginner, exposes a database directly to an LLM that accepts public input, of all things?
Re: Supabase MCP can leak your entire SQL database
#204The MCP hype is real, but top of HN? That's like saying that if anyone can submit random queries to a Postgres database with full access, it can leak the database. That's like middle-school-level SQL trivia.
Yes, but some lessons need to be re-learned over and over so it's seems totally fine that this is here considering how MCP is being promoted as the "integration to rule them all".
MCP is the new GraphQL.
Re: Supabase MCP can leak your entire SQL database
#205If you're hooking up an LLM to your production infrastructure, the vulnerability is you.
This should be the one-line summary at the top of the article.
Re: Supabase MCP can leak your entire SQL database
#206Low hanging fruit this MCP threat business! The security folk must love all this easy traffic and probably lots of consulting work. LLMs are just insecure. They are the most easily confused deputy.
Re: Supabase MCP can leak your entire SQL database
#207Earlier quoted context omitted.
You can have the MCP talking directly to the database if you want! You just can't have it in this configuration of a single context that both has all the tool calls and direct access to untrusted data.
Whichever model/agent is coordinating between other agents/contexts can itself be corrupted to behave unexpectedly. Any model in the chain can be. The only reasonable safeguard is to firewall your data from models via something like permissions/APIs/etc.
Exactly. The database level RLS has to be honoured even by the model. Let the "guard" model run at non-escalated level and when it fails to read privileged data, let it interpret the permission denied and have a workflow to involve humans (to review and allow retry by explicit input of necessary credentials etc).
Re: Supabase MCP can leak your entire SQL database
#208I'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…
That's a different issue - it's two things: - exposure to untrusted input - the ability to run tools that can cause damage I designed the trifecta framing to cover the data exfiltration case because the "don't let malicious instructions trigger damaging tools" thing is a whole lot easier for people to understand. Meanwhile the data exfiltration attacks kept on showing up in dozens of different production systems: htt…
I wonder why the original requestor isn't tied to the RBAC access, rather than the tool.
For example, in a database I know both the account that is logged and the OS name of the person using the account. Why would the RBAC not be tied by both? I guess I don't understand why anyone would give access to an agent that has anything but the most limited of access.
Re: Supabase MCP can leak your entire SQL database
#209Supabase 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…
No it can't work. Not in general. And MCP is "in general". Whereas custom coded tool use might be secure on a case by case basis if the coder knows what they are doing.
Re: Supabase MCP can leak your entire SQL database
#210Maybe I'm getting too old but the core problem here seems to be with `execute_sql` as a tool call! When I learned database design back in the early 2000s one of the essential concepts was a stored procedure which anticipated this problem back when we weren't entirely sure how much we could trust the application layer (which was increasingly a webpage). The idea, which has long since disappeared (for very good and pra…
If the LLM has access to executing only specific stored procedures (I assume modern DBMSs can achieve that granularity, but I haven't checked), then the problem mostly (entirely?) disappears.
It limits the utility of the LLM, as it cannot answer any question one can think of. From one perspective, it's just a glorified REST-like helper for stored procedures. But it should be secure.