CVE-2026-97204: 
Gitea vulnerability analysis and mitigation

CVE-2026-97204 is an Incorrect Authorization vulnerability in Gitea that allows an authenticated user with write access to a repository's issues to delete organization-level labels belonging to a different tenant. The flaw affects Gitea versions up to and including 28.1.0, and was disclosed on October 18, 2026. It is classified as Low severity with a CVSS v3.1 base score of 3.5 (GitHub Advisory, Gitea Release).

The root cause is an incorrect authorization check (CWE-863) in the DeleteLabel(ctx, id, labelID) function within models/issues/label.go. The function accepts a single untyped id parameter and compares it against either the label's OrgID or RepoID depending on the label type — but repository IDs and organization IDs are drawn from independent auto-increment sequences that can produce identical numeric values. When a repository-scoped API route (e.g., routers/api/v1/repo/label.go:271) passes a repository ID that numerically matches an organization's ID, the authorization check passes and the organization's label is deleted. The org-side routes require reqOrgOwnership, but the repo-side routes do not, making this exploitable by any user with issues-write permission on the matching repository (GitHub Advisory).

A successful exploit allows an authenticated attacker to delete labels belonging to an organization they have no membership or ownership in, crossing tenant boundaries. Removing organization labels detaches them from every issue in that organization that referenced them, disrupting triage workflows, project management, and issue categorization across all affected teams. There is no confidentiality or availability impact; the impact is limited to integrity of label data within the affected organization (GitHub Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported. The attack complexity is rated High (CVSS AC:H) because the numeric ID collision between a repository and a target organization is not attacker-controlled — on a populated instance, engineering a specific collision may be impractical, though identifying an existing collision is straightforward via the public API. The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog (GitHub Advisory).

1. Reconnaissance: Authenticate to a Gitea instance running version ≤ 28.1.0. Use the Gitea API (e.g., GET /api/v1/repos/{owner}/{repo}) to enumerate repository IDs you have write access to, and GET /api/v1/orgs/{org} to enumerate organization IDs visible to you.
2. Identify ID collision: Compare the numeric id values of repositories where you hold issues-write access against the numeric id values of organizations. A match (e.g., repository ID = 42, organization ID = 42) is the prerequisite for exploitation.
3. Enumerate target labels: Use GET /api/v1/orgs/{org}/labels to list the organization's labels and obtain their labelID values.
4. Trigger unauthorized deletion: Send a DELETE /api/v1/repos/{owner}/{repo}/labels/{labelID} request using your repository credentials, supplying a labelID that belongs to the ID-colliding organization. The DeleteLabel function will compare the repository ID against the organization's ID, find them equal, and proceed with deletion.
5. Verify impact: Confirm the organization label has been removed by re-querying GET /api/v1/orgs/{org}/labels, observing that the label is detached from all issues in that organization (GitHub Advisory).

• Network/API Logs: Unexpected DELETE /api/v1/repos/{owner}/{repo}/labels/{id} requests where the labelID resolves to an organization-scoped label rather than a repository-scoped label; requests originating from users who are not members of the affected organization.
• Application Logs: Gitea audit log entries showing label deletion events attributed to a repository collaborator on labels owned by an organization they do not belong to.
• Data Integrity: Sudden disappearance of organization-level labels from issues across an organization, particularly when no organization owner or admin performed the deletion.

Gitea has released version 28.2.0, which fixes this vulnerability by ensuring labels are deleted only within their own repository or organization scope. The fix was introduced via pull requests #39743 (main branch) and #39752 (backport to v28 release branch). Users should upgrade to Gitea 28.2.0 or later as soon as possible; no configuration-based workaround is available (Gitea Release, Fix PR, Backport PR).

The vulnerability was reported by researcher N0K0 and disclosed via GitHub Security Advisories on October 18, 2026. The advisory notes that prior CVEs (CVE-2026-58445 and CVE-2026-25038) addressed related label scoping issues at or below version 1.27.0, but this particular ID-type conflation survived those fixes. No significant broader media coverage or social media discussion has been identified (GitHub Advisory).