CVE-2026-102414

pbkdf2 through 3.1.6 re-hashes passwords longer than the digest's block size on every iteration in its JavaScript fallback (lib/sync.js). A password longer than the block size (64 bytes, or 128 bytes for sha384 and sha512) is passed to HMAC as the key on every iteration, and HMAC hashes such keys in full each time. Cost is therefore O(iterations × password length), and a long password can block the event loop. The fallback is used by pbkdf2Sync and pbkdf2 on Node.js before 0.12, on Bun (1.0.0 through 1.1.34, and 1.2.6 and later), and on Deno 2.9.0 and later, because their native pbkdf2Sync fails the library's feature check. It is also used when lib/sync.js is imported directly. Node.js 0.12 and later, and browser builds (which use lib/sync-browser.js), are not affected. Applications that enforce a reasonable maximum password length are not meaningfully affected.

pbkdf2 through 3.1.6 re-hashes passwords longer than the digest's block size on every iteration in its JavaScript fallback (lib/sync.js). A password longer than the block size (64 bytes, or 128 bytes for sha384 and sha512) is passed to HMAC as the key on every iteration, and HMAC hashes such keys in full each time. Cost is therefore O(iterations × password length), and a long password can block the event loop. The fallback is used by pbkdf2Sync and pbkdf2 on Node.js before 0.12, on Bun (1.0.0 through 1.1.34, and 1.2.6 and later), and on Deno 2.9.0 and later, because their native pbkdf2Sync fails the library's feature check. It is also used when lib/sync.js is imported directly. Node.js 0.12 and later, and browser builds (which use lib/sync-browser.js), are not affected. Applications that enforce a reasonable maximum password length are not meaningfully affected.

Summary

This is the same bug as Django had (CVE-2013-1443).

Details

A long password can cause a DoS because it is not using cached HMAC, length limits, or pre-hashing passwords longer than the block size of the hash function as per HMAC spec. This line of code hashes the full password each iteration: https://github.com/browserify/pbkdf2/blob/1c3b1f526b052a29b3b42120c9821895772df7e8/lib/sync.js#L60

Also see https://github.com/browserify/pbkdf2/issues/82

PoC

The first key will take a lot longer to generate when not using the native code and uses code from /lib/sync.js (ie when this if statement is true): https://github.com/browserify/pbkdf2/blob/1c3b1f526b052a29b3b42120c9821895772df7e8/index.js#L33-L37

var pbkdf2 = require('pbkdf2');
var createHash = require('create-hash');
var pw = ".".repeat(1048576); // 1 MiB

var t0 = performance.now();
var key1 = pbkdf2.pbkdf2Sync(pw, "salt", 1000, 32, "sha256");
var t1 = performance.now();
pw = createHash('sha256').update(pw).digest(); // HMAC specification for keys larger than block size
var key2 = pbkdf2.pbkdf2Sync(pw, "salt", 1000, 32, "sha256");
var t2 = performance.now();

console.log("First took:  " + (t1 - t0));
console.log("Second took: " + (t2 - t1));
console.log("Generated keys:");
console.log(key1);
console.log(key2);

Impact

DoS

pbkdf2 through 3.1.6 re-hashes passwords longer than the digest's block size on every iteration in its JavaScript fallback (lib/sync.js). A password longer than the block size (64 bytes, or 128 bytes for sha384 and sha512) is passed to HMAC as the key on every iteration, and HMAC hashes such keys in full each time. Cost is therefore O(iterations × password length), and a long password can block the event loop. The fallback is used by pbkdf2Sync and pbkdf2 on Node.js before 0.12, on Bun (1.0.0 through 1.1.34, and 1.2.6 and later), and on Deno 2.9.0 and later, because their native pbkdf2Sync fails the library's feature check. It is also used when lib/sync.js is imported directly. Node.js 0.12 and later, and browser builds (which use lib/sync-browser.js), are not affected. Applications that enforce a reasonable maximum password length are not meaningfully affected.

pbkdf2 through 3.1.6 re-hashes passwords longer than the digest's block size on every iteration in its JavaScript fallback (lib/sync.js). A password longer than the block size (64 bytes, or 128 bytes for sha384 and sha512) is passed to HMAC as the key on every iteration, and HMAC hashes such keys in full each time. Cost is therefore O(iterations × password length), and a long password can block the event loop. The fallback is used by pbkdf2Sync and pbkdf2 on Node.js before 0.12, on Bun (1.0.0 through 1.1.34, and 1.2.6 and later), and on Deno 2.9.0 and later, because their native pbkdf2Sync fails the library's feature check. It is also used when lib/sync.js is imported directly. Node.js 0.12 and later, and browser builds (which use lib/sync-browser.js), are not affected. Applications that enforce a reasonable maximum password length are not meaningfully affected.

pbkdf2 through 3.1.6 re-hashes passwords longer than the digest's block size on every iteration in its JavaScript fallback (lib/sync.js). A password longer than the block size (64 bytes, or 128 bytes for sha384 and sha512) is passed to HMAC as the key on every iteration, and HMAC hashes such keys in full each time. Cost is therefore O(iterations × password length), and a long password can block the event loop. The fallback is used by pbkdf2Sync and pbkdf2 on Node.js before 0.12, on Bun (1.0.0 through 1.1.34, and 1.2.6 and later), and on Deno 2.9.0 and later, because their native pbkdf2Sync fails the library's feature check. It is also used when lib/sync.js is imported directly. Node.js 0.12 and later, and browser builds (which use lib/sync-browser.js), are not affected. Applications that enforce a reasonable maximum password length are not meaningfully affected.

Summary

This is the same bug as Django had (CVE-2013-1443).

Details

A long password can cause a DoS because it is not using cached HMAC, length limits, or pre-hashing passwords longer than the block size of the hash function as per HMAC spec. This line of code hashes the full password each iteration: https://github.com/browserify/pbkdf2/blob/1c3b1f526b052a29b3b42120c9821895772df7e8/lib/sync.js#L60

Also see https://github.com/browserify/pbkdf2/issues/82

PoC

The first key will take a lot longer to generate when not using the native code and uses code from /lib/sync.js (ie when this if statement is true): https://github.com/browserify/pbkdf2/blob/1c3b1f526b052a29b3b42120c9821895772df7e8/index.js#L33-L37

var pbkdf2 = require('pbkdf2');
var createHash = require('create-hash');
var pw = ".".repeat(1048576); // 1 MiB

var t0 = performance.now();
var key1 = pbkdf2.pbkdf2Sync(pw, "salt", 1000, 32, "sha256");
var t1 = performance.now();
pw = createHash('sha256').update(pw).digest(); // HMAC specification for keys larger than block size
var key2 = pbkdf2.pbkdf2Sync(pw, "salt", 1000, 32, "sha256");
var t2 = performance.now();

console.log("First took:  " + (t1 - t0));
console.log("Second took: " + (t2 - t1));
console.log("Generated keys:");
console.log(key1);
console.log(key2);

Impact

DoS

pbkdf2 through 3.1.6 re-hashes passwords longer than the digest's block size on every iteration in its JavaScript fallback (lib/sync.js). A password longer than the block size (64 bytes, or 128 bytes for sha384 and sha512) is passed to HMAC as the key on every iteration, and HMAC hashes such keys in full each time. Cost is therefore O(iterations × password length), and a long password can block the event loop. The fallback is used by pbkdf2Sync and pbkdf2 on Node.js before 0.12, on Bun (1.0.0 through 1.1.34, and 1.2.6 and later), and on Deno 2.9.0 and later, because their native pbkdf2Sync fails the library's feature check. It is also used when lib/sync.js is imported directly. Node.js 0.12 and later, and browser builds (which use lib/sync-browser.js), are not affected. Applications that enforce a reasonable maximum password length are not meaningfully affected.

TuxCare rebuilt pbkdf2 to address 1 CVE. Fixed in 3.1.6-tuxcare.1.