CVE-2025-6545

What it actually does

The flaw is an improper input validation issue in the browserify/pbkdf2 package, affecting versions 3.0.10 through 3.1.2, associated with lib/to-buffer.js. When an application passes attacker-controlled or malformed values into pbkdf2-based cryptographic workflows, ambiguous or invalid input may be converted and accepted in a way that weakens signature or key-validation logic. In affected use cases, this can allow signature spoofing or acceptance of data that should fail integrity validation. The CVSS vector indicates network reachability, low attack complexity, no privileges, and no user interaction, but with a required attack condition: the vulnerable library must be used in a security-sensitive path such as token validation, request signing, password-derived key generation, or message authentication.

Why it matters to the business

Applications that rely on the affected pbkdf2 versions for authentication, request signing, token validation, or integrity checks may incorrectly trust forged or tampered data. The practical business risk is unauthorized access, fraudulent transactions or API calls, bypass of integrity controls, and loss of trust in cryptographic protections. Although EPSS is low at 0.00359, there is no known CISA KEV listing, no known ransomware association, and no reported mature public exploitation in the provided data, the issue has been public for over a year, so vulnerable dependencies should be treated as patch debt in any externally exposed or authentication-related application.

How an attack unfolds

An attacker first identifies an application feature that uses the affected pbkdf2 implementation in a security decision, such as verifying a signed token, deriving a key from supplied material, validating a request signature, or checking integrity of a message. The attacker then supplies specially formed input that reaches the vulnerable conversion routine in lib/to-buffer.js. Because the vulnerable code does not properly validate the input before converting it for cryptographic use, the application may derive or compare cryptographic material against an unintended byte representation. If the surrounding application treats the result as authoritative, the attacker can cause a forged signature or malformed authenticated value to be accepted without needing an account or user interaction. Exploitability is application-dependent: deployments that include the vulnerable package but do not expose attacker-controlled inputs to pbkdf2-backed trust decisions may have limited direct exposure.

How to fix it

Upgrade or patch all affected uses of browserify/pbkdf2 versions 3.0.10 through 3.1.2. For source consumers, use a version that includes commit 9699045c37a07f8319cfb8d44e2ff4252d7a7078 or later. If consuming through npm or a transitive dependency, update the direct dependency, regenerate lockfiles, and verify that the resolved pbkdf2 package is no longer in the affected range. Where immediate upgrade is not possible, restrict untrusted input from reaching pbkdf2-related code paths, add strict type and length validation before cryptographic operations, reject non-Buffer/non-string inputs unless explicitly supported, and add application-level checks that fail closed on malformed cryptographic material. For Mageia 6 packages listed in the advisory data, update to the fixed package versions: kernel and kernel-userspace-headers 4.14.100-1.mga6, kmod-vboxadditions and kmod-virtualbox 5.2.24-4.mga6, kmod-xtables-addons 2.13-78.mga6, wireguard-tools 0.0.20190123-1.mga6, and ndiswrapper 1.62-1.mga6. After patching any authentication or signing service, consider invalidating high-risk sessions, rotating affected derived signing material where feasible, and reissuing tokens if suspicious activity is found.

How to confirm the fix worked

Confirm exposure by inventorying dependencies and resolved lockfiles for pbkdf2 versions 3.0.10 through 3.1.2. Check package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, bundled JavaScript assets, container images, and software composition analysis results. Confirm remediation by verifying the resolved package version is outside the affected range or that the source includes commit 9699045c37a07f8319cfb8d44e2ff4252d7a7078 or later. For Mageia systems, validate installed package versions with the system package manager and confirm they match or exceed the fixed versions listed in the advisory. Functionally test security-sensitive flows that use pbkdf2 by submitting malformed, non-canonical, oversized, null, object-like, or unexpected input types and verifying the application rejects them before cryptographic comparison. Regression tests should assert fail-closed behavior for invalid signatures, invalid tokens, and malformed key-derivation inputs.

Typical attack path

1. Identify a web application, API, client-side bundle, or service that includes browserify/pbkdf2 version 3.0.10 through 3.1.2.
2. Determine whether the application uses pbkdf2-derived values in authentication, request signing, token validation, password reset flows, encrypted payload handling, or message integrity checks.
3. Send crafted inputs to the feature that are processed by the vulnerable lib/to-buffer.js conversion path.
4. Trigger ambiguous or improperly validated conversion of attacker-controlled data before cryptographic verification or key derivation.
5. Use the resulting validation weakness to cause a forged or tampered value to be accepted as authentic.
6. Leverage the accepted forged value to access protected functionality, impersonate a user or service, or modify data that should have been integrity-protected.

How to detect it

There are no universal exploitation artifacts for this library-level cryptographic weakness; evidence depends on the application using the affected code. Start with exposure detection by searching dependency manifests and deployed artifacts for pbkdf2 versions 3.0.10 through 3.1.2 or source trees containing lib/to-buffer.js from the affected package. For possible exploitation, review application, API gateway, authentication, identity, and web access logs for malformed or unusual signed tokens, request signatures, password-reset tokens, authorization headers, or cryptographic parameters that nevertheless resulted in successful authentication or authorization. Look for clusters of failed signature, token, or MAC validation events followed by successful access from the same IP address, user agent, session, API client, or target account. Investigate successful privileged actions that occurred immediately after invalid-token errors, unusually encoded payloads, oversized inputs, null-like values, object-like serialized values, or non-canonical base64/hex strings. In JavaScript services, inspect error telemetry for TypeError, RangeError, buffer conversion errors, unexpected input type messages, or validation exceptions near pbkdf2, crypto, token, or signature verification code. If client-side bundles include the vulnerable library, inspect web telemetry for unexpected token-generation or signing behavior, but treat server-side trust decisions as the primary risk.

What your security team should do

• Prioritize patching applications where pbkdf2 is used in authentication, session/token validation, request signing, password reset, API authentication, or message integrity enforcement.
• Run dependency inventory across source repositories, lockfiles, build artifacts, containers, and deployed bundles to identify browserify/pbkdf2 versions 3.0.10 through 3.1.2.
• Upgrade to a fixed version or source revision containing commit 9699045c37a07f8319cfb8d44e2ff4252d7a7078, then rebuild and redeploy affected services.
• Add strict input validation around cryptographic code paths so unexpected types, encodings, lengths, and malformed values are rejected before pbkdf2 or signature-verification logic is reached.
• Review authentication and signing logs for anomalous successful validations, especially malformed tokens, unusual encodings, repeated signature failures followed by success, and access from unfamiliar sources.
• If exploitation is suspected, invalidate active sessions and rotate relevant signing secrets, derived keys, API tokens, or credentials according to application design.
• Track this as moderate urgency where the package is present but not used in trust decisions, and higher urgency for externally reachable services using the affected library in security-sensitive workflows.