Summary
Gitea's tag-deletion route could allow a user with Code write access to delete published releases and their attachments, even without permission to manage releases. The issue becomes risky when the route processes a release tag through a handler that does not verify the target is only a plain tag, although protected-tag rules may still prevent deletion.
Gitea's tag-deletion route could allow a user with Code write access to delete published releases and their attachments, even without permission to manage releases. The issue becomes risky when the route processes a release tag through a handler that does not verify the target is only a plain tag, although protected-tag rules may still prevent deletion.
Affected context
The vulnerability occurs in Gitea repositories where:
- A collaborator has write access to the Code unit
- The collaborator does not have Releases write access
- The tag-deletion web route is used against a tag associated with a published release
- The shared deletion handler does not distinguish plain tags from release tags
Protected tag rules covering the target release tag may provide an additional control that blocks the operation.
The vulnerability occurs in Gitea repositories where:
- A collaborator has write access to the Code unit
- The collaborator does not have Releases write access
- The tag-deletion web route is used against a tag associated with a published release
- The shared deletion handler does not distinguish plain tags from release tags
Protected tag rules covering the target release tag may provide an additional control that blocks the operation.
Exploit preconditions
- Attack surface: Gitea's authenticated web route for deleting tags
- Required access: Code write permission on the affected repository, without requiring Releases write permission
- Trigger point: A tag-deletion request targeting a tag associated with a published release
- Why exploitation is possible: Authorization is evaluated for tag deletion, while the shared handler can also perform release deletion without separately checking release-management permissions
- Attack surface: Gitea's authenticated web route for deleting tags
- Required access: Code write permission on the affected repository, without requiring Releases write permission
- Trigger point: A tag-deletion request targeting a tag associated with a published release
- Why exploitation is possible: Authorization is evaluated for tag deletion, while the shared handler can also perform release deletion without separately checking release-management permissions
Why this happens
The underlying flaw is an authorization boundary failure. A handler shared by tag and release deletion treated permission to delete a code tag as sufficient for operations that could also remove a published release and its attachments.
This behavior maps primarily to CWE-863: Incorrect Authorization, because the application did not enforce the authorization required for the specific protected action. It is also related to CWE-732: Incorrect Permission Assignment for Critical Resource, because repository permissions permitted a lower-privileged collaborator to affect release resources.
The underlying flaw is an authorization boundary failure. A handler shared by tag and release deletion treated permission to delete a code tag as sufficient for operations that could also remove a published release and its attachments.
This behavior maps primarily to CWE-863: Incorrect Authorization, because the application did not enforce the authorization required for the specific protected action. It is also related to CWE-732: Incorrect Permission Assignment for Critical Resource, because repository permissions permitted a lower-privileged collaborator to affect release resources.
Potential impact
- An authorized collaborator may permanently delete published releases
- Release attachments may be removed
- Consumers may lose access to expected release artifacts
- Release history and distribution workflows could be disrupted
- The incident could cause integrity, availability, or auditability concerns for repository content
- An authorized collaborator may permanently delete published releases
- Release attachments may be removed
- Consumers may lose access to expected release artifacts
- Release history and distribution workflows could be disrupted
- The incident could cause integrity, availability, or auditability concerns for repository content
General mitigation guidance
Mitigation generally focuses on enforcing authorization for the final operation rather than relying on the permission associated with the initial route.
Common defensive patterns include:
- Separating tag-deletion and release-deletion authorization checks
- Verifying that the target is a plain tag before allowing tag-only behavior
- Requiring explicit Releases write permission for release and attachment deletion
- Applying object-level authorization checks immediately before destructive operations
- Preserving protected-tag enforcement as an independent safeguard
- Using least-privilege repository roles and limiting write access to trusted collaborators
- Providing confirmation, audit logging, and recovery controls for destructive repository actions
Mitigation generally focuses on enforcing authorization for the final operation rather than relying on the permission associated with the initial route.
Common defensive patterns include:
- Separating tag-deletion and release-deletion authorization checks
- Verifying that the target is a plain tag before allowing tag-only behavior
- Requiring explicit Releases write permission for release and attachment deletion
- Applying object-level authorization checks immediately before destructive operations
- Preserving protected-tag enforcement as an independent safeguard
- Using least-privilege repository roles and limiting write access to trusted collaborators
- Providing confirmation, audit logging, and recovery controls for destructive repository actions
How teams detect issues like this
Organizations can assess for this class of issue through:
- Static analysis that identifies shared destructive handlers with inconsistent permission checks
- Code review checks comparing route-level permissions with object-level authorization
- Tests that exercise each repository role against tag, release, and attachment deletion separately
- Policy enforcement requiring explicit authorization for destructive operations on release artifacts
- Audit-log monitoring for release deletion performed by identities lacking release-management privileges
- Automated security review tools that flag missing resource-type validation or authorization checks
Organizations can assess for this class of issue through:
- Static analysis that identifies shared destructive handlers with inconsistent permission checks
- Code review checks comparing route-level permissions with object-level authorization
- Tests that exercise each repository role against tag, release, and attachment deletion separately
- Policy enforcement requiring explicit authorization for destructive operations on release artifacts
- Audit-log monitoring for release deletion performed by identities lacking release-management privileges
- Automated security review tools that flag missing resource-type validation or authorization checks
Sources
| Source | Link |
|---|---|
| blog. | blog.gitea.com/ |
| github. | github.com/ |
| github. | github.com/ |
| github. | github.com/ |
| github. | github.com/ |
