Mechanism: The nearObject operator loaded a vector from the beacon-named collection without authorizing that collection. A caller could place chosen probe vectors in a collection it controlled and use returned distances to reconstruct the protected vector. The fix authorizes the beacon target at the shared vector lookup before loading it.
In Weaviate's GraphQL nearObject path, the system authorized the collection being searched but not the collection named by the beacon before loading that target's vector. The caller could not directly read the protected object or see its properties or vector in the response. Instead, chosen probe vectors and returned distances enabled reconstruction. The reporter recovered a normalized four-dimensional vector to within 5e-9 using eight probe objects.
Why now: Weaviate disclosed the issue with v1.39.3 and identified earlier versions as affected, making the upgrade boundary and mitigation immediately actionable.
Weaviate disclosed the issue alongside v1.39.3, which fixes it, and the post identifies versions below v1.39.3 as affected. Teams can act against a defined version boundary rather than treating this as a hypothetical authorization risk.
Evidence boundary: The supplied public disclosure describes a working reproduction and says Weaviate has no indication of exploitation. It does not establish exploitation in customer environments; CVE assignment is pending.
Weaviate reports no indication that the vulnerability was exploited, and the CVE assignment is pending. The disclosure establishes a demonstrated recovery method and its stated prerequisites; it does not establish exploitation in customer environments.
Implication: Operators with collection-level RBAC in shared clusters should upgrade to v1.39.3 or later.
Shared-cluster operators should update to v1.39.3 or later and review role grants for read_collections and create_data, especially where collection boundaries represent separate teams or applications.
Watch condition: Track the pending CVE assignment and any later changes to affected-version scope or exploitation assessment.
The operational lesson is about authorization placement: checking access at the request resolver is insufficient if a shared lower-level lookup can load a protected object first. Weaviate says the fix applies the check at the shared vector lookup, so API paths using that lookup inherit the control. That is a more durable boundary than relying on each caller to reproduce the same policy correctly.