Four Auth0 SDK Advisories: auth0.js, Lock, java-jwt and nextjs-auth0

On 13 October 2026 Okta published four advisories for Auth0 client libraries: auth0.js, auth0-lock, nextjs-auth0 and auth0/java-jwt. None is critical on its own, with CVSS scores between 5.3 and 6.1. But these libraries sit inside login flows across many web and Java apps, and each bug breaks a specific promise your app makes about authentication.

What's affected

auth0.js. When an app passes maxAge to authorize(), it's asking for a recent login, often before a sensitive action. Affected versions didn't compare the ID token's auth_time to that value, so a token from an older login was accepted. GHSA-42v6-5rcc-mq4v.

nextjs-auth0. The SDK checked that returnTo was same-origin, then stored it and rebuilt it later. The rebuilt value could be one that browsers read as absolute or scheme-relative, sending a freshly logged-in user to another domain. GHSA-5vvp-h2v6-59j6.

auth0-lock. If a user typed a username that was only a domain, such as @corp.com, on an Active Directory connection, Lock started the transaction with a GET instead of a POST. The form data landed in the query string, where proxies, browser history and server logs pick it up.

java-jwt. A JWT with an out-of-range exp, nbf or iat could terminate the thread parsing it. That happens before signature verification, so no valid key is needed. GHSA-cg7w-5cc2-f2xm.

How to check if you're exposed

For JavaScript projects:

npm ls auth0-js auth0-lock @auth0/nextjs-auth0 2>/dev/null

Then check whether the vulnerable feature is in use:

# auth0.js: is maxAge passed per request?
grep -rnE "authorize\(|maxAge|max_age" src/ | grep -i -E "maxage|max_age"

# nextjs-auth0: do you build login links with returnTo?
grep -rn "returnTo" app/ pages/ src/ 2>/dev/null

For Java:

mvn dependency:tree -Dincludes=com.auth0:java-jwt
# or
gradle dependencies --configuration runtimeClasspath | grep java-jwt

If you'd rather not run tooling, the free scan at https://gold.safeguard.sh/scan reads a package.json or a CycloneDX or SPDX SBOM in the browser, and the file never leaves your machine. It handles up to 100 dependencies per scan.

What to do now

1. Upgrade. auth0-js to 10.3.0 or later. @auth0/nextjs-auth0 to 4.32.0 or later. auth0-lock to 15.0.2 or later, or 13.2.1 if you're pinned to the 13.x line. com.auth0:java-jwt to 4.6.2 or later.
2. Check auth_time server-side too. If an API relies on recent authentication, have the API verify auth_time itself rather than trusting the front end to have checked it.
3. Restrict returnTo to known paths. Even after the fix, accept only relative paths that start with a single /, and reject anything starting with // or containing a scheme.
4. Scrub logs for Lock's GET requests. Search web server and proxy logs for Auth0 authorize or login URLs carrying password= in the query string. If you find any, purge those entries and have the affected users change their passwords.
5. Contain java-jwt parsing failures. Make sure JWT parsing runs inside request handling that catches errors and doesn't take a worker thread down with it. Rate-limit unauthenticated requests carrying bearer tokens.

Why it matters

These four bugs are a tidy map of where token handling usually breaks. Freshness checks get skipped, because they only matter in step-up flows that few people test. Redirect validation happens at one point and then the value is transformed later. Form submission methods change based on an edge case nobody expected users to hit. And parsers do work on untrusted input before verifying the signature.

Most teams pin auth SDKs once and leave them. That's understandable, since an auth library upgrade can break login. But it means advisories like these sit unpatched for a long time, and auth libraries are exactly where small bugs have outsized consequences.

Try it yourself

Run npm ls auth0-js auth0-lock @auth0/nextjs-auth0 in one repository, then grep for maxAge and returnTo. If the vulnerable version is present but the feature is never called, that lowers urgency for that bug, though it doesn't remove it. Asking "does our code call the vulnerable path?" is what reachability analysis automates.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• CVE-2026-107371: Missing Verification of auth_time Claim in auth0.js
• CVE-2026-107369: Improper Validation of Post-Login Redirect URL in nextjs-auth0
• CVE-2026-107370: Improper Request Handling for Active Directory Logins in auth0-lock
• CVE-2026-85473: Out-of-Range Timestamp Claim Handling in auth0/java-jwt
• Okta security advisories index