Summary
A server-side request forgery vulnerability in Kroxylicious's Azure Key Vault KMS provider allows an attacker to influence the vault destination encoded in wire-deserialized EDEK data. Under conditions where crafted EDEK bytes are processed, the proxy may send its Azure bearer token to an attacker-controlled host, enabling token replay against the legitimate Key Vault.
A server-side request forgery vulnerability in Kroxylicious's Azure Key Vault KMS provider allows an attacker to influence the vault destination encoded in wire-deserialized EDEK data. Under conditions where crafted EDEK bytes are processed, the proxy may send its Azure bearer token to an attacker-controlled host, enabling token replay against the legitimate Key Vault.
Affected context
The issue occurs in deployments using Kroxylicious's Azure Key Vault KMS provider when EDEK bytes received from an untrusted or insufficiently authenticated source are deserialized and their vaultName value is used to construct outbound requests. Risk increases when the provider does not constrain vault destinations to an approved Azure Key Vault endpoint or otherwise protect bearer-token-bearing requests from attacker-controlled routing.
The issue occurs in deployments using Kroxylicious's Azure Key Vault KMS provider when EDEK bytes received from an untrusted or insufficiently authenticated source are deserialized and their vaultName value is used to construct outbound requests. Risk increases when the provider does not constrain vault destinations to an approved Azure Key Vault endpoint or otherwise protect bearer-token-bearing requests from attacker-controlled routing.
Exploit preconditions
- Attack surface: Processing of wire-deserialized EDEK bytes by the Azure Key Vault KMS provider
- Required access: Ability to supply, influence, or cause processing of crafted EDEK data
- Trigger point: Resolution of the vaultName value during a KMS operation
- Why exploitation is possible: The deserialized vaultName is trusted without sufficient format or destination validation, allowing outbound requests to be redirected to an attacker-controlled host
- Credential condition: The proxy must attach an Azure bearer token to the resulting request for token exfiltration to occur
- Attack surface: Processing of wire-deserialized EDEK bytes by the Azure Key Vault KMS provider
- Required access: Ability to supply, influence, or cause processing of crafted EDEK data
- Trigger point: Resolution of the vaultName value during a KMS operation
- Why exploitation is possible: The deserialized vaultName is trusted without sufficient format or destination validation, allowing outbound requests to be redirected to an attacker-controlled host
- Credential condition: The proxy must attach an Azure bearer token to the resulting request for token exfiltration to occur
Why this happens
The underlying bug is a failure to treat wire-deserialized destination data as untrusted input. The provider uses vaultName to influence an outbound request without enforcing a strict format, approved-host policy, or equivalent trust boundary. This behavior maps to CWE-918: Server-Side Request Forgery, because attacker-controlled data can cause a server-side component to make requests to an unintended destination while carrying privileged authentication material.
The underlying bug is a failure to treat wire-deserialized destination data as untrusted input. The provider uses vaultName to influence an outbound request without enforcing a strict format, approved-host policy, or equivalent trust boundary. This behavior maps to CWE-918: Server-Side Request Forgery, because attacker-controlled data can cause a server-side component to make requests to an unintended destination while carrying privileged authentication material.
Potential impact
- An attacker may exfiltrate the proxy's Azure bearer token
- Exfiltrated credentials could be replayed against the legitimate Azure Key Vault
- Unauthorized key-management operations could occur
- Record-encryption confidentiality and integrity could be weakened
- The proxy's cloud identity may be abused for broader resource access, depending on permissions
- An attacker may exfiltrate the proxy's Azure bearer token
- Exfiltrated credentials could be replayed against the legitimate Azure Key Vault
- Unauthorized key-management operations could occur
- Record-encryption confidentiality and integrity could be weakened
- The proxy's cloud identity may be abused for broader resource access, depending on permissions
General mitigation guidance
Mitigation generally focuses on removing attacker control over outbound request destinations and minimizing the value of credentials exposed to network requests.
Common defensive patterns include:
- Accepting only strictly validated vault identifiers that match the intended Azure Key Vault format
- Resolving vault names through an allowlist of approved tenants, subscriptions, domains, or endpoint identities
- Rejecting absolute URLs, alternate schemes, host overrides, and ambiguous destination representations
- Separating wire-deserialized metadata from trusted provider configuration
- Applying outbound network controls that permit requests only to approved Key Vault endpoints
- Using narrowly scoped, least-privilege identities and tokens for KMS operations
- Avoiding credential forwarding when the destination has not been independently verified
- Treating malformed or unexpected EDEK data as a validation failure before any network request
Mitigation generally focuses on removing attacker control over outbound request destinations and minimizing the value of credentials exposed to network requests.
Common defensive patterns include:
- Accepting only strictly validated vault identifiers that match the intended Azure Key Vault format
- Resolving vault names through an allowlist of approved tenants, subscriptions, domains, or endpoint identities
- Rejecting absolute URLs, alternate schemes, host overrides, and ambiguous destination representations
- Separating wire-deserialized metadata from trusted provider configuration
- Applying outbound network controls that permit requests only to approved Key Vault endpoints
- Using narrowly scoped, least-privilege identities and tokens for KMS operations
- Avoiding credential forwarding when the destination has not been independently verified
- Treating malformed or unexpected EDEK data as a validation failure before any network request
How teams detect issues like this
Detection approaches commonly include:
- Static analysis and code review for outbound HTTP clients whose host, URL, or authority is derived from deserialized input
- Checks for missing allowlists, URL canonicalization, scheme restrictions, and destination validation
- Tests using malformed, alternate-format, and attacker-controlled vaultName values to confirm requests are rejected
- Network telemetry that flags Key Vault provider traffic to unapproved hosts or unexpected destinations
- Policy enforcement requiring cloud-service egress restrictions and preventing bearer-token-bearing requests to arbitrary endpoints
- Automated security review tools that identify SSRF-prone request construction and credential forwarding patterns
Detection approaches commonly include:
- Static analysis and code review for outbound HTTP clients whose host, URL, or authority is derived from deserialized input
- Checks for missing allowlists, URL canonicalization, scheme restrictions, and destination validation
- Tests using malformed, alternate-format, and attacker-controlled vaultName values to confirm requests are rejected
- Network telemetry that flags Key Vault provider traffic to unapproved hosts or unexpected destinations
- Policy enforcement requiring cloud-service egress restrictions and preventing bearer-token-bearing requests to arbitrary endpoints
- Automated security review tools that identify SSRF-prone request construction and credential forwarding patterns
Sources
| Source | Link |
|---|---|
| access. | access.redhat.com/ |
| bugzilla. | bugzilla.redhat.com/ |
| github. | github.com/ |
| github. | github.com/ |
