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 validation is missing outright. Any authenticated user can read, write, update, and delete data in any tenant's collection. Authentication is the only gate; tenancy is not enforced at all.
- CVE-2026-45831. The
SimpleRBACAuthorizationProvider, from 0.5.0 onward, checks whether a user holds a permission but never checks which tenant, database, or collection it applies to. Hold "read" for one collection and you effectively hold it for every collection. - CVE-2026-45832. All V1 collection-level endpoints pass
Nonefor tenant and database into the authorization layer. An attacker routes their request through the V1 endpoints and the scope check has nothing to evaluate, so it is bypassed entirely — a bypass by choosing the older API surface.
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 onward. A malicious model repository combined with
trust_remote_code=truein the collection config yields arbitrary code execution on the server. This is not an authorization bug — it is remote code execution — but it lands in the same advisory window and the same patch closes it. Do not let the authz story bury it.
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 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 release past the affected 0.4.17+ / 0.5.0+ lines — take the fixed version named in the advisory. These are silent bugs: nothing breaks, data just leaks across tenants.
- Never enable
trust_remote_code. There is no configuration where downloading and executing code from a model repository on your inference host is the boring, correct choice. That closes CVE-2026-45833 by policy, not only by patch level. - Do not expose the vector DB to untrusted clients. It belongs behind your app, on a private network. If it is reachable from the public internet, the authorization bugs are the least of your problems.
- Give the vector DB its own authorization boundary. Application-layer tenant checks are necessary, not sufficient. These CVEs are what happens when the app is the only thing enforcing tenancy and either the app or the DB has a bug. The security playbook has the general version of this rule.
- If you are genuinely multi-tenant, segment at the instance or network level. One instance per tenant, or per trust boundary, removes the entire class: there is no cross-tenant read if there is no shared tenant to cross into. It costs more to run. It is also the design that does not depend on every future release getting the scope check right.
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, and /scanner will tell you whether the
versions in your compose file are on the wrong side of the fix.