CVE-2025-65945

What it actually does

The flaw affects auth0/node-jws versions 3.2.2 and earlier, and 4.0.0, when applications verify HMAC-signed JSON Web Signatures with HS256 using jws.createVerify(). Under specific implementation patterns, if the application uses attacker-controlled values from the protected header or payload to choose or look up the HMAC secret, signature verification can be bypassed. The practical result is integrity failure: an attacker may be able to make an application accept a forged token or signed message as valid without possessing the legitimate signing secret. The CVSS impact is high for integrity, with network exploitation, low attack complexity, no privileges, and no user interaction required. The listed SUSE OpenEXR package entries appear inconsistent with the described Node.js JWS issue; treat vendor package advisories separately, but prioritize auth0/node-jws usage for this vulnerability.

Why it matters to the business

Applications that rely on vulnerable node-jws verification for authentication, authorization, session validation, API access, tenant routing, or privilege decisions may accept forged claims. This can lead to unauthorized account access, privilege escalation, fraudulent API activity, bypass of business rules, or unauthorized changes to data. The issue is not currently in CISA KEV, is not reported as ransomware-used, has low EPSS probability, and no public exploit maturity is listed, but the impact is significant wherever HS256 JWS verification protects sensitive actions. Because it was published 249 days ago, vulnerable dependencies should be treated as overdue remediation rather than a newly emerging risk.

How an attack unfolds

An attacker first identifies an application endpoint that accepts a JWS or JWT-like object and verifies it using auth0/node-jws. They then determine or infer that the application uses HS256 and calls jws.createVerify() while deriving the HMAC secret from data that the attacker controls in the token header or payload. The attacker crafts a token whose protected header and/or payload influence the secret lookup routine so that verification is performed against attacker-chosen or otherwise incorrect key material. They then submit the forged signed object to the application. If the vulnerable verification path is reached, the application may treat the attacker-controlled claims as authentic, enabling unauthorized access or actions consistent with the forged token contents.

How to fix it

Upgrade auth0/node-jws to a patched release: 3.2.3 or later on the 3.x line, or 4.0.1 or later on the 4.x line. For source builds, ensure the fix includes commit 4f6e73f24df42f07d632dec6431ade8eda8d11a6. Regenerate lockfiles and redeploy applications so the patched dependency is actually present in runtime containers, serverless bundles, and build artifacts. Review all uses of jws.createVerify() with HS256 and ensure HMAC secret selection is based only on trusted server-side configuration or pre-validated key identifiers, not untrusted protected header or payload values. Where feasible, restrict accepted algorithms explicitly and reject tokens with unexpected alg, kid, issuer, audience, or claim structures before performing sensitive authorization decisions. If SUSE package scanners report the listed OpenEXR entries, apply the vendor-fixed package version 2.1.0-6.26.1 for the affected SUSE 12 SP5 products, but validate whether that advisory mapping is relevant to this Node.js authentication issue.

How to confirm the fix worked

Confirm dependency remediation by inspecting package.json, package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, SBOMs, and deployed node_modules/jws/package.json to verify node-jws is not 3.2.2 or earlier and is not 4.0.0. Run npm ls jws, yarn why jws, or pnpm why jws to identify transitive inclusions and confirm all resolved versions are patched. Search application source for jws.createVerify() and review whether HS256 verification uses header or payload fields to choose HMAC secrets. Add regression tests that submit tokens with manipulated protected headers and payload claims used in key lookup logic and assert that they are rejected. Validate production exposure by checking that services accepting JWS/JWT inputs have been redeployed from patched builds rather than only updating source repositories.

Typical attack path

1. Discover an endpoint or workflow that accepts JWS/JWT-style bearer tokens, signed requests, webhooks, session artifacts, or API assertions.
2. Confirm or infer that HS256 HMAC verification is accepted by the application.
3. Craft JWS inputs with attacker-controlled protected header or payload fields that may be used by the application during HMAC secret lookup.
4. Sign or structure the token so that vulnerable node-jws verification accepts it under the manipulated lookup condition.
5. Submit the forged token or signed message to the target endpoint.
6. Use accepted forged claims to access protected functions, assume unauthorized roles, alter state, or bypass application-level authorization checks.

How to detect it

There are no unique network or host indicators that prove exploitation of this library flaw. Detection should focus on exposure review and behavioral evidence of forged-token use. Collect application authentication logs, API gateway logs, reverse proxy logs, identity-provider logs, audit trails for authorization decisions, and any structured token validation failure/success telemetry. Look for successful requests using HS256 tokens where header or payload fields such as kid, iss, aud, sub, tenant, client_id, or role values are unusual, newly observed, malformed, missing, or inconsistent with normal issuance patterns. Investigate successful authentications that lack a corresponding legitimate token issuance event, have impossible travel or impossible sequence behavior, use unexpected roles or scopes, or perform privileged actions shortly after anomalous token presentation. If tokens or token metadata are logged, compare accepted tokens against known issuer signing policies and expected server-side key mappings. In code and build telemetry, search for jws.createVerify() combined with HS256 and secret lookup routines that read from protected header or payload fields. Preserve relevant request headers, authorization metadata, application debug logs, and audit records before rotating secrets or changing verification logic, because remediation may remove evidence needed for timeline reconstruction.

What your security team should do

• Inventory all Node.js services and libraries that include auth0/node-jws directly or transitively, especially internet-facing authentication, API gateway, webhook, and session-validation paths.
• Patch to node-jws 3.2.3 or 4.0.1 or later, rebuild artifacts, redeploy, and verify the runtime version rather than relying only on dependency manifests.
• Prioritize applications using HS256 with jws.createVerify() and any custom HMAC secret lookup based on token header or payload data.
• Perform a focused code review of token verification logic to ensure untrusted token claims are not used to determine the verification secret before the signature is trusted.
• Add tests and runtime controls to reject unexpected algorithms, untrusted key identifiers, malformed protected headers, and tokens with inconsistent issuer/audience/subject claims.
• Review authentication and authorization logs for anomalous successful access involving unusual token headers, unexpected key identifiers, role changes, issuer/audience anomalies, or impossible user behavior.
• Because no KEV listing, ransomware association, or mature public exploit is currently reported and EPSS is low, schedule remediation based on exposure and business criticality, but treat any internet-facing auth path as high priority.