When a collaborator with admin permission on a private repo creates a webhook, that webhook keeps firing after the collaborator's access is revoked. Gitea's revocation cleanup DeleteCollaboration removes the collaboration record, recalculates accesses, drops watches, and unassigns issues — but it does not remove or disable webhooks the user created, and webhook delivery never re-checks whether the creator still has repo access. The former collaborator therefore receives the full payload …
The endpoint "/orgs/{org}/public_members/{username}" + GET exposes organization membership of public members in a private organization.
Gitea's /api/v1/teams/{id} API routes do not correctly enforce the public-only access token restriction. A public-only token is intended to limit API access to public repositories and public organizations. However, several team API routes continue to return private team repository metadata and private team activity feed entries when called with a public-only token.
PR #38145 fixed ListPublicMembers and IsPublicMember but missed ListMembers. Any authenticated user can enumerate ALL members (not just public ones) of a private organization.
Gitea's restore-repo command processes release.yml files from a user-supplied archive. The DownloadURL field in each release attachment is passed to uri.Open() without scheme validation. Because uri.Open() supports the file:// scheme via os.Open(), an operator-level attacker can plant a crafted release.yml to exfiltrate arbitrary files from the server filesystem as release attachments.
A user with Code write access to one repository may be able to associate an existing Git LFS object from a private source repository with their target repository, even when they do not have Code access to the source repository that currently owns the LFS object. The issue appears to be caused by the source-object authorization check using broad repository accessibility instead of requiring Code-unit access to at least one …
GetActionsUserRepoPermission (models/perm/access/repo_permission.go) decides whether an Actions task token may access a target repo. Its cross-repo branches each enforce a fork-PR discriminator — except the collaborative-owner branch, which is missing the !task.IsForkPullRequest guard that its sibling has. As a result, when a private repo B lists owner A as a collaborative owner, an attacker-controlled fork pull-request workflow whose base repo is owned by A is granted code-read on B — i.e. …
This is a cross-repository IDOR / broken access control issue. An attacker can tamper with issue-tracking state (dependency relationships) and inject an attacker-authored comment into a private repository they cannot otherwise read or write to, crossing a trust boundary the "add" path explicitly enforces. Impact is bounded - it requires an existing dependency link and discloses no repository content - but it is a genuine unauthorized-write primitive across a private-repo …