CVE-2025-64767: hpke-js Race Condition Vulnerability

CVE-2025-64767 Overview

CVE-2025-64767 is a race condition vulnerability in hpke-js, a Hybrid Public Key Encryption (HPKE) module built on top of the Web Cryptography API. Prior to version 1.7.5, the public SenderContext.Seal() API contains a race condition that allows the same AEAD (Authenticated Encryption with Associated Data) nonce to be reused across multiple Seal() calls. This cryptographic flaw can lead to complete loss of confidentiality and integrity of encrypted messages.

Critical Impact

Race condition in HPKE encryption allows nonce reuse, completely compromising message confidentiality and integrity for applications using the affected library.

Affected Products

• hpke-js versions prior to 1.7.5
• Applications using the SenderContext.Seal() API with concurrent operations
• Any software implementing HPKE via the affected hpke-js library

Discovery Timeline

• 2025-11-21 - CVE CVE-2025-64767 published to NVD
• 2025-11-25 - Last updated in NVD database

Technical Details for CVE-2025-64767

Vulnerability Analysis

This vulnerability affects the cryptographic implementation of the HPKE (Hybrid Public Key Encryption) protocol in hpke-js. The core issue lies in the SenderContext.Seal() function, which fails to properly synchronize access to the internal sequence counter used for nonce generation. When multiple concurrent calls to Seal() occur, a race condition can result in the same nonce being used for different encryption operations.

In AEAD encryption schemes, nonce reuse is catastrophic. When the same nonce is used to encrypt two different plaintexts with the same key, an attacker can XOR the two ciphertexts together to eliminate the keystream, revealing the XOR of the two plaintexts. This completely breaks confidentiality and can also compromise integrity by allowing message forgery.

The vulnerability is particularly dangerous in modern JavaScript environments where asynchronous operations are common. Applications performing parallel encryption operations—such as encrypting multiple messages simultaneously or handling concurrent API requests—are especially vulnerable.

Root Cause

The root cause is a Time-of-Check Time-of-Use (TOCTOU) race condition in the nonce management logic. The SenderContext class increments a sequence number after each encryption operation to ensure unique nonces. However, without proper synchronization, concurrent calls can read the same sequence number before either has a chance to increment it, resulting in nonce collision.

The vulnerable code path in senderContext.ts lacks mutex protection around the critical section that reads the nonce, performs encryption, and increments the counter.

Attack Vector

The attack vector is network-based and requires no privileges or user interaction. An attacker who can observe ciphertexts produced by a vulnerable application can exploit nonce reuse to:

1. Recover plaintext: By capturing two ciphertexts encrypted with the same nonce, the attacker XORs them to obtain the XOR of the plaintexts
2. Forge messages: With knowledge of one plaintext and its ciphertext, the attacker can modify the ciphertext to decrypt to an arbitrary message
3. Break authentication: AEAD integrity guarantees are completely invalidated when nonces are reused

The fix introduces a Mutex class to serialize access to the encryption context:

export class Mutex {
  #locked: Promise<void> = Promise.resolve();

  async lock(): Promise<() => void> {
    let releaseLock!: () => void;
    const nextLock = new Promise<void>((resolve) => {
      releaseLock = resolve;
    });
    const previousLock = this.#locked;
    this.#locked = nextLock;
    await previousLock;
    return releaseLock;
  }
}

Source: GitHub Commit

The patched RecipientContext implementation properly acquires the mutex before accessing shared state:

import { EMPTY, OpenError } from "@hpke/common";

import { EncryptionContextImpl } from "./encryptionContext.ts";
import { Mutex } from "./mutex.ts";

export class RecipientContextImpl extends EncryptionContextImpl {
  #mutex?: Mutex;

  override async open(
    data: ArrayBuffer,
    aad: ArrayBuffer = EMPTY.buffer as ArrayBuffer,
  ): Promise<ArrayBuffer> {
    this.#mutex ??= new Mutex();
    const release = await this.#mutex.lock();
    let pt: ArrayBuffer;
    try {
      pt = await this._ctx.key.open(this.computeNonce(this._ctx), data, aad);
    } catch (e: unknown) {
      throw new OpenError(e);
    } finally {
      release();
    }
    this.incrementSeq(this._ctx);
    return pt;

Source: GitHub Commit

Detection Methods for CVE-2025-64767

Indicators of Compromise

• Multiple encrypted messages with identical nonce values in HPKE-encrypted traffic
• Unexpected decryption errors or authentication failures in HPKE-based systems
• Evidence of message tampering or forged ciphertexts in encrypted communications
• Anomalous patterns in encrypted API traffic suggesting plaintext recovery attempts

Detection Strategies

• Audit application dependencies for hpke-js versions prior to 1.7.5 using npm ls @hpke/core or similar package manager commands
• Monitor for concurrent Seal() or Open() operations in application logs or telemetry
• Implement cryptographic logging to detect nonce collisions in encryption operations
• Use software composition analysis (SCA) tools to identify vulnerable library versions across your codebase

Monitoring Recommendations

• Enable detailed logging for HPKE encryption/decryption operations in production environments
• Implement nonce uniqueness verification as a defensive monitoring measure
• Monitor for unusual patterns in encrypted message sizes or timing that may indicate exploitation
• Set up alerts for authentication tag validation failures in AEAD operations

How to Mitigate CVE-2025-64767

Immediate Actions Required

• Upgrade hpke-js to version 1.7.5 or later immediately
• Audit all applications using hpke-js for concurrent encryption operations
• Review encrypted data produced by vulnerable versions for potential compromise
• Consider rotating encryption keys used with vulnerable library versions

Patch Information

The vulnerability has been patched in hpke-js version 1.7.5. The fix introduces a Mutex class that provides proper synchronization for the Seal() and Open() operations, ensuring that nonce generation and sequence counter increments are atomic.

The patch is available at commit 94a767c9b9f37ce48d5cd86f7017d8cacd294aaf. For detailed information, refer to the GitHub Security Advisory.

Workarounds

• Serialize all Seal() and Open() calls at the application level using async/await or Promise chaining to prevent concurrent access
• Implement application-level mutex or semaphore for HPKE operations if immediate upgrade is not possible
• Avoid using shared SenderContext or RecipientContext instances across concurrent operations
• Create new context instances for each encryption operation as a temporary mitigation

# Update hpke-js to patched version
npm update @hpke/core@1.7.5
# Or using yarn
yarn upgrade @hpke/core@1.7.5
# Verify installed version
npm ls @hpke/core