auth0.js EUVD-2026-100483

Exploitation is only possible when the integrating application actually calls auth0.js authorize() with a maxAge parameter AND relies on that value to enforce recent authentication (e.g. step-up auth before sensitive operations) on an affected version (9.12.0 to <10.3.0). The limiting factors are significant: applications that do not use maxAge are unaffected, and an actor must already possess or leverage a valid-but-older authentication event/session rather than forging arbitrary credentials - the flaw weakens a freshness guarantee rather than granting unauthenticated access. PR:L indicates an authenticated context is required; the fix (>=10.3.0) adds the missing auth_time validation.

This is a moderate-severity authentication-control weakness (CVSS 5.4, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N) in the auth0.js client library, reported by Okta PSIRT with a patch available. The flaw (CWE-613, Insufficient Session Expiration) means the library silently ignores the maxAge parameter's re-authentication guarantee by not validating the ID token's auth_time claim. No EPSS score, KEV listing, or public POC was provided in the input, so there is no signal of active or probable near-term exploitation; this should be treated as a hygiene/defense-in-depth fix rather than an emergency patch. No SSVC decision data was supplied. The vendor CVSS vector lists PR:L (authenticated) and C:L/I:L, implying limited impact that depends on an application actually relying on maxAge for step-up or recent-authentication enforcement - applications that never request maxAge are effectively unaffected. The practical risk is bounded: this is a real priority only for apps using maxAge to gate sensitive actions, and low priority otherwise. Note the input provides no EPSS/KEV/POC data at all - absence of those signals is not evidence of safety, but no exploitation evidence exists in the provided intelligence.

An application uses auth0.js authorize() with a maxAge value to force recent re-authentication before a sensitive operation (e.g. changing payment details). Because the library never checks the returned ID token's auth_time against maxAge, a user (or an actor leveraging a still-valid older authentication session) can pass this gate using a stale authentication event, bypassing the intended step-up/recent-login requirement. No public exploit code was identified in the provided data.