Kroxylicious EUVD-2026-104983

Requires a Kroxylicious deployment (as shipped in Red Hat Streams for Apache Kafka 3) configured to use the Azure Key Vault KMS provider for record encryption - this is a specific, non-universal configuration. The attacker must be able to supply or influence wire-deserialized EDEK bytes processed by the proxy (reflected as PR:L in the vector) and must control a network host the proxy can reach to receive the exfiltrated bearer token. Exploitation is limited to deployments actually using the Azure Key Vault provider; environments using other KMS backends or without record encryption enabled are not affected. No end-user interaction is required (UI:N).

This is a genuine high-priority issue rather than an inflated-CVSS artifact, but it is scoped to a specific deployment configuration. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N, 8.1 High) describes a network-reachable, low-complexity attack requiring only low privileges - consistent with an attacker who can feed EDEK (encrypted data encryption key) bytes into the proxy's record-encryption path. The C:H/I:H impact is well-justified: exfiltrating the proxy's Azure bearer token and replaying it against the real Key Vault collapses the record-encryption trust model, enabling both disclosure and forgery of protected records; A:N is appropriate as this is not a denial-of-service. No EPSS score, KEV listing, or POC was provided in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation - the priority derives from impact severity and the modest preconditions, not from observed in-the-wild activity. One nuance to verify: PR:L indicates authenticated access, yet the real limiting factor is whether an attacker can reach the wire-deserialized EDEK path and whether the Azure Key Vault KMS provider is actually in use; both should be confirmed against the specific deployment.

An attacker with low-privilege access to the Kafka data path through Kroxylicious crafts a record whose wire-serialized EDEK embeds an attacker-controlled vaultName. Because the Azure Key Vault KMS provider never validates the vaultName format, the proxy issues an authenticated request - carrying its Azure bearer token - to the attacker's host (SSRF), leaking the token. The attacker then replays that bearer token against the legitimate Azure Key Vault to decrypt or forge protected records. No public exploit code was identified at time of analysis.