Weaviate patches nearObject flaw that leaked vectors across collections

What the vulnerability does

A nearObject search takes a beacon that names an existing object, loads that object's vector, and uses it as the search vector. According to Weaviate, the system authorized the collection being searched but did not authorize the collection named in the beacon. When the two differed, the vector of the beacon target was loaded and used even if the caller had no read permission on it.

The company stresses that this is not a direct read of the protected object. The caller never sees the object, its properties or its vector in the response. What the caller does receive is the distance between the protected vector and each object returned by the search. According to Weaviate, those distances are enough to reconstruct the protected vector.

The attack works by filling a collection the user controls with chosen probe vectors, then running a nearObject search against that collection with a beacon pointing into a collection the user does not control. The reporter demonstrated recovery of a normalized four-dimensional vector to within 5e-9 using eight probe objects.

Who is affected and what an attacker needs

Weaviate lists three requirements for the attack:

• The name of the target collection and the UUID of a specific object within it. These are not guessable, but they are often known, for example where an application stores cross-references between collections.
• Permission to read collection definitions, which GraphQL requires in order to expose the collection's fields.
• Permission to create and read data in some other collection, used to hold the probe vectors.

The user does not need read permission on the target collection. Weaviate notes that a direct read of the protected object correctly returns 403, while the same account can retrieve the same vector through the search path.

The issue matters for deployments that rely on RBAC to separate collections within a shared cluster, for instance where several teams or applications share one Weaviate instance and each has read access only to its own collection. Deployments where every user with query access is already trusted with all collection data are not meaningfully affected, according to the company.

The fix and recommended steps

The fix authorizes the beacon target before its vector is loaded. Weaviate says it placed the check at the shared vector lookup rather than in the GraphQL resolver, so every API surface using that lookup is covered by the same check. The CVSS score is Medium, and impacted versions are those below v1.39.3. Weaviate recommends updating to v1.39.3 or later.

Customers running in Weaviate Cloud and Marketplace customers on AWS, Azure and GCP have already been patched, the company says. Weaviate Enterprise Support customers received early notification under embargo, and customer-facing teams are working with Weaviate Dedicated customers to organize version upgrades where appropriate.

For users who cannot upgrade immediately, Weaviate suggests reviewing which roles hold read_collections across all collections, since a user who cannot see a collection's definition cannot query its fields through GraphQL, and narrowing that permission to the collections each role legitimately needs. It also advises reviewing which roles hold create_data on any collection, because the attack requires somewhere to place probe vectors.

Disclosure and what it means for operators

Weaviate says the flaw was discovered and reported by Civitasmass through its Vulnerability Disclosure Program. The report included a complete working reproducer and a precise root cause analysis, which the company says allowed it to confirm and fix the issue quickly. Weaviate states it has no indication that the vulnerability has been exploited, and it will update its post with the CVE ID once issued.

For operators of shared Weaviate clusters that depend on per-collection RBAC, the practical step is to upgrade to v1.39.3 or later and, in the meantime, tighten the read_collections and create_data permissions described above.