What Happened
Weaviate v1.39.3 fixes a high-severity credential disclosure vulnerability in its Google-backed embedding and generation modules. Earlier versions could send a configured Google API key or OAuth token to an attacker-controlled host if an unvalidated apiEndpoint was supplied. An attacker could set that endpoint through collection configuration with schema-write access or, for generative-google, through a GraphQL query with ordinary read access to a configured collection. Weaviate reports no indication of exploitation; a CVE had not yet been assigned when it announced the fix. [1]
Why It Matters to Businesses
RAG applications often connect search infrastructure to external embedding and generation services. This case shows why a query-level integration setting must be treated as a security boundary: read permission can become a path to credential disclosure when a request can redirect an authenticated outbound call. Teams using Weaviate should upgrade to v1.39.3 or later; Weaviate says its Cloud and Marketplace customers have been patched. [1]
Kimbodo Engineering Perspective
The design lesson applies beyond one vector database: keep service endpoints and credentials under operator control, rather than allowing application users to choose where credential-bearing requests go. Collection-level access controls still matter, but they do not substitute for validating outbound destinations. [1]
How We Would Implement It
- Inventory Weaviate deployments using text2vec-google, multi2vec-google, or generative-google, and upgrade affected instances to v1.39.3 or later. [1]
- Remove unneeded schema-write permissions and restrict direct query access to collections with configured external-service credentials.
- Set approved service endpoints in deployment configuration; validate or reject endpoint overrides at application and infrastructure boundaries.
- Constrain outbound network access to approved provider hosts, and alert on unexpected destination changes from search services.
Risks, Costs and Security
Upgrades and tighter endpoint controls require compatibility testing, particularly where applications intentionally use custom provider endpoints. Egress restrictions add operational work but provide a second barrier if request validation fails. Where an affected deployment allowed untrusted users to submit endpoint overrides, review access and outbound-request logs and assess whether configured credentials should be rotated; the announced issue is a potential disclosure path, not evidence that a particular deployment was compromised. [1]
Where Kimbodo Comes In
Kimbodo builds and operates this in production for businesses — see our RAG Development Services practice, or Estimate My RAG System.
