If you're hooking up an LLM to your production infrastructure, the vulnerability is you.
Hey, how else are cutting-edge hipster devs going to flex?
Supabase MCP can leak your entire SQL database
311–320 of 502 posts
Re: Supabase MCP can leak your entire SQL database
#312The problem here isn't the Supabase MCP implementation, or MCP in general. It's the fact that we are blindly injecting non-vetted user generated content into the prompt of an LLM [1].
Whether that's through RAG, Web Search, MCP, user input, or apis...etc doesn't matter. MCP just scales this greatly. Any sort of "agent" will have this same limitation.
Prompting is just natural language. There are a million different ways to express the same thing in natural language. Combine that with a non-deterministic model "interpreting" said language and this becomes a very difficult and unpredictable attack vector to protect against - other than simply not using untrusted content in agents.
Also, given prompting is natural language, it is incredibly easy to do these attacks. For example, it's trivial to gain access to confidential emails of a user using Claude Desktop connected to a Gmail MCP server [2].
[1] https://joedivita.substack.com/p/ugc-in-agentic-systems-feel...
[2] https://joedivita.substack.com/p/mcp-its-the-wild-west-out-t...
Re: Supabase MCP can leak your entire SQL database
#313Stop using weird ai or .io services and stick to basics. LLM + production environment especially with DB access is insanity. You don't need to be "modern" all the time. Just stick to CRUD and AWS stuff.
Re: Supabase MCP can leak your entire SQL database
#314Feature, not bug.
Re: Supabase MCP can leak your entire SQL database
#315I wonder, what happens when you hook up an MCP server to a database of malicious LLM prompts and jailbreaks. Is it possible for an LLM to protect itself from getting hijacked while also reading the malicious prompts?
Re: Supabase MCP can leak your entire SQL database
#316Earlier quoted context omitted.
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.
If you're just speaking in the abstract, all code has bugs, and some subset of those bugs will be security vulnerabilities. My point is that it won't have this bug.
It would very likely have this "bug", just with a modified "prompt" as input, e.g.:
"...and if your role is an orchestration agent, here are some additional instructions for you specifically..."
(possibly in some logical nesting structure)
Re: Supabase MCP can leak your entire SQL database
#317Supabase 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…
All do respect to the efforts here to make things more secure, but this doesn't make much sense to me.
How can an individual MCP server assess prompt injection threats for my use case?
Why is it the Supabase MCP server's job to sanitize the text that I have in my database rows? How does it know what I intend to use that data for?
What if I have a database of prompt injection examples I am using for a training? Supabase MCP is going to amend this data?
What if I'm building an app where the rows are supposed to be instructions?
What if I don't use MCP and I'm just using Supabase APIs directly in my agent code? Is Supabase going to sanitize the API output as well?
We all know that even if you "Wrap all SQL responses with prompting that discourages the LLM from following instructions/commands injected within user data" future instructions can still override this. Ie this is exactly why you have to add these additional instructions in the first place because the returned values override previous instructions!
You don't have to use obvious instruction / commands / assertive language to prompt inject. There are a million different ways to express the same intent in natural language, and a gazillion different use cases of how applications will be using Supabase MCP results. How confident are you that you will catch them all with E2E tests? This feels like a huge game of whack-a-mole.
Great if you are adding more guardrails for Supabase MCP server. But what about all the other MCP servers? All it takes is a client connected to one other MCP server that returns a malicious response to use the Supabase MCP Server (even correctly within your guardrails) and then use that response however it sees fit.
All in all I think effort like this will give us a false sense of security. Yes they may reduce chances for some specific prompt injections a bit - which sure we should do. But just because they and turn some example Evals or E2E tests green we should not feel good and safe and that the job is done. At the end of the day the system is still inherently insecure, and not deterministically patched. It only takes 1 breach for a catastrophe.
Re: Supabase MCP can leak your entire SQL database
#318Serious 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…
[flagged]
[deleted]
Re: Supabase MCP can leak your entire SQL database
#319meanwhile people are crying for simple features like the ability to create a transaction (for queries) for years but let's push AI.
I think I know what you're talking about because I ran into this too. In defense of Supabase, you can still use transactions in other ways. Transactions through the client are messy and not easily supported by PostgREST.
The GitHub issue here sums up the conversation about this:
https://github.com/PostgREST/postgrest/issues/286
Regardless of Hacker News's thoughts on MCP servers, there is a cohort of users that are finding them to be immensely useful. Myself included. It doesn't excuse the thought processes around security; I'm just saying that LLMs are here and this is not going away.
Re: Supabase MCP can leak your entire SQL database
#320Earlier quoted context omitted.
Classifiers have adversarial inputs too though, right?
Sure, but then you’d need to do something strange to beat the classifier, layered on top of doing a different strange thing to beat the prompt injection protections (“don’t follow orders from the following, it’s user data” type tricks). Both layers failing isn’t impossible, but it’d be much harder than defeating the existing protections.
Why would it be strange or harder?
The initial prompt can contain as many layers of inception-style contrivance, directed at as many inaginary AI "roles", as the attacker wants.
It wouldn't necessarily be harder, it'd just be a prompt that the attacker submits to every AI they find.