What is the CVSS score of CVE-2026-55982?

CVE-2026-55982 has a CVSS 3.1 base score of 9.1 (Critical). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. EPSS exploitation probability: 0.2%.

How to fix or mitigate CVE-2026-55982?

Within 24 hours: Identify all Gitea instances and their current versions; audit which users hold personal access tokens and when they were issued. Within 7 days: Deploy Gitea 1.27.0 or later to all affected instances, immediately revoking all active personal access tokens and requiring users to re-authenticate and request new tokens with explicitly configured minimal scopes. Within 30 days: Audit the userinfo endpoint access logs for the past 90 days to identify any tokens used to retrieve identity claims outside their intended scopes; notify affected users if their profile information was accessed without authorization and review token scope policies to implement principle of least privilege.

Gitea CVE-2026-55982

Q: Which versions of Gitea are affected by CVE-2026-55982?

Gitea self-hosted Git servers before version 1.27.0 permit any token-holder to access organization team membership and email addresses through an authorization bypass, regardless of their token's…. A patch is available.

EUVD-2026-58138 CRITICAL

Information Exposure (CWE-200)

2026-07-21 https://github.com/go-gitea/gitea

GHSA-mg4f-x9v4-6h2p

Information Disclosure Gitea

9.1

CVSS 3.1 · Vendor: https://github.com/go-gitea/gitea

View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

Access

Obtain narrowly scoped Gitea API token
Exploit

Send token as bearer to /login/oauth/userinfo
Execution

Endpoint skips scope enforcement
Impact

Receive email and org/team groups claims

Vulnerability Assessment

Weakness	CWE CWE-200 OWASP Top 10:2025 A01:2025 - Broken Access Control ASVS 5.0 V14 - Data Protection Data exposure prevention MITRE ATT&CK 2 techniques across 2 tactics: Collection, Discovery The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. Sign in to read
Exploitation Conditions	Requires possession of a valid Gitea personal access token for the target instance - any scope suffices, including tokens deliberately restricted to read:misc that are denied by /api/v1/user, /api/v1/user/emails, and /api/v1/user/orgs. The attacker must be able to reach the /login/oauth/userinfo endpoint over the network. Limiting factors: it is not anonymous/unauthenticated (a token is mandatory, so despite the CVSS PR:N this behaves as an authenticated flaw), the disclosure is confined to the authenticated token holder's own identity claims (email and their org/team membership) with no access to other users' data, repositories, issues, or admin functions, and only Gitea versions < 1.27.0 are affected.
Impact	The signals conflict sharply and the headline CVSS 9.1 (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:N) overstates real-world risk. The vendor's own advisory states there is no repository, issue, admin, integrity, or cross-user impact - so I:H is not supportable and PR:N is questionable because exploitation requires possession of a valid Gitea API token (a privilege), not anonymous access. The concrete impact is disclosure of the authenticated user's own email and their organization/team membership (the groups claim), which is a genuine but bounded confidentiality issue. EPSS is low (0.17%, 7th percentile) and there is no KEV listing, consistent with a low-urgency information-disclosure bug rather than a mass-exploitation threat, even though public PoC code exists. The practical priority is: patch on a normal maintenance cadence; the flaw matters most where PAT scoping is relied on as a security control (e.g. tokens minted for third-party integrations that should not learn a user's org/team graph), in which case the scope-bypass weakens a boundary operators explicitly configured. Bottom line: treat the vendor-provided 9.1 as inflated and rank this as Medium in your own triage rather than Critical.
Exploit ScenarioDerived	An organization issues a narrowly scoped Gitea PAT (only read:misc) to a low-trust CI job or third-party service, expecting it cannot read the user's identity or org/team graph. The service instead sends that token as a bearer credential to GET /login/oauth/userinfo and receives the user's email and full group/team membership. Public PoC code demonstrates the bypass, and because complexity is low, any token holder can reproduce it with a single HTTP request.

Act Now Prioritize within 24-48h. Why: CRITICAL severity.

Patch available 0.2% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv2 – Aug 14, 2026

Identity-claim disclosure in Gitea (self-hosted Git server) before 1.27.0 lets any holder of a valid personal access token retrieve their email and organization/team membership from the OIDC userinfo endpoint (GET /login/oauth/userinfo) even when the token's scopes (e.g. only read:misc) would deny the equivalent REST API calls. The endpoint accepts API tokens as bearer credentials but skips the scope enforcement applied elsewhere, collapsing the authorization boundary that scoped tokens are meant to provide. Publicly available exploit code exists; the flaw is not in CISA KEV and EPSS is low (0.17%).

Earlier versions of this analysis (1)

v1 Jul 21, 2026 - 21:19

Gitea's OIDC userinfo endpoint (GET /login/oauth/userinfo) bypasses API token scope enforcement, exposing email addresses and organization/team membership to any valid token holder regardless of assigned scopes. A token scoped exclusively to read:misc - which is correctly denied access to /api/v1/user, /api/v1/user/emails, and /api/v1/user/orgs - successfully retrieves identity claims through the OIDC endpoint. A public proof-of-concept exists; the issue is fixed in Gitea v1.27.0 and is not confirmed in the CISA KEV catalog.

RemediationAI

Vendor-released patch: upgrade to Gitea 1.27.0 or later, which enforces API token scopes on the OIDC userinfo endpoint (advisory GHSA-mg4f-x9v4-6h2p; release https://github.com/go-gitea/gitea/releases/tag/v1.27.0). If you cannot upgrade immediately, reduce exposure by treating existing personal access tokens as capable of reading identity/group data regardless of their assigned scope: revoke and reissue tokens granted to untrusted or third-party integrations, and avoid depending on narrow PAT scoping to hide org/team membership until patched. Where feasible, restrict network reachability of the /login/oauth/userinfo endpoint to trusted OIDC clients via a reverse proxy allowlist - note this side effect breaks legitimate OIDC relying parties that call userinfo, so apply it only if you are not using Gitea as an OIDC provider. Because the disclosure is limited to the token holder's own identity, the upgrade is the clean fix and workarounds are secondary.

Affected VersionsENISA

Gitea Open Source Git Server 1.26.2

Affected Packages

go code.gitea.io/gitea fix: 1.27.0

go gitea.dev fix: 1.27.0

euvd gitea_open_source_git_server no fix

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 3 packages in go, euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

Gitea implements OAuth2/OIDC and issues scoped personal access tokens (PATs) whose scopes (read:user, read:organization, read:misc, etc.) gate the v1 REST API. The OIDC userinfo endpoint is designed to return standard identity claims to an OAuth client, and it shares Gitea's bearer-token authentication middleware. The defect (CWE-200, Exposure of Sensitive Information) is that userinfo authenticates the PAT but never checks whether the presented token carries a user/organization scope before assembling the email and groups claims, so a token that is functionally unprivileged for identity data at the REST layer is treated as fully privileged at the OIDC layer. Affected package is pkg:go/code.gitea.io/gitea at versions < 1.27.0.

Know when Gitea gets its next vulnerability

Watch products and get an email when something new is published
Check this CVE against your own stack and servers
Exploit and PoC references, threat intelligence from 22 sources

Continue with Google Continue with GitHub

No credit card · 7-day full trial

Severity by source

Vendor (https://github.com/go-gitea/gitea) PRIMARY 9.1 CRITICAL

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

vuln.today AI 4.3 MEDIUM

A valid API token is required (PR:L, not PR:N); disclosure is limited to the holder's own email and group membership (C:L), with no integrity or availability impact.

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

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

SUSE CRITICAL

Primary rating from Vendor (https://github.com/go-gitea/gitea).

CVSS VectorVendor: https://github.com/go-gitea/gitea

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

None

Lifecycle Timeline

Analysis Updated

Aug 14, 2026 - 18:30 vuln.today

v2 - CVSS changed

CVSS changed

Aug 14, 2026 - 18:22 NVD

9.1 (CRITICAL)

DescriptionCVE.org

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:

http

403 Forbidden

with a scope-related error.

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

http

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

Create a personal access token with only the following scope:

text

read:misc

Verify that the token cannot access user-related REST API endpoints:

http

GET /api/v1/user
GET /api/v1/user/emails
GET /api/v1/user/orgs

Each request returns:

http

403 Forbidden

Send the same token to the OIDC userinfo endpoint:

http

GET /login/oauth/userinfo
Authorization: Bearer <read-misc-token>

Observe that the request succeeds and returns identity claims, for example:

json

{
  "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.

Executive ViewAI

Why It Matters

Gitea self-hosted Git servers before version 1.27.0 permit any token-holder to access organization team membership and email addresses through an authorization bypass, regardless of their token's scoped permissions. This scope enforcement failure exposes your organization's internal team structure and employee contact information to all API token holders. The public availability of exploit code increases risk of discovery and exploitation by departing employees or internal actors.

Business Impact: High

Compensating Controls

Vendor-released patch: Gitea 1.27.0 or later

Threat Intelligence Overview

EPSS Score

0.2%

Top 93% exploitable

Prevalence

Medium

popular self-hosted Git server, common among self-hosters but not enterprise-ubiquitous

Threat Intel

1 source

Data Quality

6 sources

Confidence: High

EUVD

NVD

CVE.org

EPSS GHSA Vendor

GitHub

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue

Severity CRITICAL

CISA KEV No

Public POC No

EPSS 0.2%

Patch available Yes

Active threat No

Deciding rule

CRITICAL severity

What every action level means

Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.

Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.

This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.

This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.

Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived

Scheduled

Exploitation· derived

None

System Exposure· derived

Open

Automatable· derived

Yes

Human Impact

High

Priority Score

Low Medium High Critical

KEV: 0

EPSS: 0

CVSS: +46

PoC: 0

Weaponized: 0

Threat intel: 0

Gov advisory: 0

Attack Technique

Information Disclosure MEDIUM

Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.