Skip to content

GHSA-mg4f-x9v4-6h2p CVE-2026-55982 GO-2026-6065

Gitea: OIDC userinfo Endpoint Returns Identity Claims Without Enforcing API Token Scopes

Critical Go
Severity
0.0 / 10
Critical · CVSS 4.0
Exploit chance (EPSS)
0.51%
Chance of exploitation in the next 30 days. Higher than 43.19% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-200 Exposure of Sensitive Information to an Unauthorized Actor
Fix
Available
2 packages have a fixed version

Description

Summary

The OIDC userinfo endpoint (GET /login/oauth/userinfo) accepts Gitea API tokens as bearer credentials but does not enforce API token scopes before returning identity claims.

A personal access token scoped only to read:misc can successfully retrieve user information from the OIDC userinfo endpoint, even though the same token is denied access to user-related REST API endpoints that enforce scope checks.

As a result, identity information remains accessible through the OIDC endpoint regardless of the scopes assigned to the API token.

Details

Gitea supports scoped personal access tokens and enforces scope checks on user-related REST API endpoints.

For example, a token scoped only to read:misc is denied access to endpoints such as:

Endpoint Required Scope
GET /api/v1/user read:user
GET /api/v1/user/emails read:user
GET /api/v1/user/orgs read:organization

Requests to these endpoints return:

403 Forbidden

with a scope-related error.

However, the same read:misc token can be supplied as a bearer credential to:

GET /login/oauth/userinfo
Authorization: Bearer <token>

and receives a successful response containing identity claims.

Observed claims include:

  • email
  • groups

The groups claim contains organization and team membership information associated with the authenticated user.

This behavior indicates that the OIDC userinfo endpoint accepts API tokens but does not apply scope restrictions before returning identity claims.

PoC

PoC Details

Proof-of-concept code: https://anonymous.4open.science/r/Gitea_PoC-EC93/3_poc_oidc_userinfo_scope_bypass

Reproduction Steps

  1. Create a personal access token with only the following scope:
read:misc
  1. Verify that the token cannot access user-related REST API endpoints:
GET /api/v1/user
GET /api/v1/user/emails
GET /api/v1/user/orgs

Each request returns:

403 Forbidden
  1. Send the same token to the OIDC userinfo endpoint:
GET /login/oauth/userinfo
Authorization: Bearer <read-misc-token>
  1. Observe that the request succeeds and returns identity claims, for example:
{
  "email": "user@example.com",
  "groups": [
    ...
  ]
}

Impact

Holders of narrowly scoped API tokens can obtain identity information through the OIDC userinfo endpoint regardless of the scopes assigned to the token.

The issue does not provide access to repositories, issues, pull requests, administrative functionality, or data belonging to other users.

Impact is limited to disclosure of identity information associated with the authenticated user. However, it weakens the authorization boundary established by API token scopes because identity claims remain accessible even when the token lacks user- or organization-related scopes.

Affected versions

Go

PackageVulnerableFixed in
code.gitea.io/gitea
< 1.27.0
1.27.0
gitea.dev
< 1.27.0
1.27.0

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

code.gitea.io/gitea Go → 1.27.0

go
go get code.gitea.io/gitea@v1.27.0 && go mod tidy

gitea.dev Go → 1.27.0

go
go get gitea.dev@v1.27.0 && go mod tidy

Severity breakdown

CVSS 4.0 0.0

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

Attack vector
Network
Attack complexity
Low
Attack requirements
None
Privileges required
Low
User interaction
None
Confidentiality (vulnerable system)
Low
Integrity (vulnerable system)
None
Availability (vulnerable system)
None
Confidentiality (subsequent systems)
None
Integrity (subsequent systems)
None
Availability (subsequent systems)
None

CVSS 3.1 9.1

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

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
None

Weakness

CWE-200: Exposure of Sensitive Information to an Unauthorized Actor

The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.

How to prevent it
  • Architecture and Design: Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-rcr6-4jqh-j84m
Gitea: Remote Code Execution via diffpatch Git Hook Installation
Critical Known exploited Also affects code.gitea.io/gitea
GHSA-fq2p-5p22-8g6j
Gitea: Public-Only Personal access tokens scope bypass in Organization and Permission Endpoints
Medium Also affects code.gitea.io/gitea
GHSA-2wm4-vwp6-v7xc
Gitea: SSRF via Migration Asset Downloads Bypasses hostmatcher — Reads Internal Files and Cloud Metadata
High Also affects code.gitea.io/gitea
GHSA-3r5c-2xxx-h872
Gitea: Webhook Authorization Header Returned in Plaintext via API
Low Also affects code.gitea.io/gitea
GHSA-frpw-3h2q-4jj6
Gitea: Cross-Repo Information Disclosure via Org-Level Actions Run/Job APIs
Medium Also affects code.gitea.io/gitea
GHSA-q423-49rw-g9mh
Gitea: GHSA-8fwc-qjw5-rvgp ClearRepoWatches fix not applied to API EditRepo path — sister code path retains stale watches on public->private
Medium Also affects code.gitea.io/gitea
GHSA-h56g-4qw7-2mxg
Gitea: Public-only API token restriction is not enforced on team API routes
Medium Also affects gitea.dev
GHSA-prr9-9mp4-5gp2
Gitea: Private org member list leaked via /members API endpoint — incomplete fix for PR #38145
High Also affects gitea.dev
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor