CVE-2026-102414 in pbkdf2
Summary
by MITRE • 09/29/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/29/2026
The vulnerability identified in pbkdf2 versions through 3.1.6 represents a significant performance degradation issue rooted in the implementation of its JavaScript fallback mechanism, specifically within the lib/sync.js module. The core technical flaw lies in how password hashing is handled when the input password exceeds the digest algorithm's block size. For standard algorithms like SHA-256, this threshold is 64 bytes, while for SHA-384 and SHA-512 it extends to 128 bytes. When a password surpasses these limits, the library incorrectly passes the entire long password as the HMAC key on every single iteration of the derivation process. Because HMAC algorithms are required to hash their keys in full if they exceed the block size, this results in redundant and computationally expensive operations that scale linearly with both the number of iterations and the length of the password.
This implementation error leads to a time complexity of O(iterations multiplied by password length), which can cause severe performance bottlenecks. In environments where synchronous execution is mandatory or default, such as Node.js versions prior to 0.12, Bun version ranges from 1.0.0 through 1.1.34 and 1.2.6 onward, and Deno 2.9.0 and later, this flaw can block the event loop. Blocking the event loop is particularly dangerous in server-side applications as it prevents the handling of other incoming requests, effectively leading to a denial-of-service condition for legitimate users even if no malicious intent was present from an attacker perspective. The vulnerability specifically impacts systems where native pbkdf2Sync implementations fail the library's feature check, forcing them to rely on this inefficient JavaScript fallback code path.
The scope of affected software is clearly defined by version constraints and runtime environments. Node.js versions 0.12 and later are not vulnerable because they utilize optimized native bindings that do suffer from this specific inefficiency in the same manner. Similarly, browser-based builds utilizing lib/sync-browser.js are unaffected due to their distinct implementation strategies designed for web environments. Direct imports of lib/sync.js also trigger the vulnerability regardless of the host runtime, highlighting a critical dependency management risk if developers inadvertently pull in the synchronous fallback module without considering the execution context.
From a security architecture perspective, this issue aligns with CWE-400, which describes uncontrolled resource consumption leading to denial-of-service conditions. It can be mapped to ATT&CK technique T1496, Resource Hijacking, as an attacker could potentially exploit long passwords or crafted inputs to consume excessive CPU resources and degrade service availability. While the vulnerability is primarily a performance issue rather than a direct confidentiality breach, its impact on system stability makes it a critical concern for operational security.
Mitigation strategies should focus on both immediate patching and architectural safeguards. The primary remediation is to upgrade pbkdf2 to version 3.1.7 or later, where this inefficient hashing behavior has been corrected. For applications unable to update immediately, enforcing strict maximum password length limits at the application layer serves as an effective compensating control. By ensuring that no input exceeds the digest block size before it reaches the cryptographic library, organizations can prevent the triggering of the expensive re-hashing logic. Additionally, developers should audit their dependency trees to ensure they are not directly importing lib/sync.js in contexts where synchronous execution might block critical threads, preferring asynchronous alternatives or native bindings whenever possible to maintain system responsiveness and resilience against resource exhaustion attacks.