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 grant_types per client and documents both as client registration. token dispatches on the grant_type in the request body, so a client registered for authorization_code alone can ask for client_credentials, 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. redirect_uris 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 client_id alone, so anyone who knows that identifier can request one.
Security readout for executives and security teams
Plain-English summary
Punk::OAuth2::Server through version 0.03 can issue valid access tokens with permissions or login flows not approved for the requesting client. An attacker with a registered client identifier—and potentially no secret—could gain unauthorized access or modify protected data if downstream services trust those token claims.
Executive priority
Treat affected production identity infrastructure as an immediate remediation priority. Compromise could bypass application authorization while producing correctly signed tokens that appear legitimate downstream. Prioritize systems protecting sensitive or write-capable APIs, then investigate previously issued tokens and suspicious client activity.
Technical view
The server records client scopes and grant types but does not enforce them during authorization or token issuance. Requested scopes can be copied into authorization codes or signed directly into at+jwt tokens. Punk::OAuth2::Checker then accepts those signed scopes. Public clients without secrets may authenticate using only a known client_id. Redirect URI validation remains enforced.
Likely exposure
Exposure is likely where Punk::OAuth2::Server 0.03 or earlier issues tokens and protected services rely on Punk::OAuth2::Checker. Risk increases for internet-accessible token endpoints, guessable or disclosed client identifiers, clients without secrets, and high-privilege scopes. The supplied version metadata is inconsistent, so confirm installed package versions directly.
Exploitation context
The flaw is remotely reachable, low complexity, and requires no user interaction. A registered client can request unauthorized grant types or scopes; clients without secrets may be impersonated using their identifiers. The source bundle reports no CISA KEV listing, and no supplied source confirms active exploitation or public weaponization.
Researcher notes
The defect is an authorization-enforcement failure consistent with CWE-862. Scope validation is absent in both described authorization-code and client-credentials paths, while grant-type registration is not consulted during token dispatch. RFC 6749 requires invalid or excessive scope requests to be rejected. Evidence does not establish broader OAuth implementations as affected.
Mitigation direction
Identify and prioritize every deployment running Punk::OAuth2::Server through 0.03.
Review the 0.04 release notes and upgrade according to current package guidance.
Restrict token endpoints and disable unnecessary clients until remediation is verified.
Rotate exposed client identifiers and secrets where practical after remediation.
Review and revoke tokens containing scopes or grant types not registered to their clients.
Validation and detection
Inventory installed Punk-OAuth2 versions and all services trusting its signed tokens.
Compare issued token scopes and grant types against each client's registered values.
Confirm clients without secrets cannot obtain privileges beyond their registrations.
Review token and authorization logs for unexpected scopes, grant types, or client activity.
After updating, test that unauthorized scope and grant requests are rejected.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · medium confidence lookup
CWE-862: Authorization and privilege behavior lookup
Authorization weaknesses can support privilege escalation and valid-account review, depending on exploit path. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
The CVE wording references authentication or credential exposure, so valid-account and credential-access review may help. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
2ADP providers
4Source links
SSVC decision data
CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: noneAutomatable: yesTechnical Impact: total
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-862 · source CWE mapping
Missing Authorization
Missing Authorization represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.