+ "details": "### Impact\nAuthentication Bypass for `client_credentials` tokens. the league/oauth2-server library sets the JWT sub claim to the client identifier (since there's no user). The token guard then passes this value to retrieveById() without validating it's actually a user identifier, potentially resolving an unrelated real user. Any machine-to-machine token can inadvertently authenticate as an actual user.\n\n\nUsage of `EnsureClientIsResourceOwner` middleware together with `Passport::$clientUuids` set to `false`, can result in resolving the user instead, as stated in the [documentation](https://laravel.com/docs/13.x/passport#:~:text=The%20underlying%20OAuth2,client%20credentials%20token). \n\n> The [underlying OAuth2 server](https://oauth2.thephpleague.com/database-setup/#:~:text=Please%20note%20that,the%20bearer%20token.) sets the token's sub claim to the client's identifier for client credentials tokens. By default, Passport uses UUIDs for clients, so this cannot collide with a user's integer primary key. However, if you have set Passport::$clientUuids to false, a client credentials token may inadvertently resolve a user whose ID matches the client's ID. In such cases, using this middleware cannot guarantee that the incoming token is a client credentials token.\n\n### Patches\nPatched in v13.7.1\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\nDisallow usage of `client_credentials`. \n\n\n### References\n- https://github.com/laravel/passport/issues/1900\n- https://github.com/laravel/passport/pull/1901\n- https://github.com/laravel/passport/pull/1902\n- https://github.com/thephpleague/oauth2-server/issues/1456#issuecomment-2734989996",
0 commit comments