Trend Vulnerabilities

The Shadow of JWT-Based Authentication: A Fatal Threat Behind the Convenience

  • Dec 16 2025
The Shadow of JWT-Based Authentication: A Fatal Threat Behind the Convenience

Overview

JWT, which has become the standard for modern web applications and mobile apps, provides the convenience of stateless authentication. However, when operated and managed unsafely, it can become a single point of failure that collapses the entire authentication system. This post introduces the concept and authentication methods of JWT, analyzes its key vulnerabilities based on CVE cases, and suggests practical defense strategies for prevention and mitigation.

 

JSON Web Token (JWT)

JWT is a web standard (RFC 7519) that securely transmits information between two parties in a compact and self-contained manner using a JSON object. This token contains all the required information within itself, allowing user authentication and authorization to be performed using the token without requiring a database query on the server. In addition, its stateless structure reduces the burden of storing and synchronizing server-side sessions, and its ease of transmission through HTTP headers or URL parameters makes it easy to scale and transmit in a distributed environment. For these reasons, JWT has become a key authentication method in modern web and microservice environments.

 

1) Structure and Components of JWT

JWT is composed of three parts (Header, Payload, Signature) encoded in Base64Url and combined with periods (.).

Figure 1. Structure of JWT

 

1. Header: Metadata

The header is the part that contains the token’s metadata in a JSON object encoded with Base64Url. It must include the typ (Type, typically JWT) and alg (Algorithm, encryption algorithm used for the signature, e.g., HS256, RS256) claims.

{
  "alg": "HS256",  // Signature algorithm
  "typ": "JWT"     // Token type
}

 

2. Payload: Claims

The payload includes authentication credentials, authorization information, and other claims in a JSON object that is to be transmitted. Like the header, the payload is also encoded with Base64Url.

  • Types of Claims
    Claims are classified into three types based on their roles: Registered (standard), Public, and Private. Registered claims include standard fields that are used to validate the token’s validity, such as the expiration time (exp), issuance time (iat), issuer (iss), and audience (aud).
  • Security Considerations
    Since the header and payload are encoded and not encrypted, it is easy to decode the payload if it is obtained. Therefore, the payload should not include sensitive personally identifiable information (PII) such as emails and payment details.
{
  "sub": "user123",           // User ID
  "name": "John Doe",         // User name
  "role": "admin",            // Role
  "iat": 1516239022,          // Issued at
  "exp": 1516242622           // Expiration time
}

 

3. Signature: Ensuring Integrity

The signature is a key element that ensures the token’s integrity and authenticity. The signature is calculated through a cryptographic operation based on the encoded header and payload, and the secret key (HS256) or private key (RS256) stored on the server. The server recalculates the signature and checks if it matches the received signature to determine if the token has been tampered with. Attackers who do not know the secret key cannot generate a valid signature.

HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  SECRET_KEY
)

 

2) Comparison of Session-Based Authentication and JWT Authentication

The differences between session-based and JWT authentication can be identified through the diagram shown in Figure 2.

Figure 2. Comparison of the session-based authentication and JWT authentication processes

 

Session-Based Authentication

Session-based authentication has four major disadvantages:

  • Stateful structure requiring the server to directly manage session state
  • Session sharing (common session store, sticky session, etc.) is required when scaling out servers
  • Additional load and operating costs occur for the session store (DB, Redis, etc.)
  • It may lose flexibility in a microservices or distributed architecture because it relies on a central session store

 

JWT Authentication

On the other hand, JWT authentication somewhat alleviates the disadvantages of session-based authentication:

  • Stateless structure allowing basic authentication through signature verification without a separate session store
  • It is advantageous for scaling out because it does not require session synchronization between servers/instances
  • It is microservices-friendly because each service can directly validate tokens
  • It reduces the server’s dependency on the server state by including user identifiers, permissions, and expiration times in the token

 

Main JWT security vulnerabilities

The vulnerability of JWTs mainly occurs when the server trusts the header parameters that the user can manipulate. The key advantage of JWT, its statelessness, can actually become a critical weakness if the operational design is inadequate. In traditional session-based authentication, when a server deletes a session, the user is immediately logged out. However, with JWT, since the token is stored on the client side, it is difficult for the server to immediately revoke the token. Unless there is a separate revocation mechanism, the token can remain valid until it expires. This means that even if a user’s permissions are changed or their account is deactivated, if the previously issued JWT is still valid, the user may still be able to access the API. Even if the user detects the account takeover and resets the password, the attacker can still use the JWT that they have obtained to access the API.

If a signature key is leaked, an attacker can impersonate any user or create a token with escalated privileges. There have been reported cases where a breach of a signature key was used to forge an authentication token, leading to a massive data breach. If a forged token passes the signature verification, the server and detection system will treat it as a legitimate request and process it accordingly, causing a delay in detection.

 

1) Bypassing Signature Integrity Check

1. HS/RS Algorithm Confusion Vulnerability (CVE-2015-9235)

The jsonwebtoken library for Node.js versions before 4.2.2 has an algorithm confusion vulnerability. It accepts tokens signed with HMAC algorithms (HS) even when it should be validating tokens signed with RSA or ECDSA algorithms (RS). An attacker can exploit this vulnerability by using the server’s public key as an HMAC secret key to sign a token with an arbitrary payload. This allows the attacker to bypass authentication or escalate their privileges.

2. alg=none Allowance Vulnerability (CVE-2021-22160 / CVE-2022-23540 / CVE-2025-61152)

Some implementations do not perform signature verification on tokens that contain alg: “none” in the header, or they treat an unspecified verification option as none. This allows attackers to bypass signature verification. An issue was reported where Apache Pulsar did not perform signature verification on tokens with alg=none. The jsonwebtoken library allowed signature verification to be bypassed by treating none as the default when the algorithm was not specified in jwt.verify(). The python-jose library was reported to allow tokens with alg=none to bypass signature verification.

3. JWT Claim Tampering Vulnerability (CVE-2022-39227)

python-jwt before version 3.3.4 has a vulnerability where the JWS JSON serialization and JWS compact serialization processes do not match, which can result in the values that pass signature verification being different from the actual claims used by the application. An attacker can exploit this vulnerability by using the stolen secret key to reuse the signature from a legitimate token and tamper with the claims to bypass authentication. This vulnerability has been rated as a CVSS score of 9.1 (Critical).

 

2) Algorithm Confusion Attack

1. json-web-token Library Vulnerability (CVE-2023-48238)

The json-web-token library for Node.js versions before 3.1.1 has a design flaw that allows the algorithm used for validation to be extracted from the alg field in the JWT header. If a server is using RS256 and an attacker obtains the public key, they can set the alg to HS256 and use the public key as an HMAC key to sign a token without needing a private key.

2. cjwt Library Vulnerability (CVE-2024-54150)

In version 2.2.0 of the C-based JWT library cjwt, the signature scheme (HMAC vs. RS/EC/PS) is not strictly distinguished during the token verification process, potentially leading to algorithm confusion. As a result, in configurations where the validation logic does not safely enforce the alg and key type of the token, threat actors may treat the public key as an HMAC key and coerce the validation process to pass without a private key, allowing them to forge tokens. This vulnerability has been patched in version 2.3.0.

 

3) Key Search Parameter Injection

1. Traversing the path of the kid parameter and SQL injection

If the server directly uses the kid value in a file path or a database query, threat actors can inject path traversal strings such as /dev/null or SQL statements to select an arbitrary key or disrupt the key lookup logic. As a result, the verification can be performed with the wrong key, leading to the exposure of key storage information.

 

4) Vulnerability of Key Management Failure

1. Hardcoded Secret Key (CVE-2025-7079 / CVE-2025-6950)

If the private key is hard-coded in the code or firmware, threat actors can obtain the value to forge an arbitrary JWT and bypass authentication. CVE-2025-7079 is a case where the ‘bluebell-plus’ string is hard-coded in the jwt.go file of bluebell-plus, and CVE-2025-6950 is a case where the use of a hard-coded key for JWT signature was reported in Moxa network security devices and routers.

2. Violation of iss Claim Form (CVE-2025-30144)

fast-jwt before 5.0.6 has a validation flaw allowing string arrays in the iss claim, which should be a string from the perspective of RFC 7519. An attacker can bypass the validation logic by creating an iss array that combines legitimate and malicious issuers.

3. Insider Abuse Due to Failure in Rotating and Disposing of Signing Keys

If an organization operates a JWT signature key for a long time without performing key rotation or disposal procedures when a manager is changed or permissions are adjusted, valid JWTs can continue to be created using the leaked key. As long as the signature is verified correctly, the server and security system may mistake this for normal traffic, causing a delay in detection and resulting in the incident being identified only after an external report or investigation.

 

Detection and Defense Strategies

To respond to all JWT attack vectors, including internal key leakage, it is necessary to strengthen server-side validation logic and establish a real-time breach detection system.

 

1) Building a Secure Key Management System and Strategy to Replace HS256

1. Using Hardware Security Module (HSM) or Cloud KMS

A key aspect of countering insider threats is isolating the signature key data from the application server’s file system or memory. The signature key (secret key/private key) must be stored in an HSM (Hardware Security Module) or a cloud-based KMS (Key Management Service), and the application server must not handle the key value directly, instead using it by calling the signature operation API. This physically blocks insiders from gaining access to the key data even if they access the server.

2. Transition to Asymmetric Keys (RS256) and Key Rotation

To mitigate insider threats and reduce the risk of key exposure, the use of asymmetric keys (RS256) in a private key/public key structure should be given priority over the use of symmetric keys in a single shared structure (HS256). The private key is stored in the HSM/KMS, and the public key can be distributed externally. As long as the confidentiality of the private key is maintained, threat actors cannot forge valid tokens. Furthermore, operating procedures must be established based on the assumption that a breach is possible, defining the key’s lifespan and replacement cycle and regularly rotating and disposing of keys.

 

2) Implementing Strict Token Verification on the Server Side

Even when using a JWT library, developers must explicitly block all potential risks allowed by the standard specification.

1. Enforcing an Algorithm Whitelist

When validating JWT, the algorithm allowed by the server (e.g., RS256) must be explicitly fixed in the library. This blocks the acceptance of unsafe algorithms like alg=none and neutralizes algorithm confusion attacks.

2. Strict Validation of Critical Claims

Perform validation for standard claims such as exp (expiration time), iss (issuer), and aud (audience) without any omissions. When receiving an Access Token, the expiration time must be validated to block the use of expired tokens.

3. Defense of Key Reference Parameters

Dynamic key reference mechanisms such as kid, jku, and jwk provide injection attack vectors, so their use should be avoided. If their use is unavoidable, it is recommended to apply strong input filtering (whitelist-based) that includes path traversal and SQL injection patterns to the kid value.

 

3) Token Lifespan Management and Invalidation Strategies

1. Access Token Lifespan Management

Access Tokens should be issued with a short lifespan (expiring within a few minutes) to minimize the blast radius in case of a breach. Long-term session management should be separated using Refresh Tokens, and policies such as rotation and one-time use should be applied to the Refresh Tokens to prevent reuse.

2. Real-time Token Revocation System

A centralized Revocation List is established for immediate token invalidation in cases of key leakage or forced logout. Each API request queries the Revocation List based on the jti claim of the token, and blocks the request if it is found in the list. Revocation List items are automatically expired with TTL until the expiration time (exp) of the token.

 

4) Breach Detection and Monitoring System

1. Detailed Logging and SIEM Integration

Record JWT verification failure events (Invalid Signature, Algorithm Mismatch, Claim Errors, etc.) in detail and integrate them with a centralized SIEM system.

2. Suspicious Sign Detection System

Detect suspicious signs, such as excessive API calls with the same token in a short period of time (replay attack attempts), abnormal access distribution geographically, or tokens with an unusually long expiration time (exp), and generate immediate alerts to prevent further damage.

Conclusion

The security breach of a JWT-based authentication system can lead to a wide range of breaches against a company’s core assets. In particular, a failure in managing the signing key can elevate the breach to a high-risk single point of failure that disables the entire authentication system. Therefore, it is crucial to isolate the signing key within an HSM or KMS and prioritize tasks such as transitioning to an asymmetric key (RS256) and implementing key rotation policies. Strict verification logic must also be implemented, which includes algorithm locking, core claim verification, and key reference input defense, to reduce the possibility of a successful attack. Lastly, it is recommended to build an operational system that combines log-based detection with anomaly sign automation to identify breach signs early and minimize the damage.

 

Source

 

Gain access to related IOCs and detailed analysis by subscribing to AhnLab TIP. For subscription details, click the banner below.

Tags:
Previous Post

Next Post