Live › vulnerability › CVE-2026-105941
Go to dashboardThe Azure Key Vault KMS provider in Kroxylicious trusts a vault name taken from wire-deserialized encrypted data keys without validating its format. An attacker can make the proxy send its Azure bearer token to a host they control, then replay that token against the real Key Vault.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Teams running Kroxylicious with the Record Encryption filter and the Azure Key Vault KMS provider. An attacker only needs permission to produce a record to a topic the proxy decrypts. When a consumer fetches it, the proxy sends its Azure bearer token to an attacker-controlled host. Teams using no Record Encryption, or another KMS (AWS KMS, HashiCorp Vault, Thales), can skip this.
| Product | Ecosystem | Affected | Fixed in |
|---|---|---|---|
| kroxylicious-kms-provider-azure-key-vault-kms | maven | 0.25.0 | 0.25.1 |
0.25.0 is affected per the GHSA, 0.25.1 is fixed0.25.1 (kroxylicious-kms-provider-azure-key-vault-kms 0.25.1)Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
The Azure Key Vault KMS provider in Kroxylicious accepts an untrusted vaultName from wire-deserialized EDEK bytes without format validation, enabling SSRF that exfiltrates the proxy's Azure bearer token to an attacker-controlled host. Token replay against the real Key Vault defeats the entire record-encryption trust model.
This page as .md · .json · in your agent: get_signal("CVE-2026-105941")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.