CVE-2026-105941 in Kroxylicious
Summary
by MITRE • 10/20/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/20/2026
The vulnerability in question resides within the Azure Key Vault KMS provider integrated into Kroxylicious, a high-performance API gateway and reverse proxy for Kafka. The core technical flaw is an improper validation of input data during the decryption process, specifically involving External Data Encryption Keys or EDEK bytes that are deserialized from network traffic. When the system processes these wire-deserialized structures, it extracts a vaultName parameter directly from the untrusted payload without performing any format validation or sanitization checks. This lack of rigorous input verification allows an attacker to inject maliciously crafted strings into the vaultName field, which is subsequently used by the underlying Azure SDK to construct API requests against Microsoft's Key Vault service.
This architectural oversight leads to a Server-Side Request Forgery (SSRF) vulnerability with severe security implications. Because Kroxylicious operates as a proxy handling sensitive data encryption and decryption tasks, it possesses valid authentication credentials for interacting with Azure services. Specifically, the application context includes an active Azure bearer token used to authenticate requests to Key Vault operations such as decrypting EDEKs or retrieving keys. By manipulating the vaultName parameter through SSRF, an attacker can force the proxy server to send authenticated HTTP requests not only to legitimate Azure endpoints but also to arbitrary external hosts controlled by the adversary. The most critical consequence of this behavior is that the Azure bearer token embedded in the request headers is transmitted directly to the attacker-controlled destination during the initial handshake or authentication phase of the SSRF-induced connection.
The operational impact of this vulnerability extends far beyond simple data exfiltration, fundamentally breaking the security model of the entire system. Once an attacker obtains a valid Azure bearer token from Kroxylicious, they can perform token replay attacks against the real Azure Key Vault service. Since these tokens are typically issued with specific scopes and permissions granted to the proxy application, the stolen credentials allow the attacker to decrypt any data protected by keys managed within that vault or potentially manipulate key configurations depending on the scope of the leaked token. This effectively defeats the record-encryption trust model because the confidentiality guarantees provided by Azure Key Vault rely on the secrecy of these access tokens and the integrity of the decryption process. An adversary with a valid replayable token can bypass encryption controls entirely, gaining unauthorized access to sensitive records that were previously protected under the assumption that only authorized internal services could interact with the key vault infrastructure.
From a classification perspective, this vulnerability aligns closely with CWE-918, which addresses Server-Side Request Forgery (SSRF) flaws where server-side code makes requests based on user-supplied input without sufficient validation. Additionally, it relates to CWE-20, Improper Input Validation, as the root cause is the failure to restrict or sanitize the vaultName parameter before its use in a critical security function. In terms of attack tactics, this scenario maps to MITRE ATT&CK technique T1557, Adversary-in-the-Middle, specifically involving credential theft via SSRF, and potentially T1078, Valid Accounts, due to the reuse of stolen service principal credentials for unauthorized access. The exploitation chain demonstrates how a seemingly minor input validation failure in a cryptographic component can cascade into a complete compromise of data confidentiality and integrity.
To mitigate this vulnerability, immediate remediation efforts should focus on implementing strict allow-listing or format validation for all inputs that influence network destination resolution within the KMS provider logic. Developers must ensure that parameters like vaultName are validated against expected patterns, such as standard Azure Key Vault DNS naming conventions, to prevent injection of arbitrary hostnames or IP addresses. Furthermore, employing a dedicated HTTP client configuration that restricts outbound connections to only known and trusted endpoints can provide defense-in-depth protection against SSRF attacks even if input validation is bypassed. It is also critical to rotate the compromised Azure bearer tokens immediately upon detection of any potential exploitation attempts, as these credentials may have already been exfiltrated by attackers who gained access prior to patch deployment. Long-term architectural improvements should include isolating cryptographic operations in separate processes or containers with restricted network egress policies to limit the blast radius of such vulnerabilities and prevent direct communication between sensitive components and external networks without explicit authorization checks.