Weaviate v1.39.3 fixes high severity credential leak in Google modules

What the vulnerability does

The issue affects three Weaviate modules: text2vec-google, multi2vec-google and generative-google. They let users set the host for outbound Vertex AI and Gemini requests through an apiEndpoint configuration value. According to Weaviate, that value was written directly into the host portion of the request URL without validation, and the operator's configured Google credential was attached to the request as a bearer token regardless of where the request went.

A user who can influence apiEndpoint could therefore make Weaviate deliver that credential to a host of their choosing. A CVE has been requested from MITRE and is pending assignment. Weaviate says it will update its post once the ID is issued.

Two paths, one more serious

Weaviate describes two ways to set the value:

• Collection configuration. Setting moduleConfig.text2vec-google.apiEndpoint, or the equivalent for the other two modules, when creating or updating a collection. Validation at this layer only checked that a project ID was present. This path requires schema-write privileges.
• GraphQL query parameter. The generative-google module accepted apiEndpoint as an inline parameter on a generative query, and the per-query value overrode the collection default. This path requires only ordinary read access to a collection already configured to use generative-google, with no schema-write privilege and no change to stored configuration.

Weaviate calls the second path the more serious one and the main reason for the severity rating.

The exposed credential depends on how a deployment authenticates to Google. With a static API key, that key is disclosed. With USE_GOOGLE_AUTH enabled, the disclosed value is a live OAuth access token scoped to cloud-platform, which Weaviate says is broad enough to reach most Google Cloud APIs available to the underlying service account. The company notes this is the documented way to run Vertex AI vectorization with Google Cloud Application Default Credentials, and the usual setup for GKE deployments using Workload Identity.

Why earlier protections did not apply

Weaviate says this is a distinct code path from base URL validation added in earlier releases. That work hardened the endpoint fields of many other model providers, but those fields are named baseURL. The Google modules use apiEndpoint, which was not covered.

The related dial-time protection is also opt-in via MODULES_VALIDATE_BASE_URL and blocks only loopback, private and link-local addresses. It therefore does not stop a credential from being sent to an attacker-controlled host on the public internet, according to Weaviate.

The fix extends endpoint validation to the apiEndpoint field in all three Google modules, at both the configuration-validation layer and the GraphQL query-parameter layer.

Who is affected and what to do

Versions of Weaviate earlier than v1.39.3 are impacted. Weaviate recommends updating to v1.39.3 or later. Customers running in Weaviate Cloud, and Marketplace customers on AWS, Azure and GCP, have been patched seamlessly. Enterprise Support customers received early notification under embargo, and Weaviate says its customer-facing teams are working with Weaviate Dedicated customers to organize version upgrades where appropriate.

For those who cannot upgrade immediately, Weaviate suggests disabling the affected modules by removing text2vec-google, multi2vec-google and generative-google from the "enabled_modules" flag. Where the modules are required, it recommends restricting schema-write and query access to collections configured to use them, and scoping the Vertex AI service account as narrowly as the workload allows instead of relying on a broad cloud-platform scope.

The vulnerability was reported by independent security researcher Syed Anas Mohiuddin through Weaviate's Vulnerability Disclosure Program. The company thanked him for the detail and care of the report.