Auth0-PHP CVE-2025-68129

Applies to applications built on Auth0-PHP SDK v8.0.0-v8.17.0, or downstream SDKs depending on those versions: Auth0/laravel-auth0 7.0.0-7.19.0, Auth0/symfony 5.0.0-5.5.0, and the Auth0/wordpress plugin 5.0.0-BETA0-5.4.0. Exploitation requires that the application uses the SDK's token validation such that an ID token can be substituted where an access token is expected, and that the attacker can obtain a valid ID token from the target's Auth0 tenant (i.e., be able to authenticate or drive an authentication flow against that tenant). The limiting factor is therefore possession of a legitimately issued ID token for the specific tenant, not any special network position; unpatched deployments running the listed versions are the concrete exposure surface. Upgrading to Auth0-PHP 8.18.0 (or the corresponding fixed downstream releases: laravel-auth0 7.20.0, symfony 5.6.0, wordpress 5.5.0) remediates the issue.

This is an improper-authorization flaw (CWE-863) in the Auth0-PHP SDK where the audience (aud) claim of access tokens is validated improperly, allowing an application to accept an ID token where it expects an access token. The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, base 7.5) indicates a network-reachable, low-complexity, unauthenticated bypass with high confidentiality impact and no integrity/availability impact - consistent with an attacker presenting a token they can legitimately obtain (an ID token) to gain access to resources gated behind access-token validation. No EPSS score, SSVC decision, KEV entry, or POC was supplied in the intelligence; per precision rules this is 'no public exploit identified at time of analysis,' and there is no evidence of active exploitation. The real risk is moderate-to-serious rather than mass-exploitation-imminent: it is a genuine token-confusion authorization weakness in a security-critical component (an auth SDK), but it requires the affected app to be built on vulnerable Auth0-PHP versions and to be misusing/relying on the SDK's token type distinction, and exploitation depends on the attacker being able to obtain a valid ID token for the target tenant. The signals are internally consistent (no conflicts); the main caveat is the absence of exploitation-probability data, so prioritization should be driven by whether the environment actually runs the affected SDK versions rather than by a threat-intel signal.

An attacker who can authenticate to the target's Auth0 tenant (e.g., as a legitimate low-value user or via a client they control) obtains an ID token, which is normally only intended to identify the user to the client application. Because the SDK skips proper audience validation for access tokens, the attacker submits that ID token to an endpoint that expects an access token, and the application accepts it as valid - granting API/resource access it should not. No public exploit code is identified, but the attack is low-complexity and requires no elevated privileges once a token is obtained.