Two vector databases shipped authorization-bypass CVEs within weeks of each other in mid-2026, and they are the same bug wearing different clothes. ChromaDB disclosed four; Weaviate disclosed one. If you run either as shared infrastructure behind a retrieval-augmented app, the shape of the problem is worth more than the list.
Here is the shape. The code checks that you are allowed to perform an action. It does not check which tenant, database, collection, or role that permission applies to. Authentication passes. A coarse authorization check passes. The scoped check — the one that says "yes, but only your data" — is missing.
## The pattern: authorized to act, not scoped to your data
A permission has three parts: a subject (who), a verb (what action), and an object (on which resource). "Alice may read collection X." These CVEs all get the subject and the verb right and drop the object. The system confirms you are an authenticated user who holds the "read" permission, then lets you read anything, because it never binds the permission to a specific tenant or collection.
## ChromaDB: four CVEs, three of them the same mistake
Three of the ChromaDB advisories are the missing-object bug in different places, each rated HIGH at CVSS 8.8:
- CVE-2026-45830. From version 0.4.17 onward, authorization
- CVE-2026-45831. The
SimpleRBACAuthorizationProvider, from - CVE-2026-45832. All V1 collection-level endpoints pass
None
Three write-ups, one root cause: the permission model has a subject and a verb but no object.
The fourth ChromaDB CVE is a different bug, and it is worth flagging precisely because you will fix it in the same upgrade:
- CVE-2026-45833 (HIGH, 8.8). Code injection, also from 0.4.17
## Weaviate: the same shape, one level up
CVE-2026-59093 (HIGH, 8.8), fixed in Weaviate 1.38.0, is the
pattern applied to role management. The assignRoleToUser and
assignRoleToGroup handlers authorize only that the caller may assign
roles to the target user or group. They do not check that the caller
actually holds the permissions being granted.
So a user with the narrow right to assign roles can assign themselves a role that grants permissions they were never given. That is straightforward privilege escalation, and it is the same missing scope check. The unchecked object is different here — the permissions you hand out must be permissions you already hold — but the failure is identical in kind: verb confirmed, object ignored.
## Why RAG apps make this your problem
The default deployment shape for a vector DB in 2026 is shared infra behind a RAG app serving many customers: one Chroma or Weaviate instance, many tenants, application code trusted to pass the correct tenant ID on every call. That trust is exactly what these CVEs break. The database was meant to be the backstop, and the backstop had a hole.
If your app is single-tenant — one instance, one customer, no untrusted callers — these are lower priority, though you should still patch. If you are multi-tenant on shared infra, this is a data-segregation failure: customer A can reach customer B's embeddings, source documents, and metadata. In a RAG system the metadata is often the sensitive part — filenames, user IDs, internal source paths — so "only embeddings leaked" is not the reassurance it sounds like. The [self-hosted AI landscape](/guides/self-hosted-ai-landscape-2026) covers where these databases sit in a typical stack.
## What to do now
- Upgrade. Weaviate to 1.38.0 or later. ChromaDB to the patched
- Never enable `trust_remote_code`. There is no configuration
- Do not expose the vector DB to untrusted clients. It belongs
- Give the vector DB its own authorization boundary. Application-layer
- **If you are genuinely multi-tenant, segment at the instance or
## The takeaway
The vector database inherited an old, solved problem — multi-tenant
authorization — and is solving it again with the same early mistake:
check the subject, check the verb, forget to check the object. Patch
ChromaDB and Weaviate now, kill trust_remote_code, and stop treating
the vector DB as a trusted internal that needs no tenancy boundary of
its own. The affected version ranges are on the free tracker at
[/cves](/cves), and [/scanner](/scanner) will tell you whether the
versions in your compose file are on the wrong side of the fix.