CVE-2026-11500: 
Wolfi vulnerability analysis and mitigation

CVE-2026-11500 is an authorization bypass vulnerability in Weaviate's Static API Key Handler, affecting all versions up to and including 1.37.7. The flaw resides in the validateConfig function within usecases/auth/authentication/apikey/client.go, where duplicate static API keys are not rejected during configuration validation, allowing a single shared token to authenticate as different users depending on key list ordering. It was reported by community researcher 3em0 via GitHub issue #11392 on May 21, 2026, and publicly disclosed on June 8, 2026. The vulnerability carries a CVSS v3.1 base score of 5.0 (Medium) and a CVSS v4.0 base score of 1.3 (Low) (Github Advisory, Feedly).

The root cause is classified as CWE-285 (Improper Authorization) and CWE-639 (Authorization Bypass Through User-Controlled Key). Weaviate's static API key authentication hashes the presented bearer token using SHA-256 and returns the index of the first matching configured key; that index is then used to resolve the associated username (principal). The validateConfig function checked for empty keys and length mismatches but did not enforce uniqueness of AllowedKeys values, so an operator could configure the same raw key string bound to two different users. An attacker who possesses a shared token is authenticated as whichever user appears first in the duplicate key list — if that first entry is a high-privilege account, the token effectively grants elevated access regardless of the operator's intent. Exploitation requires the attacker to already hold a valid (low-privilege) API key and the target deployment to have been misconfigured with duplicate keys (GitHub Issue, GitHub Commit).

A low-privileged authenticated attacker can be resolved as a higher-privileged user (e.g., admin) when duplicate static API keys are present in the configuration, enabling unauthorized schema creation, data reads, data modification, and data deletion within the Weaviate vector database. The confidentiality, integrity, and availability of stored vector objects and associated metadata are all at risk. Because Weaviate is commonly used as a backend for AI/RAG applications, unauthorized access could expose sensitive embedded documents or allow an attacker to corrupt or delete vector collections, disrupting dependent applications (Github Advisory, GitHub Issue).

1. Identify a vulnerable deployment: Locate a Weaviate instance (version ≤ 1.37.7) with static API key authentication enabled (AUTHENTICATION_APIKEY_ENABLED=true). Confirm the instance is reachable via HTTP/HTTPS on port 8080.
2. Confirm duplicate key misconfiguration: Determine (e.g., through configuration disclosure, insider knowledge, or trial-and-error) that the same API key value appears more than once in AUTHENTICATION_APIKEY_ALLOWED_KEYS, bound to different users — with a high-privilege user (e.g., admin) listed first.
3. Obtain the shared API key: Acquire the shared static API key value. In a misconfigured environment, this key may be distributed to low-privilege users who are unaware it also maps to an admin account.
4. Send a privileged request: Use the shared token as a Bearer token in an HTTP request targeting a privileged endpoint, such as schema creation:

   curl -X POST http://<target>:8080/v1/schema \
     -H 'Authorization: Bearer <shared-static-token>' \
     -H 'Content-Type: application/json' \
     --data-binary '{"class":"MaliciousCollection","vectorizer":"none"}'

5. Achieve privilege escalation: Because the first matching key entry resolves to the admin user, the request is authorized as admin, returning HTTP 200 and granting full schema/data management capabilities (GitHub Issue).

• Logs: Weaviate access logs showing schema creation, data modification, or deletion requests authenticated with a token that should only have read-level access; requests from a known low-privilege API key performing admin-level operations (e.g., POST /v1/schema, DELETE /v1/schema/{className}).
• Configuration: Presence of duplicate values in the AUTHENTICATION_APIKEY_ALLOWED_KEYS environment variable or equivalent configuration file — the same raw key string appearing more than once, mapped to different usernames.
• Behavioral: Unexpected collections or schema changes appearing in Weaviate that cannot be attributed to known admin users; audit logs (if enabled) showing admin-level actions attributed to a username that should only have read permissions.

Upgrade Weaviate to version 1.38.0-rc.0 or later, which includes patch 40f2cc32279f0f8a51016c3c6870a2c0c808e6c0 that adds a uniqueness check in validateConfig — startup will now fail with the error "keys must be unique" if duplicate AllowedKeys values are detected (GitHub Commit, GitHub Release). As an immediate workaround for deployments that cannot be upgraded, audit all Weaviate configurations to ensure each value in AUTHENTICATION_APIKEY_ALLOWED_KEYS is unique and maps to exactly one user. Additionally, implement network-level access controls to restrict Weaviate API access to trusted clients only, reducing the attack surface until patching is complete.