CVE-2026-73334 in Parquet
Summary
by MITRE • 09/09/2026
Potential problem for users of the org.apache.parquet.crypto.keytools package in Apache Parquet, versions 1.12 to 1.18. This package enables users to encrypt Parquet files via an envelope encryption mechanism that wraps (encrypts) data keys via a Key Management Service (KMS). On the reader side, the KMS URL can be application-controlled or file-controlled. If the user does not leverage application control for this parameter, a file-controlled KMS URL is forwarded to a pluggable KmsClient implementation. If the pluggable implementation does not perform host validation, a KMS token can be sent to a malicious host set by an attacker in the file.
Before the problem is fixed, users are recommended to leverage application control for KMS URL parameter in readers (versions 1.12-1.18). After the problem is fixed (presumably in version 1.19), the upgrade will disable file-controlled KMS URL by default. Users of the KMS URL parameter will have two options then: leverage application control for KMS URL parameter in readers, or enable file-controlled KMS URL (via a new app parameter). The latter option will explicitly require (in the new parameter documentation) to validate the KMS URL and use authentication in the custom implementation of the KMS client plug in.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/09/2026
The vulnerability identified within Apache Parquet versions 1.12 through 1.18 affects the org.apache.parquet.crypto.keytools package, which is responsible for implementing envelope encryption mechanisms that wrap data keys using a Key Management Service or KMS. This architectural design allows organizations to manage cryptographic keys centrally while keeping encrypted data portable across different storage systems. The core technical flaw lies in how the reader component handles the location of the KMS service when decrypting files. Specifically, the system supports two modes for determining the KMS URL: application-controlled and file-controlled. In the vulnerable configuration, if an administrator does not explicitly enforce application control, the reader defaults to or accepts a file-controlled mode where the KMS endpoint is embedded directly within the metadata of the Parquet file itself. This design choice introduces a critical trust boundary violation because it assumes that the source of the data file is trustworthy and unmodified by malicious actors during transit or storage.
When a user opens a Parquet file configured with a file-controlled KMS URL, the application extracts this endpoint from the file metadata and forwards it to a pluggable KmsClient implementation for authentication and key retrieval. The vulnerability arises if this custom client implementation fails to perform rigorous host validation on the extracted URL. An attacker who can influence or create Parquet files can embed a malicious KMS URL pointing to an infrastructure they control. Upon decryption, the application will attempt to authenticate with this rogue endpoint. If the pluggable client does not validate that the hostname matches an expected allowlist or possesses valid certificates from trusted authorities, it may successfully establish a connection and transmit sensitive cryptographic tokens or data keys to the attacker's server. This scenario effectively bypasses the security controls intended by envelope encryption, as the confidentiality of the wrapping key is compromised through social engineering or file manipulation rather than direct cryptanalysis.
From an operational impact perspective, this flaw enables unauthorized access to encrypted datasets if the underlying KMS credentials are exfiltrated via the malicious endpoint. Even in scenarios where the attacker cannot immediately decrypt the data without additional keys, the exposure of authentication tokens and metadata can facilitate further attacks such as credential stuffing or lateral movement within a cloud environment that relies on these specific identity providers. The risk is particularly acute in big data ecosystems where Parquet files are frequently shared across teams, ingested from external sources, or processed by automated pipelines that may not scrutinize file metadata for anomalies. This vulnerability aligns with CWE-295 Improper Certificate Validation and CWE-807 Reliance on Untrusted Inputs in Security Features, as the system relies on unvalidated input derived from an external source to make critical security decisions regarding key management endpoints.
To mitigate this risk before upgrading to patched versions, administrators must explicitly configure readers to leverage application-controlled KMS URL parameters rather than relying on file-controlled settings. This ensures that the endpoint for key retrieval is defined in a secure configuration file or environment variable managed by the operations team, preventing malicious files from dictating where decryption requests are sent. For organizations planning to upgrade to version 1.19 and beyond, it is important to note that the default behavior will shift to disable file-controlled KMS URLs entirely. Users who require this functionality for legacy compatibility must explicitly enable it via a new application parameter. Crucially, when enabling file-controlled URLs in newer versions, developers are required to implement strict host validation within their custom KmsClient plugins and ensure robust authentication mechanisms are in place. This shift reflects industry best practices outlined in the MITRE ATT&CK framework under techniques related to Command and Control or Data Exfiltration over Alternative Protocol, emphasizing that security controls must not be bypassable through data manipulation.