Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

CVE-2022-23539

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up

jsonwebtoken unrestricted key type could lead to legacy keys usage

High severity GitHub Reviewed PublishedDec 21, 2022 in auth0/node-jsonwebtoken • UpdatedJun 24, 2024

Package

npmjsonwebtoken (npm)

Affected versions

<= 8.5.1

Patched versions

9.0.0

Description

Overview

Versions<=8.5.1 ofjsonwebtoken library could be misconfigured so that legacy, insecure key types are used for signature verification. For example, DSA keys could be used with the RS256 algorithm.

Am I affected?

You are affected if you are using an algorithm and a key type other than the combinations mentioned below

Key typealgorithm
ecES256, ES384, ES512
rsaRS256, RS384, RS512, PS256, PS384, PS512
rsa-pssPS256, PS384, PS512

And for Elliptic Curve algorithms:

algCurve
ES256prime256v1
ES384secp384r1
ES512secp521r1

How do I fix it?

Update to version 9.0.0. This version validates for asymmetric key type and algorithm combinations. Please refer to the above mentioned algorithm / key type combinations for the valid secure configuration. After updating to version 9.0.0, If you still intend to continue with signing or verifying tokens using invalid key type/algorithm value combinations, you’ll need to set theallowInvalidAsymmetricKeyTypes option totrue in thesign() and/orverify() functions.

Will the fix impact my users?

There will be no impact, if you update to version 9.0.0 and you already use a valid secure combination of key type and algorithm. Otherwise, use theallowInvalidAsymmetricKeyTypes option totrue in thesign() andverify() functions to continue usage of invalid key type/algorithm combination in 9.0.0 for legacy compatibility.

References

@julienwolljulienwoll published to auth0/node-jsonwebtokenDec 21, 2022
Published to the GitHub Advisory DatabaseDec 22, 2022
ReviewedDec 22, 2022
Published by theNational Vulnerability DatabaseDec 23, 2022
Last updatedJun 24, 2024

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

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

CVSS v3 base metrics

Attack vector:More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity:More severe for the least complex attacks.
Privileges required:More severe if no privileges are required.
User interaction:More severe when no user interaction is required.
Scope:More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality:More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity:More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability:More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

EPSS score

Exploit Prediction Scoring System (EPSS)

This score estimates the probability of this vulnerability being exploited within the next 30 days. Data provided byFIRST.
(23rd percentile)

Weaknesses

CVE ID

CVE-2022-23539

GHSA ID

GHSA-8cf7-32gw-wr33
LoadingChecking history
See something to contribute?Suggest improvements for this vulnerability.

[8]ページ先頭

©2009-2025 Movatter.jp