CVE-2026-75866: Punk::OAuth2::Server versions through 0.03 for Perl issue access tokens outside a client's registered scopes and grant types because no authorization path reads them
Punk::OAuth2::Server versions through 0.03 for Perl issue access tokens outside a client's registered scopes and grant types because no authorization path reads them.
Punk::OAuth2::Server::Store registers scopes and granttypes per client and documents both as client registration. token dispatches on the granttype in the request body, so a client registered for authorizationcode alone can ask for clientcredentials, and that arm passes the requested scope straight to the minter, which signs it into the at+jwt access token. authorize copies the query scope into the authorization code record without comparing it against the registration, leaving the optional consent hook as the only check between an arbitrary scope and the issued code. redirecturis on the same client row is read and enforced.
A registered client can obtain a correctly signed token carrying any scope it names, and a resource server running Punk::OAuth2::Checker accepts that token and honours the scope. A client registered without a secret authenticates on its clientid alone, so anyone who knows that identifier can request one.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Punk::OAuth2::Server (Perl)to a version that resolves this vulnerability.Fixed in 0.04
Event History
Frequently Asked Questions
Which clients are exposed to unauthorized token issuance?
Any registered client can request a token using a grant type or scope outside its registration because the authorization paths do not read the registered scopes or grant_types. Clients registered without a secret are especially exposed: anyone who knows the client_id can authenticate as that client and request a token.
Are redirect URI restrictions also bypassed?
No. The client's redirect_uris are read and enforced. The missing enforcement concerns registered scopes and grant_types.
Can this affect both authorization-code and client-credentials flows?
Yes. A client registered only for authorization_code can request client_credentials, and the requested scope is passed to the token minter. In the authorization-code path, the requested query scope is copied into the authorization code without comparison to the client's registered scopes.
When will an improperly scoped token be accepted by a protected service?
A resource server using Punk::OAuth2::Checker accepts the correctly signed at+jwt access token and honors the scope embedded in it. This means a token issued with an arbitrary requested scope can be treated as authorized by such a resource server.