DEV Community: Dmitry Maranik

I source-reviewed 200+ self-hosted AI tools for tenant isolation. 78 leaked across tenants.

Dmitry Maranik — Wed, 15 Jul 2026 14:41:00 +0000

The same isolation flaw, the un-retrofitted read sibling, in 78 of 200+ multi-tenant AI and SaaS products. The pattern, the fixes that shipped, and how to check your own.

Every team building on top of LLMs eventually ships the same feature: workspaces. Tenants, teams, projects, organizations, whatever you call them, the promise is identical. Your knowledge base, your chat history, your documents, walled off from everyone else on the same instance.

That wall is the one thing a multi-tenant product cannot get wrong. So over the past few months I went looking, systematically, for where it cracks.

I source-reviewed 200+ multi-tenant AI and SaaS products for one specific class of bug, and confirmed cross-tenant data exposure in 78 of them: one tenant able to read (and in some cases modify or delete) another tenant's data. That comes to 84 findings across 78 products, with 31 now filed as GitHub Security Advisories. Almost all of them are the same mistake, and it lives in the read endpoints.

This post explains that mistake, names the ones that are already fixed, and points to the live list of the rest. Everything still unnamed stays that way until its fix ships. I'm not going to hand attackers a live target before users are protected.

How I tested

Two tiers, because 200+ deep labs isn't something one person does, but 200+ source reviews is.

The sweep (200+ products). For each candidate I read the code for one pattern: an authorization check that's enforced on the write path but skipped on a neighboring read. Most products either don't have the bug, aren't actually multi-tenant in their open-source edition, or have already retrofitted every sibling. Those are the majority, and they're the denominator that makes the 78 mean something.

The confirmation (the findings). When the source review flagged a real gap, I confirmed it for real:

Stood up a clean, self-hosted instance (Docker, on my own hardware).
Created two tenants, A and B, with synthetic accounts and synthetic canary data. No real users, no production systems, ever.
Reproduced the cross-tenant read, modify, or delete with Sectum AI, an open-source multi-tenant isolation verifier, and confirmed it against database ground truth.
Captured a signed (RFC-3161-timestamped) evidence pack and reported it privately to the maintainer under coordinated disclosure (90-day hold), usually with the fix attached.

That last step is why the scoreboard below is mostly blank. Most of the 84 findings are still under coordinated disclosure. The maintainers have been told and are shipping fixes, so I name only the ones that are already public and aggregate the rest. The full current list, and each advisory as it publishes, lives at sectum.ai/research.

The pattern: writes are guarded, reads are not

What made the sweep almost mechanical is that the same shape kept repeating. The write path was correctly scoped to the tenant, and the read path right next to it was not.

A developer adds "delete this item" and remembers to check ownership: does this item belong to the caller's tenant? Good. Then someone adds "view this item" or "list this item's embeddings," and the check never gets copied over. The list/get/search endpoint fetches by a raw ID with no tenant filter. The IDs are often sequential integers or otherwise guessable, so "view item 5" happily returns another tenant's item 5.

I started calling these un-retrofitted read siblings. Once you've seen one, you grep for the rest: find the endpoint that checks ownership, then look at the neighbors that don't. Across 78 products it was the same shape almost every time. This isn't 84 unrelated bugs. It's one bug, 84 times.

There's a second, nastier variant. The check runs, but on the wrong thing. The handler authorizes the path you supplied rather than the object you asked for. You pass your own workspace's ID, which you're allowed to touch, along with a victim's object ID, and the permission check and the object lookup disagree about whose data this is. The two most damaging classes I confirmed were an embedding-vector read (raw RAG vectors, which can partially reconstruct the source text) and a connector re-index that exfiltrates another tenant's content using the victim's own stored OAuth token.

The ones already fixed

Five are public because the maintainers shipped a fix. The teams that moved fastest deserve the credit:

Tool	Issue (class)	Status
SurfSense	Cross-tenant connector re-index to exfiltrate another tenant's GitHub/Notion content using their stored credentials	✅ Fixed: PR #1503 merged
AnythingLLM	Embed widget exposed to anonymous origins by default	✅ Fixed: CVE-2025-63390, PR #5759 merged
Baserow	Cross-workspace disclosure of a field's values by serial ID	✅ Fixed and deployed: PR #5613
aideepin	Cross-user read of another user's RAG chunk text, embedding vectors, and document text by ID	✅ Fixed: PR #105 merged
Flagsmith	Cross-project read of another project's multivariate-flag values; the fix swept four sibling nested viewsets	✅ Fixed: PR #7945 merged
79 more	RAG and document leaks, credential-store IDORs, cross-workspace read and tamper, up to Critical severity	⏳ Under coordinated disclosure, named at sectum.ai/research as fixes ship

Who passed

Plenty of products held. A few are worth naming, because credit is due. Several had clearly audited the whole bug class after a single report, which is the right way to respond.

Isolation held on current releases: Open WebUI, Langfuse, LibreChat, Outline, PraisonAI, Onyx, LangWatch, Khoj. A few had cross-tenant CVEs in older versions; on current releases they're clean.
Not multi-tenant in the open-source edition (no cross-tenant surface to leak): Flowise, Mem0, MaxKB, vLLM. Their workspace isolation is an enterprise feature or an explicitly documented shared-by-design behavior. Worth knowing if you self-host them assuming a wall you don't actually have.

What this means if you're building on AI

Three takeaways, in order of how often they bit.

Authorize reads like you authorize writes. The list/get/search endpoint is not "lower risk" than delete. It's the exfiltration endpoint. When you add an ownership check, grep for every sibling that touches the same object and give them the same check. Better still, enforce tenant scoping at a layer the individual handler can't forget: a query interceptor, a row-level policy, a middleware. Then isolation is the default instead of something each endpoint opts into.
Treat embeddings and cache keys as tenant data. Some of these leaks weren't documents at all. They were RAG vectors and response caches whose keys forgot to include the tenant. If A and B can land in the same cache bucket or read each other's vectors, that is a data leak.
If you self-host, verify the isolation you're assuming. Several popular tools are single-tenant, or shared by design, in their open-source edition. That's a fine design. But if you're putting multiple customers on one instance expecting a wall, check that the wall exists.

On disclosure

Everything here was tested on isolated, self-hosted instances with synthetic accounts and synthetic data. Nothing touched a third-party or production system. Every finding went to the maintainer privately first, with a 90-day hold and an offer to write the fix. The handful named here are public because they're fixed or have an open fix PR. The rest stay unnamed until the people who maintain them have shipped. The full current list is kept up to date at sectum.ai/research, where each advisory appears as it publishes.

If you maintain one of the products still under embargo and want to coordinate timing or a CVE, reach me through sectum.ai/research.

Try it yourself

The checks I ran are open source. Sectum AI stands up two tenants, runs the cross-tenant battery (IDOR/BOLA, RAG entity-bleed, cache contamination, erasure), and emits a signed evidence pack you can hand to an auditor, without having to trust the vendor's word that isolation works. If you're shipping multi-tenant AI, point it at a staging instance before someone else points something less friendly at production.

Found and verified with Sectum AI. The full current disclosure list, updated as each advisory publishes, is at sectum.ai/research.

I Lint-Ran 4 Public Supabase Apps. They All Leak Rows.

Dmitry Maranik — Tue, 26 May 2026 17:44:07 +0000

I ran pgrls — an open-source
Postgres Row-Level Security linter I maintain — against four public
Supabase-flavored repos. Three of them are first-party examples or
official partners:

Repo	Who maintains it	Findings
`supabase/storage-api`	Supabase	2
`vercel/nextjs-subscription-payments`	Vercel × Stripe × Supabase	30
`supabase/supabase/examples/slack-clone`	Supabase	49
`supabase/supabase/examples/todo-list`	Supabase	15
Total		96

Zero false positives across the 96 findings. Every flagged
policy is either a real bug or a known-acceptable trade-off worth
surfacing for review.

What "correct" looks like first

Supabase's own RLS guide
is direct about it. Under
"Specify roles in your policies" (in the RLS-performance
recommendations section) the docs say:

Always use the Role of inside your policies, specified by the
TO operator.

And demonstrate the pattern for anonymous access as a separate,
explicit policy, not a default-on side effect:

create policy "Public profiles are visible to everyone."
    on profiles for select
    to anon                          -- explicit anon allow
    using ( true );

The translation in practice:

-- Logged-in users read messages:
CREATE POLICY "auth read" ON public.messages
    FOR SELECT TO authenticated      -- explicit role binding
    USING (true);

-- Anonymous reads, only if you actually want them:
CREATE POLICY "anon read" ON public.messages
    FOR SELECT TO anon               -- separate, intentional
    USING (is_public = true);

The standard isn't load-bearing because it's elegant — it's
load-bearing because the alternative ships rows to anonymous
clients by accident. A policy without an explicit TO clause
defaults to TO public, which means every role on the database,
including anon. The 96 findings are what falls out when four
sample apps are measured against this single principle and the
small handful of related ones (FORCE the owner role, scope by
auth.uid() not current_user, wrap auth calls for the planner).

The four rules that fire on every repo

Across all four codebases, the same four rules appear:

Rule	What it catches	Why it's everywhere
SEC002	RLS enabled but `FORCE ROW LEVEL SECURITY` missing	The owner role (typically the migration role) bypasses RLS until you opt into `FORCE`. Default-off in Postgres.
SEC003	Permissive policy with no `TO <role>` clause	Defaults to `TO public`, which reaches anonymous (`anon`) connections by accident.
SEC007	All policies on a table are permissive	A single typo in `RESTRICTIVE` (or forgetting it entirely) collapses the OR-chain to "anyone matching ANY policy passes."
SEC016	`service_role` has `BYPASSRLS`	True by design on Supabase, but surfaced so an operator can audit the blast radius before granting it to anything else.

These four are the default-Supabase posture findings. Nothing
exotic. Every Supabase project has them on day one.

What the deviation looks like in practice

The densest single finding is SEC003 in slack-clone — 13
instances of the same shape. From
examples/slack-clone/nextjs-slack-clone/full-schema.sql#L87:

create policy "Allow logged-in read access" on public.messages
    for select
    using ( auth.role() = 'authenticated' );

No TO <role> clause, so the policy defaults to TO public. The
predicate (auth.role() = 'authenticated') catches it at runtime
today, but the policy still runs for anon connections — any
later predicate change (a misplaced OR, a NULL-tolerant
IS DISTINCT FROM, the SEC004 auth_func() IS NULL OR … shape)
immediately leaks every message to unauthenticated callers.

The fix is moving the role gate from the predicate into the TO
clause, where it belongs:

CREATE POLICY "Allow logged-in read access" ON public.messages
    FOR SELECT TO authenticated         -- ← gate here, not in USING
    USING (true);

13 policies in slack-clone follow the broken shape. 5 do in
nextjs-subscription-payments. 4 in todo-list. Same fix line each
time.

The performance footgun: PERF001 in 19 of the 4 repos

USING (owner_id = auth.uid())          -- re-evaluates per row
USING (owner_id = (SELECT auth.uid())) -- evaluated once per query

Supabase's own RLS docs recommend the
(SELECT auth.uid()) wrap
for performance reasons — a row-by-row auth.uid() call is
quadratic-ish on a large SELECT, while the wrapped form lets the
planner evaluate once. 19 policies across the four repos miss
this wrap. pgrls flags it as PERF001 and auto-fixes it.

What 0 false positives means

I don't think most lint tools earn the "0 false positives" claim
honestly. Two things make pgrls's count credible:

It analyzes the live database catalog, not source files. The policy that fires is the policy Postgres will actually enforce — not a guess at what the migration text resolves to.
Each rule is severity-rated and configurable. "False positive" in the strictest sense means "the rule flags something that's not a bug." Across these 96 findings, every flagged policy either is a bug or has a known-acceptable trade-off (e.g., service_role's BYPASSRLS on Supabase is intentional — but pgrls.toml's allowlist lets the operator mark it as acknowledged rather than silently ignored).

If a finding doesn't apply to your project, it's an allowlist
entry, not a bug in the linter:

[lint.rules.SEC016]
allowlist = ["service_role"]

Try it against your own schema

pip install pgrls
export DATABASE_URL='postgres://…'
pgrls lint --schemas public

If you're on Supabase, the dev workflow is:

supabase start
DATABASE_URL=$(supabase status -o env | grep DB_URL | cut -d= -f2)
pgrls lint --schemas public

Or as a one-step GitHub Action:

- uses: pgrls/pgrls-action@v1
  with:
    database-url: ${{ secrets.SUPABASE_DB_URL }}
    schemas: public

If you share a (sanitized) policy that pgrls misses or
misclassifies, the catalog grows from real schemas, not synthetic
test fixtures. Drop a thread at
github.com/pgrls/pgrls/discussions.

47 rules total, 12 with mechanical auto-fixes. MIT,
framework-agnostic, runs against any Postgres 15+. Source:
github.com/pgrls/pgrls. Docs:
pgrls.github.io/pgrls-docs.