Azure Key Vault SSRF in Kroxylicious Exposes Bearer Tokens

A high-severity vulnerability in the Azure Key Vault KMS provider within Kroxylicious allows attackers to exfiltrate sensitive bearer tokens. This flaw enables server-side request forgery by accepting untrusted input without proper validation, compromising the security of encrypted records.

What happened

The Azure Key Vault KMS provider in Kroxylicious processes encrypted data keys from wire-deserialized EDEK bytes. According to the National Vulnerability Database record for CVE-2026-105941, the component accepts a vaultName parameter from these bytes without performing format validation. This lack of validation allows an attacker to inject a malicious vaultName into the data stream.

The injected name directs the proxy to an attacker-controlled host. The proxy then sends its Azure bearer token to this external location. This action constitutes a server-side request forgery attack. The vulnerability is classified under CWE-918, which relates to server-side request forgery issues.

This specific flaw affects Red Hat streams for Apache Kafka 3. The National Vulnerability Database assigns the issue a CVSS score of 8.1. This score places the vulnerability in the high severity range. The description notes that the flaw enables the exfiltration of the proxy's authentication credentials.

Why it matters

An attacker who obtains the Azure bearer token can replay it against the real Key Vault. According to the NVD record, this replay attack defeats the entire record-encryption trust model. The security boundary that relies on the proxy's authenticated access is effectively bypassed.

The compromise occurs because the system trusts the vaultName provided in the serialized data. Without format validation, the proxy cannot distinguish between legitimate and malicious requests. This allows the attacker to redirect sensitive authentication material to their own infrastructure.

The impact extends beyond simple data theft. The stolen token grants access to the Key Vault services. This undermines the confidentiality and integrity of the encrypted records managed by the system. The trust model assumes the proxy's token remains secure.

What to watch

• Monitor network logs for outbound requests to unexpected Azure endpoints.
• Check for anomalies in Azure Key Vault access patterns and token usage.
• Review proxy configurations for any unvalidated input handling.
• Alert security teams to potential server-side request forgery attempts.

Who needs to act first

Teams should prioritize systems exposed to untrusted data sources. Identify all instances running the affected Red Hat streams for Apache Kafka 3. Isolate high-value systems that handle sensitive encrypted records. Implement strict network controls to limit outbound connections from the proxy. Test any potential mitigations in a non-production environment first. Back up current configurations before making changes. Reduce exposure by restricting which hosts the proxy can reach.

Background: Replay attacks

A replay attack occurs when an adversary intercepts valid data transmission and maliciously repeats it to impersonate a user or system. Attackers do not need to decrypt the information; they only need to resend the exact same packet or token to the target server. This bypasses authentication if the system cannot distinguish between a fresh request and a recorded one.

Read the full guide: Replay Attacks: How Stolen Data Becomes a Security Threat

What to do and how to stay safe: Kroxylicious

• Audit your environment for Red Hat streams of Apache Kafka 3.
• Restrict outbound network access for proxy services to known Azure endpoints.
• Monitor logs for unusual requests to external hosts from the proxy.
• Prepare to apply an update once the vendor provides a fix.

Step-by-step guide: Virtual Patching Myths: What It Actually Fixes and Breaks

General security guidance from the Patch Gazette newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

What is CVE-2026-105941?

It is a high-severity vulnerability in the Azure Key Vault KMS provider in Kroxylicious that allows server-side request forgery.

Which products are affected by this flaw?

Red Hat streams for Apache Kafka 3 are affected by this vulnerability.

Is there a patch available for CVE-2026-105941?

No fix has been confirmed yet for this vulnerability.