What is "MCP?"
[flagged]
Supabase MCP can leak your entire SQL database
341–350 of 502 posts
Re: Supabase MCP can leak your entire SQL database
#342Supabase 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…
> pretty please LLM don’t leak user data
Re: Supabase MCP can leak your entire SQL database
#343I have been reading HN for years. The exploits used to be so clever and incredible feats of engineering. LLM exploits are the equivalent of "write a prompt that can trick a toddler."
And the discussion used to be informative or offering perspective, and not as reactionary. I'm legitimately disappointed in the discourse on this thread. And I'm not at all bullish on LLMs.
That's because we're watching the equivalent of handing many toddlers a blowtorch. If you don't freak out in that scenario, what could possibly move you?
Re: Supabase MCP can leak your entire SQL database
#344Earlier quoted context omitted.
The main problem seems to me to be related to the ancient problem of escape sequences and that has never really been solved. Don't mix code (instructions) and data in a single stream. If you do sooner or later someone will find a way to make data look like code.
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,…
> There is no natural separation between code and data. They are the same thing.
Seems there is a pretty clear distinction in the context of prepared statements.
Re: Supabase MCP can leak your entire SQL database
#345Am I not crazy to think it's impossible to safeguard your data with open access provided to an LLM? I know you want to give users the flexibility of questioning the data with natural language but for god sake, please have LLM operate on a view for the user-specifuc data instead. Why won't people do this?
Re: Supabase MCP can leak your entire SQL database
#346Earlier quoted context omitted.
I don't understand why people get hung up on non-determinism or statistics. But most security people understand that there is no one single defense against vulnerabilities. Disastrous seems like a strong word in my opinion. All of medicine runs on non-deterministic statistical tests and it would be hard to argue they haven't improved human health over the last few centuries. All human intelligence, including military…
SQL injection and XSS both have fixes that are 100% guaranteed to work against every possible attack. If you make a mistake in applying those fixes, you will have a security hole. When you spot that hole you can close it up and now you are back to 100% protection. You can't get that from defenses that use AI models trained on examples.
I am actually asking this question in good faith: are we certain that there's no way to write a useful AI agent that's perfectly defended against injection just like SQL injection is a solved problem?
Is there potentially a way to implement out-of-band signaling in the LLM world, just as we have in telephones (i.e. to prevent phreaking) and SQL (i.e. to prevent SQL injection)? Is there any active research in this area?
We've built ways to demarcate memory as executable or not to effectively transform something in-band (RAM storing instructions and data) to out of band. Could we not do the same with LLMs?
We've got a start by separating the system prompt and the user prompt. Is there another step further we could go that would treat the "unsafe" data differently than the safe data, in a very similar way that we do with SQL queries?
If this isn't an active area of research, I'd bet there's a lot of money to be made waiting to see who gets into it first and starts making successful demos…
Re: Supabase MCP can leak your entire SQL database
#347Earlier quoted context omitted.
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…
[flagged]
> Capitalist incentivized
And what's the alternative here?
Re: Supabase MCP can leak your entire SQL database
#348Earlier quoted context omitted.
Except without any authentication and authorization layer. Remember, the S in MCP is for "security." Also, you can totally have an MCP for a database that doesn't provide any SQL functionality. It might not be as flexible or useful, but you can still constrain it by design.
No part of what happened in this bug report has anything to do with authentication and authorization. These developers are using the MCP equivalent of a `psql` prompt. They assume full access. I think this "S in MCP" stuff is a really handy indicator for when people have missed the underlying security issue, and substituted some superficial thing instead.
What do you think the underlying security issue is? I see at least two of them.
Also, psql doesn’t automatically provide its caller with full access to a database server—or any access at all, for that matter. You still have to authenticate yourself somehow, even if you’re it’s just local peer authentication.
If this MCP server is running with your own credentials, and your credentials give you full access to the database, then the fact that the service can be used to make arbitrary queries to the database is not remarkable: It’s literally your agent. We’d call it a bug, not necessarily a security risk. However, if it’s running with credentials that aren’t yours that provide full access, and your own credentials don’t, then this bug becomes a privilege escalation attack vector. It’s a classic confused deputy problem.
The situation with MCP today reminds me of the 1990s when everyone ran open SMTP servers. It wasn’t a big deal at first, but once the abuse became bad enough, we had to do something about it. SMTP didn’t have any security facilities in it, so we had to experiment with patchy solutions and ended up with a in-band solution involving the AUTH extension and SASL.
Something similar is going on with MCP right now. It doesn’t offer an in-band generic authentication support (hence the missing “S”). There’s no way I’m aware of to pass arbitrary application credentials to an MCP server so it can act as a database query agent that can do only as much as your credentials permit. There seems to be limited support for bearer tokens and OAuth, but neither of those directly translate to database credentials.
Re: Supabase MCP can leak your entire SQL database
#349Re: Supabase MCP can leak your entire SQL database
#350Earlier quoted context omitted.
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 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.