Weaviate EUVD-2026-35034

Exploitation requires all of the following conditions to be true simultaneously: (1) The Weaviate instance must have the Static API Key authentication feature explicitly enabled in configuration - this is not the default state for all deployments. (2) The administrator must have misconfigured the AllowedKeys array with at least one duplicate key value mapped to two different user entries (e.g., AllowedKeys: ['key-A', 'key-A'], Users: ['user1', 'user2']). (3) The attacker must already possess the duplicated API key (PR:L - authenticated, low privilege), meaning they are a known API user of the system. What limits exploitation: the attacker cannot create the duplicate key condition themselves without administrative access to the Weaviate configuration; high attack complexity (AC:H) is consistent with needing to identify and trigger the ambiguous key resolution path; and the impact is bounded to user-level identity confusion within a single Weaviate instance (SC:N - no scope change). Deployments using OIDC, anonymous access, or no authentication are unaffected.

CVSS 4.0 score of 1.3 is very low, and the vector accurately reflects the real-world risk profile: AV:N (network-reachable) but AC:H (high complexity), PR:L (low privilege - attacker must already hold a valid key), and limited confidentiality, integrity, and availability impact (VC:L/VI:L/VA:L) scoped to the vulnerable system only (SC:N/SI:N/SA:N). The E:P modifier confirms proof-of-concept code exists but lowers the score relative to confirmed active exploitation. No KEV listing exists, and EPSS data is not provided. The practical risk is further constrained by the requirement for a specific administrator misconfiguration (duplicate keys in Static API Key config), meaning this vulnerability cannot be exploited against correctly configured deployments. This is a misconfiguration-amplification issue rather than a standalone unauthenticated attack vector. The high attack complexity designation is consistent - an attacker must both possess a duplicated key and identify that duplicate-key ambiguity exists, which requires either insider knowledge or the ability to observe configuration state. Low priority for most organizations unless Static API Key authentication is in use with multiple users sharing key values.

An administrator has deployed Weaviate with Static API Key authentication and inadvertently (or through a tooling error) configured the same key value for two users - for example, 'jane' and 'jessica' both assigned 'secret-key'. An attacker holding that key authenticates to Weaviate, and due to the unvalidated duplicate, the key resolves to the alternate user identity rather than the attacker's own. This allows the attacker to perform API operations as the other user, accessing vector collections or data objects they are not authorized for under their own identity. Publicly available exploit code exists via GitHub issue #11392.