CVE-2025-46344

Executive Summary

CVE-2025-46344 is a security vulnerability in the Auth0 Next.js SDK, a library used for implementing user authentication in Next.js applications. The flaw exists in versions 4.0.1 through 4.5.0, where the SDK fails to invoke .setExpirationTime when generating a JWE (JSON Web Encryption) token for the session. This omission means the JWE token lacks an internal expiration claim, allowing it to remain valid indefinitely even after the session cookie has expired or been cleared. An attacker who obtains a valid JWE token can reuse it beyond its intended lifespan, potentially gaining unauthorized access to user sessions. The vulnerability has been patched in version 4.5.1.

Supply Chain & Package Security

This vulnerability affects the @auth0/nextjs-auth0 npm package. Organizations using this package in their Next.js applications should immediately audit their dependency tree to ensure they are not using a vulnerable version. The package is widely used in the Node.js ecosystem for integrating Auth0 authentication into Next.js applications. Supply chain risk is elevated because the flaw is in the session token generation logic, which is a core security function. Developers should verify the integrity of the package and consider using lock files (e.g., package-lock.json) to prevent automatic updates to vulnerable versions.

CVSS Breakdown & Threat Level

CVSS Score: 0.0 (NVD) | Adjusted Score: 5.3 (Medium)

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

• Attack Vector (AV): Network – The vulnerability can be exploited remotely.
• Attack Complexity (AC): Low – No special conditions are required.
• Privileges Required (PR): None – No authentication needed to exploit.
• User Interaction (UI): None – No user action required.
• Scope (S): Unchanged – The exploit does not affect other components.
• Confidentiality (C): Low – Potential exposure of session data.
• Integrity (I): Low – Potential for session manipulation.
• Availability (A): None – No impact on availability.

Threat Level: Medium. The vulnerability allows for session token reuse, which could lead to unauthorized access. However, exploitation requires the attacker to first obtain a valid JWE token, which may require additional steps such as intercepting network traffic or accessing the user's browser storage.

Deep Dive & Mechanics

The Auth0 Next.js SDK uses JWE (JSON Web Encryption) to securely store session data. JWE tokens typically include an exp (expiration) claim that defines when the token should no longer be considered valid. In vulnerable versions, the SDK does not call .setExpirationTime when creating the JWE token. This results in a token that has no internal expiration, meaning it will be accepted by the server as long as it is cryptographically valid.

The session cookie itself may have an expiration set by the application, but the JWE token inside the cookie does not. If an attacker extracts the JWE token from a session cookie (e.g., via XSS, network interception, or physical access), they can reuse that token even after the original session cookie has expired. The server will decrypt the JWE token and accept it because there is no expiration check on the token itself.

The fix in version 4.5.1 ensures that .setExpirationTime is called, embedding an expiration claim into the JWE token. This aligns the token's validity with the session cookie's expiration, preventing indefinite reuse.

Vulnerable vs. Patched Code

Vulnerable Code (versions 4.0.1 to 4.5.0):

// In the session creation logic, the JWE token is generated without setting expiration
const jwe = await new JWE.Encrypt(sessionData)
  .setProtectedHeader({ alg: 'dir', enc: 'A256GCM' })
  .encrypt(encryptionKey);
// Missing: .setExpirationTime(expiresAt)

Patched Code (version 4.5.1):

// The fix adds .setExpirationTime to the JWE generation
const jwe = await new JWE.Encrypt(sessionData)
  .setProtectedHeader({ alg: 'dir', enc: 'A256GCM' })
  .setExpirationTime(expiresAt) // Added line
  .encrypt(encryptionKey);

The key difference is the addition of .setExpirationTime(expiresAt), which embeds the expiration claim into the JWE token. This ensures that the token itself has a limited lifespan, even if the session cookie is not properly cleared.

Exploitation & Lab Setup

Red Team

Prerequisites:

• A Next.js application using @auth0/nextjs-auth0 version 4.0.1 to 4.5.0.
• Ability to intercept or extract a session cookie (e.g., via XSS, man-in-the-middle, or physical access).

Exploitation Steps:

1. Obtain a valid session cookie from a user. This can be done through cross-site scripting (XSS), network sniffing, or by accessing the user's browser storage.
2. Extract the JWE token from the session cookie. The cookie typically contains the JWE token as its value.
3. Wait for the session cookie to expire (e.g., after the user logs out or the cookie's Max-Age is reached).
4. Reuse the JWE token by setting it as a new session cookie in the browser or by sending it directly to the server in an HTTP request.
5. Access protected resources as the original user, since the server will decrypt the JWE token and accept it without checking expiration.

Example using curl:

# Assume the JWE token is "eyJhbGciOiJkaXIiLCJlbmMiOiJBMjU2R0NNIn0..."
curl -X GET https://target-app.com/api/protected \
  -H "Cookie: appSession=eyJhbGciOiJkaXIiLCJlbmMiOiJBMjU2R0NNIn0..."

Blue Team

Detection:

• Monitor for session cookies that are reused after their expected expiration time.
• Look for anomalies in session token usage, such as tokens being used from different IP addresses or user agents.
• Implement logging of JWE token validation failures (though in this case, there will be no failures due to missing expiration).

Mitigation:

• Immediately upgrade to @auth0/nextjs-auth0 version 4.5.1 or later.
• If immediate upgrade is not possible, implement additional session validation at the application level, such as checking the session creation time against a server-side store.
• Use short-lived session cookies and enforce re-authentication for sensitive actions.

Lab Setup:

1. Create a Next.js application with @auth0/nextjs-auth0@4.5.0.
2. Configure Auth0 authentication.
3. Log in as a user and capture the session cookie.
4. Log out and wait for the cookie to expire.
5. Reuse the captured cookie to access protected routes.

Indicators of Compromise (IOCs)

• Session cookies that contain JWE tokens without an exp claim. Decode the JWE token (if possible) to check for the absence of an expiration field.
• Unusual session reuse patterns, such as the same session token being used from different IP addresses or after a long period of inactivity.
• Log entries showing successful authentication with tokens that should have expired.

Example IOC (JWE token without expiration):

eyJhbGciOiJkaXIiLCJlbmMiOiJBMjU2R0NNIn0..encrypted_data

(Note: The token may not be decodable without the encryption key, but the absence of an exp claim in the JWE header or payload is indicative.)

Detection Engineering

YARA Rule

rule CVE_2025_46344_Auth0_JWE_No_Expiration {
    meta:
        description = "Detects JWE tokens in Auth0 Next.js SDK that lack expiration claim"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-46344"
    strings:
        $jwe_header = "eyJhbGciOiJkaXIiLCJlbmMiOiJBMjU2R0NNIn0" // base64 of {"alg":"dir","enc":"A256GCM"}
        $jwe_payload = /[A-Za-z0-9-_]+\.[A-Za-z0-9-_]+\.[A-Za-z0-9-_]+/ // JWE format
    condition:
        $jwe_header and $jwe_payload and not contains("exp")
}

Sigma Rule

title: Auth0 Next.js SDK JWE Token Without Expiration
id: 8a4b3c2d-1e5f-4a7b-9c8d-0e1f2a3b4c5d
status: experimental
description: Detects session cookies containing JWE tokens that lack an expiration claim, indicating CVE-2025-46344 exploitation.
author: Valters IT
date: 2025-04-10
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2025-46344
logsource:
    category: application
    product: nextjs
detection:
    selection:
        cs-cookie|contains: "appSession"
    filter:
        cs-cookie|contains: "exp"
    condition: selection and not filter
falsepositives:
    - Legitimate tokens that have not yet been updated to include expiration
level: medium

Suricata Rule

alert http any any -> any any (msg:"CVE-2025-46344 Auth0 Next.js SDK JWE Token Without Expiration"; flow:to_server; http.cookie; content:"appSession"; nocase; pcre:"/appSession=[A-Za-z0-9-_]+\.[A-Za-z0-9-_]+\.[A-Za-z0-9-_]+/"; pcre:"!/exp/"; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade the @auth0/nextjs-auth0 package to version 4.5.1 or later.

   npm install @auth0/nextjs-auth0@^4.5.1
   

2. Invalidate all existing sessions after the upgrade to ensure no stale JWE tokens remain valid.
3. Review application logs for any signs of token reuse or unauthorized access.

Long-Term Mitigations:

• Implement additional session validation, such as storing session creation timestamps in a database and checking them on each request.
• Use short session cookie lifetimes and enforce re-authentication for sensitive operations.
• Monitor for unusual session behavior using the detection rules provided above.
• Conduct a security audit of all dependencies to ensure no other similar vulnerabilities exist.

Workaround (if upgrade is not possible):

• Implement a custom middleware that checks the session creation time against a server-side store and rejects tokens that are too old.
• However, this is not a complete fix and should only be used as a temporary measure.

Valters IT
Securing Digital Frontiers