Skip to content

GHSA-hjrf-2m68-5959 CVE-2022-23541

jsonwebtoken's insecure implementation of key retrieval function could lead to Forgeable Public/Private Tokens from RSA to HMAC

Medium npm
Severity
5.0 / 10
Medium · CVSS 3.1
Exploit chance (EPSS)
0.81%
Chance of exploitation in the next 30 days. Higher than 56.92% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-1259 Improper Restriction of Security Token Assignment
CWE-287 Improper Authentication
Fix
9.0.0
Upgrade jsonwebtoken to this version or later

Description

Overview

Versions <=8.5.1 of jsonwebtoken library can be misconfigured so that passing a poorly implemented key retrieval function (referring to the secretOrPublicKey argument from the readme link) will result in incorrect verification of tokens. There is a possibility of using a different algorithm and key combination in verification than the one that was used to sign the tokens. Specifically, tokens signed with an asymmetric public key could be verified with a symmetric HS256 algorithm. This can lead to successful validation of forged tokens.

Am I affected?

You will be affected if your application is supporting usage of both symmetric key and asymmetric key in jwt.verify() implementation with the same key retrieval function.

How do I fix it?

Update to version 9.0.0.

Will the fix impact my users?

There is no impact for end users

Affected versions

npm

PackageVulnerableFixed in
jsonwebtoken
< 9.0.0
9.0.0

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

jsonwebtoken npm → 9.0.0

npm
npm install jsonwebtoken@9.0.0
yarn
yarn add jsonwebtoken@9.0.0
pnpm
pnpm add jsonwebtoken@9.0.0

Severity breakdown

CVSS 3.1 5.0

CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L

Attack vector
Network
Attack complexity
High
Privileges required
Low
User interaction
None
Scope
Unchanged
Confidentiality
Low
Integrity
Low
Availability
Low

Weakness

CWE-1259: Improper Restriction of Security Token Assignment

The System-On-A-Chip (SoC) implements a Security Token mechanism to differentiate what actions are allowed or disallowed when a transaction originates from an entity. However, the Security Tokens are improperly protected.

How to prevent it
  • Architecture and Design, Implementation: Security Token assignment review checks for design inconsistency and common weaknesses. Security-Token definition and programming flow is tested in both pre-silicon and post-silicon testing.

CWE-287: Improper Authentication

When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.

How to prevent it
  • Architecture and Design: Use an authentication framework or library such as the OWASP ESAPI Authentication feature.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-qwph-4952-7xr6
jsonwebtoken vulnerable to signature validation bypass due to insecure default algorithm in jwt.verify()
High Also affects jsonwebtoken
GHSA-8cf7-32gw-wr33
jsonwebtoken unrestricted key type could lead to legacy keys usage
High Also affects jsonwebtoken
GHSA-c7hr-j4mj-j2w6
Verification Bypass in jsonwebtoken
Critical Also affects jsonwebtoken
GHSA-fq2p-5p22-8g6j
Gitea: Public-Only Personal access tokens scope bypass in Organization and Permission Endpoints
Medium Same weakness, CWE-1259
GHSA-p49j-v9wc-wg57
OpenBao's Token Store Allows Cross-Namespace Renewal, Revocation
Low Same weakness, CWE-1259
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor