Skip to main content

Gitea CVE-2026-58429

| EUVDEUVD-2026-58157 MEDIUM
Improper Access Control (CWE-284)
2026-07-21 https://github.com/go-gitea/gitea GHSA-fq2p-5p22-8g6j
4.9
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

  1. Access
    Obtain or generate a public-only PAT with read:user and read:organization
  2. Delivery
    Send GET /api/v1/user/orgs with the restricted token
  3. Exploit
    Receive private organization membership list bypassing scope filter
  4. Execution
    Query GET /api/v1/users/{username}/orgs/{org}/permissions for each org
  5. Impact
    Obtain owner, admin, write, and repository-creation permission details for private organizations

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Access control enforcement
MITRE ATT&CK

1 technique across 1 tactic: Defense Evasion

The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up.

Exploitation Conditions

Exploitation requires possession of a valid Gitea personal access token configured with the public-only scope plus read:user and read:organization grant categories, belonging to an account that is a member of at least one private organization. The bypass is self-referential: it only discloses private organization data for the token's own account, not arbitrary third-party accounts, because the handler's visibility logic is driven by the authenticated user's actual org membership. Exploitation is therefore limited to accounts whose token has been shared with or stolen by an untrusted party. The CVSS PR:H assignment reflects the assumption that token possession equates to account control; operationally, the meaningful threat is a legitimately scoped token issued to a less-trusted consumer (CI job, third-party app). No special server configuration, non-default feature flag, or specific platform version beyond running Gitea < 1.27.0 is required beyond the preconditions above. Exploitation is constrained to read-only information disclosure of private org names and permission metadata; no write, delete, or code-execution path exists from this vulnerability alone.

Impact

The vendor-assigned CVSS 3.1 score of 4.9 (PR:H) reflects a conservative view that the attacker must already hold the account's own token - treating it as a self-harm scenario. However, the more operationally relevant threat model is a third-party integration, CI/CD pipeline, or leaked token that was intentionally scoped to public-only to limit blast radius; the bypass means that scope restriction provides no actual confidentiality guarantee for organizational metadata. In that context, PR:L is arguably more accurate, yielding a score closer to 6.5. EPSS data is not provided in the available intelligence, so exploitation probability cannot be quantified numerically. No CISA KEV listing exists. A working, detailed PoC is publicly available in the GHSA advisory with captured HTTP traces, meaning exploitation requires no novel research. The impact is strictly information disclosure (C:H, I:N, A:N) - no code execution, no data modification, and no availability impact. Real-world priority is highest for Gitea deployments that issue public-only tokens to third-party integrations or shared CI environments where token leakage is plausible; deployments where all PATs are tightly controlled by their owning users face lower practical risk.

Exploit ScenarioDerived

A CI pipeline is issued a public-only Gitea PAT (with read:user and read:organization scopes) to retrieve public repository metadata without exposure to sensitive organizational data. An attacker who obtains this token - through a leaked environment variable, a misconfigured secrets store, or a compromised pipeline runner - issues GET /api/v1/user/orgs using the token and receives a full list of private organizations the token owner belongs to, including their names and visibility metadata. The attacker then queries GET /api/v1/users/{username}/orgs/{org}/permissions for each discovered org and obtains the token owner's exact privilege level, including whether they hold ownership or admin rights. A detailed PoC with captured HTTP request and response traces is publicly available in GHSA-fq2p-5p22-8g6j.

This Month Plan within 30 days. Why: MEDIUM severity (CVSS 4.0-6.9).
Patch available 0.2% exploitation probability (EPSS)

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

Alert me

AnalysisAIv1 – Jul 22, 2026

Public-only personal access token scope enforcement in Gitea's REST API is inconsistently applied across two organization endpoints, allowing a token holder to enumerate private organization memberships and retrieve detailed permission data (ownership, admin status, write access, repository-creation capability) that the public-only restriction was explicitly designed to block. All Gitea versions prior to 1.27.0 are affected via GET /api/v1/user/orgs and GET /api/v1/users/{username}/orgs/{org}/permissions. Publicly available exploit code with full HTTP request/response traces is confirmed in the GHSA advisory; no CISA KEV listing exists, indicating no confirmed opportunistic mass exploitation at time of analysis.

RemediationAI

Upgrade to Gitea v1.27.0 or later, which applies fixes from PRs #37118 (https://github.com/go-gitea/gitea/pull/37118) and #37773 (https://github.com/go-gitea/gitea/pull/37773) and corresponding commits a34eac5ef42ada433a7c7dafb98f15c13d7ad74e and f2a1271f164569264c378fad720b0c000fff3336. The vendor advisory is at https://github.com/go-gitea/gitea/security/advisories/GHSA-fq2p-5p22-8g6j. If immediate upgrade is not feasible, operators should audit all existing public-only scoped tokens and revoke any issued to third-party integrations, CI pipelines, or automated tooling that has access to accounts belonging to private organizations, since those tokens cannot be trusted to restrict organizational data. As a compensating control, blocking API access to GET /api/v1/user/orgs and GET /api/v1/users/{username}/orgs/{org}/permissions at the reverse proxy level (e.g., nginx location deny rules) prevents exploitation of the affected endpoints but will break legitimate workflows that depend on those routes. No workaround fully restores the intended public-only scope guarantee without patching.

Affected VersionsENISA

Gitea Open Source Git Server 0 ≤1.26.4

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 is a self-hosted Git forge written in Go (CPE: pkg:go/code.gitea.io/gitea). Its API middleware layer uses checkTokenPublicOnly() to enforce scope restrictions on personal access tokens marked as public-only. CWE-284 (Improper Access Control) captures the root cause: the middleware evaluates route context objects (ctx.Org.Organization, ctx.ContextUser) to determine if the target resource is private, but those context objects are not populated consistently across all organization-related routes. For GET /api/v1/user/orgs, checkTokenPublicOnly() was never applied to the route at all. For GET /api/v1/users/{username}/orgs, the middleware evaluated the visibility of the path user (ctx.ContextUser) rather than the organization objects returned by the handler; since ctx.Org.Organization is not populated for list responses, private organizations passed through unfiltered. The permissions endpoint relied on general user-relationship visibility logic rather than explicit token scope checks. The fix in PRs #37118 and #37773 introduces ApplyPublicOnly() methods on query option structs (FindOrgOptions, SearchRepoOptions, etc.) and a TokenCanAccessRepo() helper to enforce scope restrictions at the data-query layer rather than the route-context layer.

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

No credit card · 7-day full trial

Severity by source

Vendor (https://github.com/go-gitea/gitea) PRIMARY 4.9 MEDIUM
AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N
vuln.today AI 6.5 MEDIUM

PR:L overrides vendor PR:H because any regular user token suffices; no admin privilege is needed, and the operational threat is token exposure to low-trust consumers.

3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
SUSE MEDIUM

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
High
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
None
Availability
None

DescriptionCVE.org

Summary

A personal access token restricted with the public-only scope can still retrieve private organization membership and organization permission details for its own account through organization-listing endpoints. This bypass breaks the intended guarantee that such tokens are limited to public resources only.

Details

The issue affects the following endpoints: GET /api/v1/user/orgs GET /api/v1/users/{username}/orgs/{org}/permissions

The application correctly prevents a public-only token from directly accessing a private organization through: GET /api/v1/orgs/{org}

However, that same token can still obtain private organization data through alternate code paths.

The root cause is inconsistent enforcement of the public-only restriction. The middleware responsible for blocking non-public organization access depends on route context being populated with the target organization. That assumption does not hold for all affected routes.

For GET /api/v1/user/orgs, the route does not apply checkTokenPublicOnly() at all.

For GET /api/v1/users/{username}/orgs, the middleware is present, but it evaluates ctx.ContextUser, which represents the user named in the path, not the organization objects returned by the handler. Since ctx.Org.Organization is not populated for these responses, private organization results are not filtered.

The organization listing logic then uses the effective relationship between the authenticated user and the target user to determine visibility. When the token belongs to the same user, the handler allows private organization visibility and returns private memberships.

The permissions endpoint is similarly affected. It relies on general visibility logic relative to the real user account rather than explicitly enforcing the public-only token restriction before returning organization authorization details. As a result, a restricted token can still obtain organization role information such as ownership, admin status, and repository creation capability for a private organization.

This is therefore a route-specific authorization failure: direct organization access is blocked, but indirect endpoints still disclose private organization-derived data.

PoC

Step 1: Create or use a user account that belongs to at least one private organization. <img width="1858" height="891" alt="Screenshot 2026-04-16 001614" src="https://github.com/user-attachments/assets/9c1bdbc4-234f-4f65-9b91-00c7ca9a51f7" />

Step 2: Generate a personal access token for that same user with the scopes: public-only, read:user, and read:organization

https://github.com/user-attachments/assets/c89c9004-5e6d-4ff9-b130-5cd9fedc38f6

Step 3: Confirm the token is correctly restricted by requesting the private organization directly <img width="1918" height="867" alt="Screenshot 2026-04-16 002345" src="https://github.com/user-attachments/assets/4c489174-b4ef-400b-9eea-5484520f51e2" />

[REQUEST] GET /api/v1/orgs/private_1?token=d8010b3dee25df1a9c3cb6aafbd24c27dae7ca56 HTTP/2 Host: gitea.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:148.0) Gecko/20100101 Firefox/148.0 Accept: application/json Accept-Language: en-US,en;q=0.9 Accept-Encoding: gzip, deflate, br Referer: https://gitea.com/api/swagger Sec-Fetch-Dest: empty Sec-Fetch-Mode: cors Sec-Fetch-Site: same-origin Priority: u=0 Te: trailers

[RESPONSE] HTTP/2 403 Forbidden Alt-Svc: h3=":443"; ma=2592000 Cache-Control: max-age=0, private, must-revalidate, no-transform Content-Type: application/json;charset=utf-8 Date: Wed, 15 Apr 2026 17:23:19 GMT Server: Caddy Vary: Origin X-Content-Type-Options: nosniff X-Gitea-Warning: token and access_token API authentication is deprecated and will be removed in gitea 1.23. Please use AuthorizationHeaderToken instead. Existing queries will continue to work but without authorization. Content-Length: 89 {"message":"token scope is limited to public orgs","url":"https://gitea.com/api/swagger"}

Step 4: Use the same token to request the authenticated user’s organizations. Observe that request send successful and receive data about private org. <img width="1545" height="791" alt="Screenshot 2026-04-16 002751" src="https://github.com/user-attachments/assets/761d2684-0882-4e61-9462-21514738e681" /> [REQUEST] GET /api/v1/user/orgs?token=d8010b3dee25df1a9c3cb6aafbd24c27dae7ca56 HTTP/2 Host: gitea.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:148.0) Gecko/20100101 Firefox/148.0 Accept: application/json Accept-Language: en-US,en;q=0.9 Accept-Encoding: gzip, deflate, br Referer: https://gitea.com/api/swagger Sec-Fetch-Dest: empty Sec-Fetch-Mode: cors Sec-Fetch-Site: same-origin Priority: u=0 Te: trailers

[RESPONSE] HTTP/2 200 OK Access-Control-Expose-Headers: X-Total-Count Alt-Svc: h3=":443"; ma=2592000 Cache-Control: max-age=0, private, must-revalidate, no-transform Content-Type: application/json;charset=utf-8 Date: Wed, 15 Apr 2026 17:26:35 GMT Server: Caddy Vary: Origin X-Content-Type-Options: nosniff X-Gitea-Warning: token and access_token API authentication is deprecated and will be removed in gitea 1.23. Please use AuthorizationHeaderToken instead. Existing queries will continue to work but without authorization. X-Total-Count: 1 Content-Length: 261 [{"id":192111,"name":"private_1","full_name":"","email":"","avatar_url":"https://gitea.com/avatars/cc05fbb4da63b760bf83cdc054c3be63","description":"","website":"","location":"","visibility":"private","repo_admin_change_team_access":true,"username":"private_1"}]

Step 5: Use the same token to request organization permissions for that private organization. <img width="1917" height="865" alt="Screenshot 2026-04-16 003100" src="https://github.com/user-attachments/assets/65578c48-3307-4e0d-ae08-991f64158706" /> [REQUEST] GET /api/v1/users/pcatso172124/orgs/private_1/permissions?token=d8010b3dee25df1a9c3cb6aafbd24c27dae7ca56 HTTP/2 Host: gitea.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:148.0) Gecko/20100101 Firefox/148.0 Accept: application/json Accept-Language: en-US,en;q=0.9 Accept-Encoding: gzip, deflate, br Referer: https://gitea.com/api/swagger Sec-Fetch-Dest: empty Sec-Fetch-Mode: cors Sec-Fetch-Site: same-origin Priority: u=0 Te: trailers

[RESPONSE] HTTP/2 200 OK Alt-Svc: h3=":443"; ma=2592000 Cache-Control: max-age=0, private, must-revalidate, no-transform Content-Type: application/json;charset=utf-8 Date: Wed, 15 Apr 2026 17:30:32 GMT Server: Caddy Vary: Origin X-Content-Type-Options: nosniff X-Gitea-Warning: token and access_token API authentication is deprecated and will be removed in gitea 1.23. Please use AuthorizationHeaderToken instead. Existing queries will continue to work but without authorization. Content-Length: 95

{"is_owner":true,"is_admin":true,"can_write":true,"can_read":true,"can_create_repository":true}

Impact

Any public-only token for a user who belongs to private organizations can enumerate those private organization names and retrieve detailed authorization information such as ownership, administrative status, write access, read access, and repository-creation capability. This weakens least-privilege token delegation and can expose sensitive internal organizational structure and privilege relationships to third-party integrations, CI jobs, or compromised automation that were only meant to access public data.

Threat Intelligence Overview

EPSS Score
0.2%
Top 94% exploitable
Prevalence
Medium
self-hosted git forge, common in enterprise DevOps and open-source teams
Threat Intel
1
1 source
Data Quality
6 sources
Confidence: High

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 MEDIUM
CISA KEV No
Public POC No
EPSS 0.2%
Patch available Yes
Active threat No
Deciding rule
MEDIUM severity (CVSS 4.0-6.9)
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
No
Human Impact· derived
Medium

Priority Score

24
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +24
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.

More in Gitea

View all
CVE-2026-60004 CRITICAL POC
9.8

Remote code execution in Gitea (self-hosted Git service) via a code-injection flaw (CWE-94) allows attackers to run arbi

CVE-2026-27771 HIGH POC
8.2 Jul 03

Broken access control in Gitea's Composer package registry (versions up to and including 1.26.1) lets remote attackers r

CVE-2022-30781 HIGH POC
7.5 May 16

Gitea before 1.16.7 does not escape git fetch remote. Rated high severity (CVSS 7.5), this vulnerability is remotely exp

CVE-2020-14144 HIGH POC
7.2 Oct 16

The git hook feature in Gitea 1.1.0 through 1.12.5 might allow for authenticated remote code execution in customer envir

CVE-2024-6886 CRITICAL POC
10.0 Aug 06

Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in Gitea Gitea

CVE-2026-72867 CRITICAL POC
9.9 Aug 10

Authenticated command injection in Dokploy (self-hostable PaaS) versions 0.29.3 through 0.29.12 lets a low-privileged us

CVE-2026-20896 CRITICAL POC
9.8 Jul 03

Reverse-proxy authentication bypass in the official Gitea Docker image (versions up to and including 1.26.2) allows any

CVE-2026-59774 CRITICAL POC
9.8

Path traversal in Gitea's Org-mode (`.org`) markup renderer allows an attacker who can get Org-mode content rendered by

CVE-2026-58053 CRITICAL POC
9.4 Jun 28

Container escape in Gitea act_runner (Docker backend, through act 0.262.0) lets an authenticated user with workflow-exec

CVE-2019-11229 HIGH POC
8.8 Apr 15

models/repo_mirror.go in Gitea before 1.7.6 and 1.8.x before 1.8-RC3 mishandles mirror repo URL settings, leading to rem

CVE-2026-57894 HIGH POC
8.5 Jul 21

Server-side request forgery and internal repository exfiltration in Gitea before 1.27.0 lets a low-privileged authentica

CVE-2026-24791 HIGH POC
8.1 Jun 17

Authorization bypass in Gitea versions 1.22.3 through 1.26.1 allows holders of `public-only` access tokens or OAuth gran

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
SUSE Linux Enterprise Server 16.1 Affected
SUSE Linux Enterprise Server for SAP applications 16.1 Affected
SUSE Linux Enterprise Module for Package Hub 15 SP5 Affected
SUSE Linux Enterprise Module for Package Hub 15 SP6 Affected
openSUSE Leap 15.5 Affected

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy