Summary
Apache C++ Parquet and PyArrow can pass a KMS URL taken from a Parquet file to a pluggable KmsClient without validating it. If the client uses that URL and does not verify its host, an attacker may cause KMS credentials or tokens to be sent to a malicious server when a crafted file is read.
Apache C++ Parquet and PyArrow can pass a KMS URL taken from a Parquet file to a pluggable KmsClient without validating it. If the client uses that URL and does not verify its host, an attacker may cause KMS credentials or tokens to be sent to a malicious server when a crafted file is read.
Affected context
The issue affects applications using Apache C++ Parquet or PyArrow versions 4.0.0 through 25.0.1 to read encrypted Parquet files with decryption properties and a custom or pluggable KmsClient implementation. Risk is higher when the reader permits the KMS URL to be obtained from file metadata rather than defining it through trusted application configuration, and when the KmsClient does not validate the destination host.
The issue affects applications using Apache C++ Parquet or PyArrow versions 4.0.0 through 25.0.1 to read encrypted Parquet files with decryption properties and a custom or pluggable KmsClient implementation. Risk is higher when the reader permits the KMS URL to be obtained from file metadata rather than defining it through trusted application configuration, and when the KmsClient does not validate the destination host.
Exploit preconditions
- Attack surface: Parquet file ingestion and decryption
- Required access: Ability to provide or influence a Parquet file that the target application reads
- Trigger point: Processing encrypted-file metadata and resolving the KMS URL
- Additional condition: The configured KmsClient must use the supplied URL without independently validating its host
- Why exploitation is possible: An attacker-controlled KMS URL can be forwarded to an unintended endpoint, where authentication material or KMS tokens may be exposed
- Attack surface: Parquet file ingestion and decryption
- Required access: Ability to provide or influence a Parquet file that the target application reads
- Trigger point: Processing encrypted-file metadata and resolving the KMS URL
- Additional condition: The configured KmsClient must use the supplied URL without independently validating its host
- Why exploitation is possible: An attacker-controlled KMS URL can be forwarded to an unintended endpoint, where authentication material or KMS tokens may be exposed
Why this happens
The vulnerability results from accepting a KMS endpoint from file-controlled input and passing it through to a KmsClient without enforcing trust or destination validation. This is an instance of CWE-20: Improper Input Validation, because externally influenced URL data is treated as an acceptable service endpoint without sufficient syntactic, semantic, or host-based checks.
The vulnerability results from accepting a KMS endpoint from file-controlled input and passing it through to a KmsClient without enforcing trust or destination validation. This is an instance of CWE-20: Improper Input Validation, because externally influenced URL data is treated as an acceptable service endpoint without sufficient syntactic, semantic, or host-based checks.
Potential impact
- KMS tokens or authentication credentials may be sent to an attacker-controlled host
- Confidentiality of encryption-service authentication material could be reduced
- An attacker could observe, log, or misuse requests received by the malicious endpoint
- Applications may experience decryption failures or availability impacts
- KMS tokens or authentication credentials may be sent to an attacker-controlled host
- Confidentiality of encryption-service authentication material could be reduced
- An attacker could observe, log, or misuse requests received by the malicious endpoint
- Applications may experience decryption failures or availability impacts
General mitigation guidance
Mitigation generally focuses on preventing untrusted file metadata from selecting security-sensitive service endpoints.
Common defensive patterns include:
- Prefer application-configured KMS URLs over file-controlled values
- Disable file-controlled KMS URL handling by default unless there is a justified trust relationship
- Require KmsClient implementations to validate URL schemes, hosts, ports, and allowed service destinations
- Use explicit allowlists for approved KMS endpoints and reject ambiguous or unexpected URLs
- Minimize token scope and apply least privilege to KMS credentials
- Treat input files as untrusted and preserve trust boundaries during decryption
Mitigation generally focuses on preventing untrusted file metadata from selecting security-sensitive service endpoints.
Common defensive patterns include:
- Prefer application-configured KMS URLs over file-controlled values
- Disable file-controlled KMS URL handling by default unless there is a justified trust relationship
- Require KmsClient implementations to validate URL schemes, hosts, ports, and allowed service destinations
- Use explicit allowlists for approved KMS endpoints and reject ambiguous or unexpected URLs
- Minimize token scope and apply least privilege to KMS credentials
- Treat input files as untrusted and preserve trust boundaries during decryption
How teams detect issues like this
Organizations can detect this class of issue through:
- Static analysis and code review rules that identify externally controlled URLs passed to network clients
- Reviews of KmsClient implementations for missing host, scheme, port, and redirect validation
- Tests using crafted encrypted files to confirm that file metadata cannot redirect KMS requests
- Runtime network policies that restrict KMS clients to approved destinations
- Logging and alerting for KMS requests to unexpected hosts or schemes
- Automated dependency and security review tools that flag unsafe endpoint handling patterns
Organizations can detect this class of issue through:
- Static analysis and code review rules that identify externally controlled URLs passed to network clients
- Reviews of KmsClient implementations for missing host, scheme, port, and redirect validation
- Tests using crafted encrypted files to confirm that file metadata cannot redirect KMS requests
- Runtime network policies that restrict KMS clients to approved destinations
- Logging and alerting for KMS requests to unexpected hosts or schemes
- Automated dependency and security review tools that flag unsafe endpoint handling patterns
Sources
| Source | Link |
|---|---|
| github. | github.com/ |
| lists. | lists.apache.org/ |
| openwall. | openwall.com/ |
