LiveActive security incident?Get immediate response
CVE Record

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.

CriticalCVSS 9.1Not KEV-listedUpdated
Glexia's TakeAutomated analysiscritical

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.
Prepared
Confidence
high
Sources
6

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.

Open ATT&CK lookup
description · low confidence lookup

Credential and access behavior lookup

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.

Open ATT&CK lookup
cve · low confidence lookup

CVE-2026-75866 mapping review

Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Critical
CVSS
9.1 (3.1)
Known Exploited
No
Published

Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

Official CVE source material

CNA and ADP enrichment extracted from CVE v5

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.

ScoreVersionSeverityVectorExploitImpactSource
9.1CVSS 3.1CriticalCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N3.95.2CISA-ADP

Vulnerability scoring details

Base CVSS 3.1 score

9.1Critical
CVSS 3.1 vector shape for CVE-2026-75866Attack VectorAttack ComplexityPrivileges RequiredUser InteractionScopeConfidentiality ImpactIntegrity ImpactAvailability Impact

Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

Attack Vector
NetworkAdjacentLocalPhysical
Attack Complexity
LowHigh
Privileges Required
NoneLowHigh
User Interaction
NoneRequired
Scope
ChangedUnchanged
Confidentiality Impact
HighLowNone
Integrity Impact
HighLowNone
Availability Impact
HighLowNone

Vulnerability timeline

Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

ADP provider summaries

CVECVE Program Container
CISA-ADPCISA ADP Vulnrichment
cvssV3_1other:ssvc

Source materials

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
Unknown vendorPunk-OAuth2Punk-OAuth2, 0unaffected
Weakness

CWE details

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.