[Update] This CVE advisory was withdrawn on Jan. 27, 2023, after the blog below was published on Jan. 17.


JsonWebToken (JWT) is a standard for creating access tokens to securely transmit information between two parties. It is commonly used to authenticate users and provide them with secure access to resources.

JsonWebToken is a JSON-encoded representation mostly used for managing authorization. It will be implemented in the node.js open-source server.

The authorization is signed digitally by the server and consumed by the client browser. Each token is also signed using RSA encryption (hashing).

Encrypting a JsonWebToken requires their public RSA key. The decryption takes place with the corresponding private RSA key, which the user must keep secret.

  • The header: identifies which algorithm is used to generate the signature. The algorithms can be HMAC, SHA256, RSA, HS256, or RS256
  • The payload: consists of the session data called as claims, for example:
      • ISSUER(ISS)
      • SUBJECT(Sub)
      • Audience(aud)
      • Expiration time(exp)
      • Issued at(iat).
  • The signature: securely validates the token. The signature is calculated by encoding the header and payload using Base64url, encoding and concatenating them with a period separator

How it works

  • Once you sign into your account, the client makes a post request with his or her credentials to the server.
  • The server will create a JsonWebToken, encoding and serializing it with a secret key. The server takes that JsonWebToken and sends it back to the browser. Note that it will not be stored on the server.
  • The client then sends a request to the server with the JsonWebToken to validate that user.
  • The server will sign the JsonWebToken with its secret key and will verify that the token has not been changed since the last time that it signed it.
  • The server will de-serialize that token and give the right authorization.

 JsonWebToken Kill Chain

JsonWebToken Security Flaw

A new vulnerability identified as CVE-2022-23529, with a high-severity score of 7.6, was found in the JsonWebToken open-source project.

By exploiting this vulnerability, adversaries can receive remote code execution (RCE).

This vulnerability pertains to all who are using the JsonWebToken versions 8.5.1 and below on the NodeJS platform.

Usually, adversaries use JsonWebToken vulnerabilities to bypass authentication and authorization mechanisms, which gives them the option to take over the account, impersonate users, and elevate privileges.

However, this vulnerability can give adversaries the option to execute remote code on the browser.

Looking at the JsonWebToken repository, one of its functions is called verify.js. This is used to verify the validity of the JsonWebToken and returns the decoded payload part.

This function receives three parameters:

  1. Token
  2. SecretOrPublicKey
  3. Options

According to the JsonWebToken implementation for node.js documentation, the SecretOrPrivateKey parameter is a string (UTF-8 encoded), buffer, object, or KeyObject containing either the secret for HMAC algorithms or the PEM-encoded private key for RSA and ECDSA.

When using Verify.js, if no arguments are provided in the options.algorithms list, the SecretOrPrivateKey uses the method toStrings() that will return the string representation of an object, and the PEM values will be assigned instead.

That indicates that there will be no validation to determine whether SecretOrPublicKey is indeed a string or a buffer, so if the toString() method is controllable, an adversary can insert a malicious code to receive a remote code execution (RCE).

By creating a malicious object and using the child_process module with the exec() method, it will spawn a shell that will execute the command within that shell.

Once the request is sent back to the server, it will execute CMD command using child_process.exec() function on the exit event of the process. Then the process exits with a code of 0. This way, the payload will run before it gets to the indexOf() method.


Update the JsonWebToken version to, which addresses the vulnerability with a fix:

As Cynet is aware of emerging threats and vulnerabilities, we have confirmed and made sure Cynet’s 360 AutoXDR platform and infrastructure are not affected by the JWT RCE vulnerability.

Cynet’s research team has already deployed a new detection to detect attempts to exploit this vulnerability.

To ensure you are fully protected by Cynet 360 AutoXDR, please confirm that all mechanisms are set with detection and preventions enabled.

Cynet is continuing to monitor the threat landscape for new risks and vulnerabilities and will provide updates about any developments, dependencies, and measures to take to mitigate these threats.

As always, the CyOps team is available 24/7 for any question or concern.