CVE-2026-85693: Chatbot UI Leaks Private Files, and RLS Was On the Whole Time

On 2026-06-12 a researcher opened an issue on a Next.js project with 33.4k stars, explaining that any logged-in user could read any other user's private file content. The issue is still open. It has zero comments.

Twelve weeks later the report became CVE-2026-85693. The interesting part isn't that a project shipped an access-control bug. It's what the database was doing the entire time.

What the route actually does

The vulnerable file is app/api/retrieval/retrieve/route.ts. Here is the shape of it, trimmed to the parts that matter:

const { userInput, fileIds, embeddingsProvider, sourceCount } = json

const uniqueFileIds = [...new Set(fileIds)]

const supabaseAdmin = createClient<Database>(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_ROLE_KEY!
)

const profile = await getServerProfile()

// ...profile is used to pick an OpenAI or Azure API key, and for nothing else

await supabaseAdmin.rpc("match_file_items_openai", {
  query_embedding: openaiEmbedding,
  match_count: sourceCount,
  file_ids: uniqueFileIds
})

Read the path fileIds takes. It arrives in the POST body, gets deduplicated, and goes into the SQL predicate. Nothing in between asks whether the caller owns those files.

getServerProfile() looks reassuring and isn't. It proves you're logged in, then its result is used to choose which API key to embed with. It's authentication standing exactly where an authorization check should be.

The Postgres function doesn't save it either. match_file_items_openai filters on where (file_id = ANY(file_ids)) with no user_id predicate, and it isn't declared security definer.

RLS was on. That's the part worth sitting with.

The obvious assumption is that this project forgot to turn on Row Level Security. It didn't.

Here's the migration that creates the table the leak reads from:

create table file_items (
  id UUID PRIMARY KEY DEFAULT uuid_generate_v4(),
  file_id UUID NOT NULL REFERENCES files(id) ON DELETE CASCADE,
  user_id UUID NOT NULL REFERENCES auth.users(id) ON DELETE CASCADE,
  sharing TEXT NOT NULL DEFAULT 'private',
  content TEXT NOT NULL,
  ...
);

ALTER TABLE file_items ENABLE ROW LEVEL SECURITY;

CREATE POLICY "Allow full access to own file items"
    ON file_items
    USING (user_id = auth.uid())
    WITH CHECK (user_id = auth.uid());

The ownership column exists. RLS is enabled. The policy is the textbook one. Rows default to private.

So every piece of the defense was built, correctly, and then one line in one route opted out of all of it. That's a different bug from the one people usually write about, and it's a more uncomfortable one, because "did you remember to turn on RLS?" is a question you can answer yes to and still be exposed.

Why no scanner is going to tell you

This is the part we found most surprising, and it's checkable in one command.

The advisory, GHSA-258v-w87q-m5c9, is marked unreviewed, and unreviewed GitHub advisories aren't exported to OSV. Ask osv.dev about it and you get nothing:

$ curl -s https://api.osv.dev/v1/vulns/CVE-2026-85693
{"code":5,"message":"Vulnerability not found"}

$ curl -s https://api.osv.dev/v1/vulns/GHSA-258v-w87q-m5c9
{"code":5,"message":"Vulnerability not found"}

There's a second reason it can't reach you. Chatbot UI is an application you clone and deploy, not a package you install, so there's no dependency entry in anyone's lockfile to match against. Between the two, the normal safety net simply isn't under this one. npm audit stays quiet. Dependabot stays quiet. If you deployed this, the only way you find out is by reading about it.

It is still live

Not "awaiting a release." Unfixed.

The CVE names commit 81328b6 as the last affected version. On 2026-09-18 that is also the tip of the default branch:

$ git ls-remote https://github.com/mckaywrigley/chatbot-ui.git HEAD refs/heads/main
81328b61d2a4ab597a7a057be70e785cf756d9f8    HEAD
81328b61d2a4ab597a7a057be70e785cf756d9f8    refs/heads/main

No commit of any kind has landed since the commit the advisory points at. The repository isn't archived, and it has no security policy, which is presumably why the reporter filed a public issue rather than a private report. It also has 9.4k forks, and every one of them carries this route.

The five-minute check on your own app

You almost certainly aren't running this project. The pattern is the part that travels.

What this does and doesn't say about AI-built apps

It would be tidy to call this a story about AI-generated code. It isn't, and the dates make that clear: the migrations are from early 2024 and this is a hand-written project by a named developer. Nobody generated it.

The reason it matters to anyone auditing an app they didn't fully write is narrower, and more useful. The service-role key is the standard escape hatch when RLS blocks a server-side query. It's the thing you reach for when a query returns an empty array and you need it to return rows. Reaching for it is easy, and the ownership check it silently replaced is invisible, because nothing errors and nothing warns you.

An experienced developer did that here, in public, in a project 33.4k people starred. Generated code inherits the same trap, and inherits it without anyone having weighed the tradeoff at all.

If you want the mechanics of which client runs which policy, the Supabase request path diagram walks through the three states a query can be in.