CVE-2026-105267: Gitea Privilege Escalation Vulnerability

CVE-2026-105267 Overview

CVE-2026-105267 is a broken access control vulnerability in Gitea, the self-hosted Git service. The flaw resides in the web route POST /{owner}/{repo}/tags/delete, which handles tag deletion. The handler is shared with release deletion logic but did not verify that the deletion target was a plain tag rather than a published release. A repository collaborator holding only Code write access, without Releases write access, could use the endpoint to permanently delete published releases and their attachments. Protected tag rules covering the release tag still blocked the deletion, limiting impact to unprotected release tags. The issue is tracked under CWE-732: Incorrect Permission Assignment for Critical Resource.

Critical Impact
A collaborator with only Code write permissions can permanently destroy published releases and attachments, bypassing the Releases unit permission model.

Affected Products

Gitea self-hosted Git service (versions prior to 28.1.0)
Repositories using the Gitea granular unit-based permission model
Any Gitea deployment granting third parties Code write access without Releases write access

Discovery Timeline

2026-10-06 - CVE-2026-105267 published to NVD
2026-10-07 - Last updated in NVD database

Technical Details for CVE-2026-105267

Vulnerability Analysis

Gitea separates repository permissions into units, including Code and Releases. Writing to each unit is intended to be independently authorized. The POST /{owner}/{repo}/tags/delete endpoint enforces only the Code write permission because tags are a Git-level construct. However, the server-side handler for this route is shared with release deletion. When the referenced tag is attached to a published release, the handler proceeded to delete the release record and its uploaded attachments without validating that the caller holds Releases write access. The result is an authorization check mismatch between the route and the handler. A collaborator restricted to source-code contributions can erase release history, binaries, and signed artifacts that are typically governed by the Releases unit.

Root Cause

The root cause is an incorrect permission assignment [CWE-732]. The tag deletion handler lacked a check confirming the target reference was a plain tag rather than a release tag. Because the authorization gate on the route checked only Code write permissions, release deletion executed under weaker privileges than the Releases unit requires.

Attack Vector

An authenticated collaborator with Code write access sends a POST request to /{owner}/{repo}/tags/delete targeting a tag that corresponds to a published release. If the release tag is not covered by a protected tag rule, the server deletes the release entry and its attachments. The attack requires valid credentials and existing collaborator status, so exploitation is scoped to insiders or compromised collaborator accounts. See the GitHub Security Advisory GHSA-vvqw-mjq8-x248 and Gitea Pull Request #39501 for the patch details.

Detection Methods for CVE-2026-105267

Indicators of Compromise

Unexpected POST /{owner}/{repo}/tags/delete requests in Gitea access logs originating from accounts that lack Releases write access.
Missing published releases or attachments in repositories where the Releases unit audit log shows no corresponding administrative action.
Gitea audit entries recording release deletion events immediately preceded by tag deletion events from the same user session.

Detection Strategies

Correlate web access logs with Gitea application audit logs to identify tag-delete calls that resulted in release removal.
Alert on release deletion events performed by users whose role grants Code write but not Releases write permission.
Baseline normal release deletion frequency per repository and flag spikes or deletions outside maintainer accounts.

Monitoring Recommendations

Forward Gitea reverse-proxy and application logs to a centralized log platform for retention and correlation.
Monitor the /tags/delete route specifically, tagging events with the acting user and the target reference name.
Track protected tag rule coverage so release tags without protection are visible to administrators.

How to Mitigate CVE-2026-105267

Immediate Actions Required

Upgrade Gitea to version 28.1.0 or later, which contains the fixes from Pull Request #39501 and Pull Request #39507.
Audit repository collaborator lists and remove unnecessary Code write grants for untrusted accounts.
Review recent release deletions to identify unauthorized removals and restore attachments from backups if required.

Patch Information

The fix shipped in Gitea v28.1.0. The patched handler verifies that the deletion target is a plain tag and enforces Releases write permission before removing a release or its attachments. Refer to the Gitea 28.1.0 release announcement for the full change set.

Workarounds

Apply protected tag rules to all release tags; protected tags continued to block deletion in vulnerable versions.
Restrict Code write access to trusted maintainers until the upgrade is complete.
Maintain regular backups of release attachments so deletions can be reversed.

bash

# Example: enforce a protected tag rule covering release tags via the Gitea API
curl -X POST \
  -H "Authorization: token $GITEA_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name_pattern": "v*", "whitelist_usernames": ["release-manager"]}' \
  https://gitea.example.com/api/v1/repos/{owner}/{repo}/tag_protections