---
id: "CVE-2026-105941"
kind: "vulnerability"
aliases: ["CVE-2026-105941"]
title: "Kroxylicious: untrusted vault name leaks Azure bearer token via SSRF"
severity: "high"
cvss: 8.1
epss: null
exploited: false
status: "open"
category: "package"
products: [{"name": "kroxylicious-kms-provider-azure-key-vault-kms", "fixed": ["0.25.1"], "affected": "0.25.0", "ecosystem": "maven"}]
ecosystems: []
tags: ["azure-key-vault", "kafka", "kroxylicious", "package", "record-encryption", "self-hosted", "ssrf"]
not_affected_if: ["aws-kms", "hashicorp-vault", "no-azure-kms-provider", "no-record-encryption", "non-azure-kms"]
published_at: "2026-10-20T13:16:39+00:00"
first_seen_at: "2026-10-23T21:57:20+00:00"
updated_at: "2026-10-25T03:31:25+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-105941", "first_seen_at": "2026-10-23T21:57:20+00:00"}, {"source": "analyst", "url": null, "first_seen_at": "2026-10-25T03:31:25+00:00"}]
---

# Kroxylicious: untrusted vault name leaks Azure bearer token via SSRF

The 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, check and fix written by a model from the sources; labelled as such._

## Affected

- maven:kroxylicious-kms-provider-azure-key-vault-kms affected 0.25.0 fixed 0.25.1

## How to check

Look in the proxy config for the Record Encryption filter with kms: AzureKeyVaultKmsService. If it is there, check the proxy version: 0.25.0 is affected per the GHSA, 0.25.1 is fixed. Look in egress or DNS logs from the proxy for connections to hosts other than *.vault.azure.net. Producers with write access to a topic can plant a crafted EDEK.

## Fix

Upgrade to Kroxylicious 0.25.1 (kroxylicious-kms-provider-azure-key-vault-kms 0.25.1). It validates the EDEK vaultName against ^[a-zA-Z0-9\-]{3,24}$. If the Azure KMS provider ran on a vulnerable version, assume the proxy's Azure bearer token may have leaked. Review Key Vault access logs and the Entra sign-in logs for the proxy identity, and consider revoking sessions and rotating the proxy identity's credentials.

## Timeline

- 2026-10-23T21:57:20+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-105941
- 2026-10-25T03:31:25+00:00 analyst — Read maintainer GHSA-5j25-p663-ww5r and 0.25.1 release post. GHSA lists affected 0.25.0 only, fixed 0.25.1; CVE record says all versions, so earlier releases unconfirmed. Not checked: public exploitation (none reported) or discussion on X/Bluesky. Red Hat's NetworkPolicy mitigation is AI-generated and unverified, so not recorded.

## Documents

- [advisory] GHSA-5j25-p663-ww5r Kroxylicious Azure KMS bearer token exfiltration https://github.com/kroxylicious/kroxylicious/security/advisories/GHSA-5j25-p663-ww5r
- [fix] Kroxylicious release 0.25.1 https://kroxylicious.io/blog/kroxylicious-proxy/releases/2026/10/20/release-0_25_1.html

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_