Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain valid API token while collaborator
-
DeliveryAccess revoked, token remains live
-
ExploitCall GET /api/v1/user/starred
-
ExecutionReceive private repo metadata (clone_url, ssh_url)
-
PersistCall GET /api/v1/user/times
-
ImpactExfiltrate private issue titles and states
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization logic validation
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires three concurrent conditions: (1) the attacker must have previously held collaborator access to the target Gitea instance and must have starred at least one private repository or logged time on at least one issue in a private repository; (2) the attacker must possess a Gitea API token or session credential that was issued before revocation and has not been explicitly invalidated - Gitea's repository-permission revocation does not automatically expire tokens; (3) the target instance must run a version of Gitea prior to 1.27.0. The exposure is strictly metadata: repository |
| Impact | The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N, score 4.3 Medium) accurately captures the risk profile: network-reachable with low complexity, but gated behind a previously-issued authenticated token (PR:L), with only limited confidentiality impact. Real-world risk is meaningful for organizations with strict information compartmentalization - contractors or former employees who starred sensitive repositories or logged time on confidential issues retain indefinite metadata visibility after revocation. The exposure is bounded: only repositories the revoked user personally starred or tracked time on are affected, not arbitrary private repositories on the instance. No EPSS score was supplied in the input and cannot be independently inferred. No KEV listing exists; active exploitation in the wild is not confirmed. The 'Authentication Bypass' tag in the advisory is somewhat imprecise - this is a post-revocation authorization failure (CWE-863), not a bypass of authentication itself. The incomplete-patch lineage from CVE-2026-20800 increases urgency for instances that believed they were already remediated. |
| Exploit ScenarioDerived | A former contractor whose collaboration access to a Gitea organization is revoked still possesses a valid personal API token issued before revocation. They issue |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Jul 21, 2026
Private repository metadata and issue titles leak to revoked Gitea users via two REST API endpoints that omit post-revocation authorization checks, constituting an incomplete fix relative to CVE-2026-20800. Former collaborators with a still-valid API token can call GET /api/v1/user/starred to receive full repository objects - including clone_url and ssh_url - for private repos they starred, and GET /api/v1/user/times to retrieve private issue titles and states for issues on which they logged time, indefinitely after repo access is revoked. Impact is metadata-only; no public exploit code has been identified at time of analysis and no CISA KEV listing exists.
RemediationAI
Upgrade to Gitea 1.27.0 or later, the vendor-released patch that introduces access filtering at output time for both getStarredRepos() and ListMyTrackedTimes(). The release is available at https://github.com/go-gitea/gitea/releases/tag/v1.27.0 and the advisory at https://github.com/go-gitea/gitea/security/advisories/GHSA-qf2f-qh6p-7v89. If immediate upgrade is not feasible, invalidate or rotate API tokens for all revoked collaborators at the time of access removal - this eliminates the attack vector entirely since the leakage requires a valid token, though it is an operational burden and must be applied to every revocation event going forward. As a secondary measure, administrators can manually clear a revoked user's stars and time entries for private repositories, though this is labor-intensive and does not scale. Neither workaround addresses the underlying code defect; patching to 1.27.0 is the only durable fix.
Affected VersionsENISA
Affected Packages
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 service written in Go (package code.gitea.io/gitea). The root cause is CWE-863 (Incorrect Authorization): both affected handlers fetch records keyed on the caller's user identity - starred repos and time-tracking entries - without subsequently re-validating that the caller retains current permission on the associated repository. getStarredRepos() does compute a per-repo permission object, but the filtering step is absent, so all starred repos are returned regardless of current access. ListMyTrackedTimes() queries by UserID only and calls LoadAttributes, which hydrates full issue metadata including title and state. CVE-2026-20800 patched the notification endpoint for the same class of bug but left these two sibling endpoints unaddressed. The fix is introduced in Gitea 1.27.0, which adds access filtering at output time for both handlers.
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
AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
PR:L because a previously-issued valid API token is required; C:L because only metadata (repo names, URLs, issue titles) is exposed, not repository content.
Primary rating from Vendor (https://github.com/go-gitea/gitea).
CVSS VectorVendor: https://github.com/go-gitea/gitea
DescriptionCVE.org
Summary
CVE-2026-20800 fixed private-info leakage to revoked users only for the notification endpoint. Two sibling endpoints that return data keyed on the caller's own relationship still do not re-check repo access at output time:
GET /api/v1/user/starred-getStarredRepos()computes a per-repo permission but still lists every
starred repo (no filtering), so the full repo object (full_name, private, clone_url, ssh_url) of a now-inaccessible private repo is returned.
GET /api/v1/user/times-ListMyTrackedTimes()queries byUserIDonly andLoadAttributesbrings
in the issue (title, state), leaking private issue titles after revocation.
Steps to reproduce
Using the provided reproduction materials, as a revoked user:
- Control:
GET /api/v1/repos/admin/starred-test→ 404. GET /api/v1/user/starred→ leaksadmin/starred-test,private:true,clone_url.GET /api/v1/user/times→ leaksissue.title = "SECRET: …",state.
(Runtime-confirmed on gitea/gitea:1.25.4. Oracle = planted sentinel title; no real secret exfiltrated.)
Impact
A former collaborator can enumerate private repos they starred and read private issue titles they logged time on, indefinitely after access revocation. Metadata only (no repo content / comment bodies). Low.
Suggested remediation
getStarredRepos: drop (or minimally redact) repos wherepermission.HasAnyUnitAccessOrPublicAccess()
is false for the caller.
ListMyTrackedTimes: filter tracked-time entries by current repo access.- Optionally clear a user's stars / time entries for a private repo on revocation.
Credit
Reported as part of an incomplete-patch measurement study (responsible disclosure).
Threat Intelligence Overview
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.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Remote code execution in Gitea (self-hosted Git service) via a code-injection flaw (CWE-94) allows attackers to run arbi
Broken access control in Gitea's Composer package registry (versions up to and including 1.26.1) lets remote attackers r
Gitea before 1.16.7 does not escape git fetch remote. Rated high severity (CVSS 7.5), this vulnerability is remotely exp
The git hook feature in Gitea 1.1.0 through 1.12.5 might allow for authenticated remote code execution in customer envir
Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in Gitea Gitea
Authenticated command injection in Dokploy (self-hostable PaaS) versions 0.29.3 through 0.29.12 lets a low-privileged us
Reverse-proxy authentication bypass in the official Gitea Docker image (versions up to and including 1.26.2) allows any
Path traversal in Gitea's Org-mode (`.org`) markup renderer allows an attacker who can get Org-mode content rendered by
Container escape in Gitea act_runner (Docker backend, through act 0.262.0) lets an authenticated user with workflow-exec
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
Server-side request forgery and internal repository exfiltration in Gitea before 1.27.0 lets a low-privileged authentica
Authorization bypass in Gitea versions 1.22.3 through 1.26.1 allows holders of `public-only` access tokens or OAuth gran
Same weakness CWE-863 – Incorrect Authorization
View allSame technique Authentication Bypass
View allVendor StatusVendor
SUSE
Severity: Moderate| Product | Status |
|---|---|
| SUSE Linux Enterprise Server 16.1 | Affected |
| SUSE Linux Enterprise Server for SAP applications 16.1 | Affected |
EUVD-2026-101280
GHSA-qf2f-qh6p-7v89
NVD
CVE.org
EPSS
Exploit-DB