CVE-2025-68129: Auth0-php Authentication Bypass Vulnerability

CVE-2025-68129 Overview

CVE-2025-68129 is an authorization flaw [CWE-863] in the Auth0-PHP SDK affecting audience validation for access tokens. The SDK improperly appends the client ID to the accepted audience list when validating access tokens. As a result, applications may accept ID tokens where an access token is required, breaking the security boundary between the two token types. The flaw impacts Auth0-PHP versions 8.0.0 through 8.17.0, as well as downstream SDKs including auth0/symfony, auth0/laravel-auth0, and the auth0/wordpress plugin. Auth0 released a patch in Auth0-PHP 8.18.0.

Critical Impact
Attackers holding a valid ID token can present it to protected API endpoints and have it accepted as an access token, enabling unauthorized access to resources.

Affected Products

auth0/auth0-php versions 8.0.0 through 8.17.0
auth0/laravel-auth0 versions 7.0.0 through 7.19.0 and auth0/symfony versions 5.0.0 through 5.5.0
auth0/wordpress plugin versions 5.0.0-BETA0 through 5.4.0

Discovery Timeline

2025-12-17 - CVE-2025-68129 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-68129

Vulnerability Analysis

The Auth0-PHP SDK validates JSON Web Tokens (JWTs) using a shared code path for both ID tokens and access tokens. During validation, the SDK constructed the list of accepted aud (audience) values by appending the application's client ID to the caller-supplied audience array. This is correct behavior for ID tokens, where the client ID is the intended audience. It is incorrect for access tokens, whose audience should be the resource API identifier only.

Because the client ID was added unconditionally, an ID token minted for the same tenant would satisfy the audience check when the application expected an access token. Downstream Laravel, Symfony, and WordPress integrations inherit the flaw through their dependency on the vulnerable SDK.

Root Cause

The root cause is an improper authorization check [CWE-863] in src/Token.php. The validator did not differentiate between token types before augmenting the audience array with the client ID, allowing type confusion between ID tokens and access tokens.

Attack Vector

The attack is network-based, requires no privileges, and requires no user interaction. An attacker who obtains an ID token issued by the same Auth0 tenant, for example through a legitimate login flow, can submit that token as a bearer credential to API endpoints that enforce access-token validation via the Auth0-PHP SDK. The SDK accepts the token and the request proceeds under the identity encoded in the ID token.

php

// Patch: src/Token.php
$tokenOrganization ??= $this->configuration->getOrganization() ?? null;
$tokenMaxAge ??= $this->configuration->getTokenMaxAge() ?? null;
$tokenLeeway ??= $this->configuration->getTokenLeeway() ?? 60;
-        $tokenAudience[] = (string) $this->configuration->getClientId();
+        if ($this->type !== self::TYPE_ACCESS_TOKEN) {
+            $tokenAudience[] = (string) $this->configuration->getClientId();
+        }
$tokenAudience = array_unique($tokenAudience);

$validator = $this->getParser()->validate();

Source: Auth0-PHP commit 7fe7000. The fix wraps the client-ID append with a type check so it applies only to non-access tokens.

Detection Methods for CVE-2025-68129

Indicators of Compromise

API requests presenting JWTs whose aud claim equals the application client ID rather than the expected API identifier
JWTs carrying an at_hash, nonce, or sid claim reaching API endpoints, indicating an ID token used as a bearer credential
Authenticated API activity that does not correlate to a preceding /oauth/token exchange for the same subject

Detection Strategies

Parse bearer tokens at the application or gateway layer and reject any whose aud claim does not match the configured API audience
Audit dependency manifests (composer.lock) for auth0/auth0-php versions < 8.18.0 and the affected Laravel, Symfony, and WordPress packages
Enable Auth0 tenant log streaming and correlate Success Login events with subsequent API access patterns to detect token-type misuse

Monitoring Recommendations

Ship Auth0 logs and application access logs to a centralized analytics platform and alert on tokens whose audience does not match the resource server
Track anomalies in bearer-token claim shape, such as the presence of nonce or at_hash in tokens sent to API endpoints
Monitor SCA (software composition analysis) reports for advisories GHSA-j2vm-wrq3-f7gf, GHSA-7hh9-gp72-wh7h, GHSA-f3r2-88mq-9v4g, and GHSA-vvg7-8rmq-92g7

How to Mitigate CVE-2025-68129

Immediate Actions Required

Upgrade auth0/auth0-php to 8.18.0 or later in every affected project
Upgrade downstream integrations: auth0/laravel-auth0 to 7.20.0, auth0/symfony to 5.6.0, and auth0/wordpress to 5.5.0
Redeploy applications after upgrading and invalidate long-lived sessions if ID-token misuse is suspected

Patch Information

Auth0 fixed the flaw in Auth0-PHP 8.18.0 via commit 7fe7000. The change conditions the client-ID audience augmentation on the token type. Downstream packages bump the SDK constraint to ^8.18. See Auth0-PHP 8.18.0 release, laravel-auth0 7.20.0, symfony 5.6.0, and wordpress 5.5.0.

text

"require": {
    "php": "^8.2",
    "ext-json": "*",
-    "auth0/auth0-php": "^8.17",
+    "auth0/auth0-php": "^8.18",

Source: laravel-auth0 commit a1c3344.

Workarounds

If patching is delayed, add middleware that inspects the aud claim of every bearer token and rejects tokens whose audience is the client ID rather than the API identifier
Reject tokens containing ID-token-only claims such as nonce or at_hash at API endpoints
Reduce ID-token lifetimes in the Auth0 tenant to shrink the window in which a leaked ID token can be replayed as an access token

bash

# Upgrade the vulnerable dependency across affected projects
composer require auth0/auth0-php:^8.18
composer require auth0/laravel-auth0:^7.20
composer require auth0/symfony:^5.6
# WordPress: update the auth0 plugin to 5.5.0 via wp-admin or wp-cli
wp plugin update auth0