Go to packages list

pbkdf2

Ecosystem: npm

Downloads:

Vulnerabilities from the last (months)
  • 2CriticalAffects 2 versions
  • 0HighAffects 0 versions
  • 0MediumAffects 0 versions
  • 1ModerateAffects 1 version
  • 0LowAffects 0 versions
Severity distribution (all time)
3vulnerabilities
  • Critical2 (66.7%)
  • High0 (0.0%)
  • Medium0 (0.0%)
  • Moderate1 (33.3%)
  • Low0 (0.0%)

Monthly breakdown

  • Critical
  • High
  • Medium
  • Moderate
  • Low
  • 1 vulnerabilities
    • Critical: 0
    • High: 0
    • Medium: 0
    • Moderate: 1
    • Low: 0
  • 2 vulnerabilities
    • Critical: 2
    • High: 0
    • Medium: 0
    • Moderate: 0
    • Low: 0

Vulnerabilities (3)

Known vulnerabilities affecting pbkdf2, based on data from OSV.

Vulnerabilities affecting pbkdf2
IDSeveritySummaryAffected versionsPublishedSource
GHSA-477h-4r7f-fvrxModeratepbkdf2 rehashes long passwords on every iteration, enabling denial of service### 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 t
  • < 3.1.7
GitHub (opens in a new tab)
GHSA-h7cp-r72f-jxh6Criticalpbkdf2 returns predictable uninitialized/zero-filled memory for non-normalized or unimplemented algos### Summary This affects both: 1. Unsupported algos (e.g. `sha3-256` / `sha3-512` / `sha512-256`) 2. Supported but non-normalized algos (e.g. `Sha256` / `Sha512` / `SHA1` / `sha-1` / `sha-256` / `sha-512`) All of those work correctly in Node.js, but this polyfill silently returns highly predictable ouput Under Node.js (only with `pbkdf2/browser` import, unlikely) / Bun (`pbkdf2` top-level import is affected), the memory is not zero-filled but is uninitialized, as `Buffer.allocUnsafe` is used Under browsers, it just returns zero-filled buffers (Which is also critical, those are completely
  • >= 3.0.10, < 3.1.3
GitHub (opens in a new tab)
GHSA-v62p-rq8g-8h59Criticalpbkdf2 silently disregards Uint8Array input, returning static keys### Summary On historic but declared as supported Node.js versions (0.12-2.x), pbkdf2 silently disregards Uint8Array input This only affects Node.js <3.0.0, but `pbkdf2` claims to: * Support Node.js [>= 0.12](https://github.com/browserify/pbkdf2/blob/v3.1.2/package.json#L62) (and there seems to be ongoing effort in this repo to maintain that) * Support `Uint8Array` input (input is typechecked against Uint8Array, and the error message includes e.g. "Password must be a string, a Buffer, a typed array or a DataView" ### Details The error is in `toBuffer` method This vulnerability somehow e
  • >= 1.0.0, < 3.1.3
GitHub (opens in a new tab)
  • GHSA-477h-4r7f-fvrxModerate
    pbkdf2 rehashes long passwords on every iteration, enabling denial of service
    • < 3.1.7
    GitHub (opens in a new tab)

    ### 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 t

    CVE: CVE-2026-102414

  • GHSA-h7cp-r72f-jxh6Critical
    pbkdf2 returns predictable uninitialized/zero-filled memory for non-normalized or unimplemented algos
    • >= 3.0.10, < 3.1.3
    GitHub (opens in a new tab)

    ### Summary This affects both: 1. Unsupported algos (e.g. `sha3-256` / `sha3-512` / `sha512-256`) 2. Supported but non-normalized algos (e.g. `Sha256` / `Sha512` / `SHA1` / `sha-1` / `sha-256` / `sha-512`) All of those work correctly in Node.js, but this polyfill silently returns highly predictable ouput Under Node.js (only with `pbkdf2/browser` import, unlikely) / Bun (`pbkdf2` top-level import is affected), the memory is not zero-filled but is uninitialized, as `Buffer.allocUnsafe` is used Under browsers, it just returns zero-filled buffers (Which is also critical, those are completely

    CVE: CVE-2025-6545

  • GHSA-v62p-rq8g-8h59Critical
    pbkdf2 silently disregards Uint8Array input, returning static keys
    • >= 1.0.0, < 3.1.3
    GitHub (opens in a new tab)

    ### Summary On historic but declared as supported Node.js versions (0.12-2.x), pbkdf2 silently disregards Uint8Array input This only affects Node.js <3.0.0, but `pbkdf2` claims to: * Support Node.js [>= 0.12](https://github.com/browserify/pbkdf2/blob/v3.1.2/package.json#L62) (and there seems to be ongoing effort in this repo to maintain that) * Support `Uint8Array` input (input is typechecked against Uint8Array, and the error message includes e.g. "Password must be a string, a Buffer, a typed array or a DataView" ### Details The error is in `toBuffer` method This vulnerability somehow e

    CVE: CVE-2025-6547

Showing 1-3 of 3 vulnerabilities