CVE-2025-64767 in hpke-js
Summary
by MITRE • 11/21/2025
hpke-js is a Hybrid Public Key Encryption (HPKE) module built on top of Web Cryptography API. Prior to version 1.7.5, the public SenderContext Seal() API has a race condition which allows for the same AEAD nonce to be re-used for multiple Seal() calls. This can lead to complete loss of Confidentiality and Integrity of the produced messages. This issue has been patched in version 1.7.5.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 11/22/2025
The vulnerability identified as CVE-2025-64767 affects hpke-js, a JavaScript implementation of Hybrid Public Key Encryption that operates on the Web Cryptography API framework. This cryptographic module implements the HPKE standard which provides authenticated encryption with associated data for secure communication. The flaw exists specifically within the SenderContext Seal() API function that handles the encryption process for messages. The race condition vulnerability manifests when multiple concurrent Seal() operations attempt to utilize the same AEAD nonce value, fundamentally compromising the security guarantees that HPKE is designed to provide.
The technical root cause of this vulnerability stems from improper nonce management within the concurrent execution environment of the JavaScript runtime. When multiple Seal() operations execute simultaneously, the system fails to properly synchronize access to the nonce generation mechanism, resulting in nonce reuse across different encryption operations. This behavior directly violates the fundamental cryptographic principle that each AEAD nonce must be unique for every encryption operation to maintain confidentiality and integrity. The issue is classified as a race condition under CWE-362, which describes the vulnerability where two or more threads or processes access shared data concurrently, leading to unpredictable behavior. The specific nature of this race condition allows attackers to exploit the nonce reuse pattern to potentially decrypt messages or inject malicious data without detection.
The operational impact of this vulnerability is severe and directly threatens the core security properties of the encrypted communications. When the same AEAD nonce is reused for multiple Seal() operations, it creates a situation where an attacker can perform ciphertext manipulation attacks that compromise both confidentiality and integrity. The reuse of nonces in AEAD encryption schemes typically leads to complete loss of confidentiality, as demonstrated in various cryptographic attacks against nonce reuse scenarios. Additionally, the integrity of the encrypted messages becomes compromised, allowing for potential data tampering and injection attacks. This vulnerability affects any system using hpke-js versions prior to 1.7.5, particularly those implementing secure communication protocols that rely on HPKE for encryption. The attack surface expands to include any web applications or services that utilize this library for encrypting sensitive data, making it a critical concern for organizations handling confidential information.
The mitigation strategy involves immediate upgrading to hpke-js version 1.7.5 or later, which implements proper nonce management and synchronization mechanisms to prevent the race condition. Organizations should conduct comprehensive vulnerability assessments to identify all systems utilizing this library and ensure timely patch deployment across their infrastructure. Security teams should also monitor for potential exploitation attempts and implement additional detection measures such as network traffic analysis for unusual encryption patterns that might indicate nonce reuse attacks. The fix addresses the underlying race condition by ensuring proper thread synchronization and nonce generation within the SenderContext Seal() function, aligning with best practices for concurrent cryptographic operations. This vulnerability demonstrates the critical importance of proper synchronization in cryptographic implementations and serves as a reminder of how seemingly minor concurrency issues can lead to catastrophic security failures. The remediation process should include thorough testing of the patched library to ensure that the nonce management behavior functions correctly under various concurrent load conditions, and that no regressions have been introduced in the encryption functionality.