Every CVE Search/ Get API key

CVE-2025-64767

hpke-js reuses AEAD nonces

9.1 CriticalFix available

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.

Attack profile

How easy it is to exploit

Attack vector
Network
Complexity
Low
Privileges needed
None
User interaction
None

What an attacker can affect

Confidentiality
High
Integrity
High
Availability
None

Exploit likelihood

0.23%Up 0.2 points since Nov 22, 2025
90%50%10%1%

What each source reports

CVE List Score used 9.1

hpke-js reuses AEAD nonces

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.

Record
CVE-2025-64767
CVSS 3.1
9.1 CriticalCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Weakness
CWE-323
Updated
2026-11-02
EUVDEUVD-2025-198319 9.1

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.

Record
EUVD-2025-198319
CVSS 3.1
9.1 CriticalCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Updated
2026-11-02
GitHub AdvisoriesGHSA-73g8-5h73-26h4 9.1

@hpke/core reuses AEAD nonces

Summary

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.

Details

The SenderContext Seal() implementation allows for concurrent executions to trigger computeNonce() with the same sequence number. This results in the same nonce being used in the suite's AEAD.

PoC

This code reproduces the issue (and also checks for more things that could be wrong with the implementation).

import { CipherSuite, KdfId, AeadId, KemId } from "hpke-js";

const suite = new CipherSuite({
  kem: KemId.DhkemP256HkdfSha256,
  kdf: KdfId.HkdfSha256,
  aead: AeadId.Aes128Gcm,
});

const keypair = await suite.kem.generateKeyPair();
const skR = keypair.privateKey;
const pkR = keypair.publicKey;

const sender = await suite.createSenderContext({
  recipientPublicKey: pkR,
});

const [message0, message1] = await Promise.all([
  sender.seal(
    new TextEncoder().encode("Secret message 1: Attack at dawn").buffer
  ),
  sender.seal(
    new TextEncoder().encode("Secret message 2: Withdraw troops").buffer
  ),
]);

const recipient = await suite.createRecipientContext({
  recipientKey: skR,
  enc: sender.enc,
});

const plaintext0 = await recipient.open(message0);
console.log("✓ Decrypted message seq=0", new TextDecoder().decode(plaintext0));

try {
  console.log(
    "✓ Decrypted message seq=1",
    new TextDecoder().decode(await recipient.open(message1))
  );
  console.log("\n✓ nonce-reuse reproduction completed, code is NOT vulnerable");
} catch (error) {
  // re-sequence the recipient to verify same nonce was used for two messages
  recipient._ctx.seq = 0;
  console.log(
    "❌ Decrypted a different message with seq=0",
    new TextDecoder().decode(await recipient.open(message1))
  );

  console.log(
    "\n✓ nonce-reuse reproduction completed, code is vulnerable, nonces are reused when concurrent calls to .seal() are used"
  );
}

// Test that failed Open() doesn't increment sequence
const recipient2 = await suite.createRecipientContext({
  recipientKey: skR,
  enc: sender.enc,
});

const invalidMessage = new Uint8Array(message0.byteLength);
invalidMessage.set(new Uint8Array(message0));
invalidMessage[0] ^= 0xff; // Corrupt the first byte

try {
  await recipient2.open(invalidMessage.buffer);
} catch {}

// Now try to open the first valid message - should still work with seq=0
try {
  await recipient2.open(message0);
  console.log("✓ Successfully decrypted message with seq=0 after failed open()");
  console.log("✓ Failed open() did NOT increment sequence");
} catch (error) {
  console.log("❌ Failed to decrypt message - sequence was incorrectly incremented");
}

// Test that same message produces same ciphertext due to nonce reuse
const sender2 = await suite.createSenderContext({
  recipientPublicKey: pkR,
});

const sameMessage = new TextEncoder().encode("Identical message").buffer;
const [cipher0, cipher1] = await Promise.all([
  sender2.seal(sameMessage),
  sender2.seal(sameMessage),
]);

const cipher0Array = new Uint8Array(cipher0);
const cipher1Array = new Uint8Array(cipher1);

let identical = true;
if (cipher0Array.length !== cipher1Array.length) {
  identical = false;
} else {
  for (let i = 0; i < cipher0Array.length; i++) {
    if (cipher0Array[i] !== cipher1Array[i]) {
      identical = false;
      break;
    }
  }
}

if (identical) {
  console.log("\n❌ Same message produced IDENTICAL ciphertext (nonce reuse confirmed)");
} else {
  console.log("\n✓ Same message produced different ciphertext (nonces are unique)");
}

Recommendation

Implement a synchronization mechanism such that only one seal()/open() per context can be executed at a time.

Notes

Refs: https://github.com/hpkewg/hpke/issues/38

…

Record
GHSA-73g8-5h73-26h4
CVSS 3.1
9.1 CriticalCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Weakness
CWE-323
Updated
2026-11-02
NVD 9.1

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.

Record
CVE-2025-64767
CVSS 3.1
9.1 CriticalCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Weakness
CWE-323
Updated
2026-11-02
OSV 9.1

hpke-js reuses AEAD nonces

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.

Record
CVE-2025-64767
CVSS 3.1
9.1 CriticalCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Weakness
CWE-323
Updated
2026-11-02
OSVGHSA-73g8-5h73-26h4 9.1

@hpke/core reuses AEAD nonces

Summary

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.

Details

The SenderContext Seal() implementation allows for concurrent executions to trigger computeNonce() with the same sequence number. This results in the same nonce being used in the suite's AEAD.

PoC

This code reproduces the issue (and also checks for more things that could be wrong with the implementation).

import { CipherSuite, KdfId, AeadId, KemId } from "hpke-js";

const suite = new CipherSuite({
  kem: KemId.DhkemP256HkdfSha256,
  kdf: KdfId.HkdfSha256,
  aead: AeadId.Aes128Gcm,
});

const keypair = await suite.kem.generateKeyPair();
const skR = keypair.privateKey;
const pkR = keypair.publicKey;

const sender = await suite.createSenderContext({
  recipientPublicKey: pkR,
});

const [message0, message1] = await Promise.all([
  sender.seal(
    new TextEncoder().encode("Secret message 1: Attack at dawn").buffer
  ),
  sender.seal(
    new TextEncoder().encode("Secret message 2: Withdraw troops").buffer
  ),
]);

const recipient = await suite.createRecipientContext({
  recipientKey: skR,
  enc: sender.enc,
});

const plaintext0 = await recipient.open(message0);
console.log("✓ Decrypted message seq=0", new TextDecoder().decode(plaintext0));

try {
  console.log(
    "✓ Decrypted message seq=1",
    new TextDecoder().decode(await recipient.open(message1))
  );
  console.log("\n✓ nonce-reuse reproduction completed, code is NOT vulnerable");
} catch (error) {
  // re-sequence the recipient to verify same nonce was used for two messages
  recipient._ctx.seq = 0;
  console.log(
    "❌ Decrypted a different message with seq=0",
    new TextDecoder().decode(await recipient.open(message1))
  );

  console.log(
    "\n✓ nonce-reuse reproduction completed, code is vulnerable, nonces are reused when concurrent calls to .seal() are used"
  );
}

// Test that failed Open() doesn't increment sequence
const recipient2 = await suite.createRecipientContext({
  recipientKey: skR,
  enc: sender.enc,
});

const invalidMessage = new Uint8Array(message0.byteLength);
invalidMessage.set(new Uint8Array(message0));
invalidMessage[0] ^= 0xff; // Corrupt the first byte

try {
  await recipient2.open(invalidMessage.buffer);
} catch {}

// Now try to open the first valid message - should still work with seq=0
try {
  await recipient2.open(message0);
  console.log("✓ Successfully decrypted message with seq=0 after failed open()");
  console.log("✓ Failed open() did NOT increment sequence");
} catch (error) {
  console.log("❌ Failed to decrypt message - sequence was incorrectly incremented");
}

// Test that same message produces same ciphertext due to nonce reuse
const sender2 = await suite.createSenderContext({
  recipientPublicKey: pkR,
});

const sameMessage = new TextEncoder().encode("Identical message").buffer;
const [cipher0, cipher1] = await Promise.all([
  sender2.seal(sameMessage),
  sender2.seal(sameMessage),
]);

const cipher0Array = new Uint8Array(cipher0);
const cipher1Array = new Uint8Array(cipher1);

let identical = true;
if (cipher0Array.length !== cipher1Array.length) {
  identical = false;
} else {
  for (let i = 0; i < cipher0Array.length; i++) {
    if (cipher0Array[i] !== cipher1Array[i]) {
      identical = false;
      break;
    }
  }
}

if (identical) {
  console.log("\n❌ Same message produced IDENTICAL ciphertext (nonce reuse confirmed)");
} else {
  console.log("\n✓ Same message produced different ciphertext (nonces are unique)");
}

Recommendation

Implement a synchronization mechanism such that only one seal()/open() per context can be executed at a time.

Notes

Refs: https://github.com/hpkewg/hpke/issues/38

…

Record
GHSA-73g8-5h73-26h4
CVSS 3.1
9.1 CriticalCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Weakness
CWE-323
Updated
2026-11-02

Affected products

Affected packages

Affected packages
PackageAffectedFixed
@hpke/core
npm
through 1.7.4
1.7.5
@hpke/core
npm
before 1.7.5
1.7.5

History

History
RecordedChangedSources
first indexedCVE List, EUVD, GitHub Advisories, NVD, OSV

Dates are when Every CVE recorded each change. Upstream dates may differ.

In short

CVE-2025-64767 is a critical vulnerability (CVSS 9.1) in Dajiaji Hpke-js, published November 20, 2025. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.23%, the 13th percentile. Fixed in @hpke/core 1.7.5.

References

This page doesn't list everything

Left out here: the rest of 2 source descriptions. The JSON record has them.

MoveEnter Open