Vendor
239 published CVES affecting Gitea, from public sources (CVE.org, NVD, CISA KEV, FIRST EPSS, OSV).
Newest publication first · page 1 of 10
The web profile and RSS/Atom feed routes of users and organizations checked only whether a signed-in viewer could see a limited-visibility owner, without considering the public-only restriction of the personal access token used to authenticate. Any user holding a public-only toke...
The /{username} web route accepted personal access tokens over HTTP Basic authentication without checking their scope. A token confined to an unrelated scope, such as read:issue, could read its owner's private activity through the user RSS/Atom feed and the profile activity tab,...
Repository and organization project boards listed the pull requests that reference each issue on the board without checking whether the viewer can read them. When a private pull request mentions an issue on a board the viewer can open, the board revealed the private repository's...
DELETE /api/v1/orgs/{org}/repos deletes all repositories of an organization, but it did not enforce the public-only restriction of access tokens: the route only checked that the organization itself was public. A public-only token of an owner of a public organization could therefo...
The web interface blocks issue and pull request changes on archived repositories, but several issue routes of the REST API did not check whether the repository is archived. A user allowed to change issues of an archived repository could use the API to edit, close or delete issues...
Gitea 1.27.3 stopped personal access tokens restricted to public resources (public-only) from creating repositories through POST /api/v1/user/repos and POST /api/v1/repos/migrate, but POST /api/v1/org/{org}/repos, POST /api/v1/orgs/{org}/repos, POST /api/v1/orgs and POST /api/v1/...
The OAuth2 userinfo endpoint (/login/oauth/userinfo) decided whether to limit the groups claim to public organizations by re-parsing the Authorization header as an OAuth2 access token instead of using the scope of the credential that authenticated the request. When a public-only...
The OCI registry's cross-repository blob mount checked the target package against the token's public-only restriction, but checked the source blob only against the full account permissions of the token owner. A public-only token with write:package scope, whose owner can read a pr...
When parsing an uploaded Helm chart, Gitea decompressed the archive and read every tar entry while looking for Chart.yaml without limiting the decompressed size, and did so before the package size quota was checked; the quota only considers the compressed upload size. A user with...
The issue timeline API and the web issue page hid cross-reference events that point at issues the reader cannot access, but not "dependency added" and "dependency removed" events. When a readable issue had been linked as a dependency to an issue in a repository the reader cannot...
The repositories, stars and watching tabs of user profiles and the repository list of organization home pages included private repositories for every signed-in request without checking whether the request used a personal access token restricted to public resources (public-only)....
The /api/v1/admin route group did not enforce the public-only restriction of personal access tokens. A public-only token with admin scope issued by a site administrator could therefore list private organizations and the email addresses of all users, create organizations, obtain r...
The GITEA_TOKEN of a Gitea Actions job authenticates as the gitea-actions system user, and the /api/v1/user email and GPG key endpoints accepted that user, so a job could register an email address and a GPG key on it; without required email confirmation (the default) the address...
The API routes for releases, release assets, milestones and repository labels did not reject changes to archived repositories. A user with write access to an archived repository, or a holder of such a user's write-scoped token, could replace or delete release assets while keeping...
Gitea did not reject personal access tokens restricted to public resources (public-only) on the organization Actions runner registration-token endpoint, and the runner registered with the resulting token was not limited to public repositories. Holding only such a token with write...
GET /api/v1/users/{username}/heatmap computed the contribution heatmap with the repository access of the token owner and ignored the public-only restriction of the access token, unlike the activity feed endpoints. A holder of a user's public-only token could read contribution cou...
Legacy (v1 to v3) Actions artifact uploads stored the request's Content-Encoding header unchecked in the column that is served as the artifact's Content-Type on download, and a value starting with video/ or audio/ also removed the sandboxing Content-Security-Policy. A user who ca...
Gitea Actions task tokens authenticate to the REST API as a shared system user with a negative ID, which repository, organization, project and key filters treated as having no owner restriction, and the token carried no API scope to restrict user-scoped routes. A user who can run...
When [oauth2_client].ACCOUNT_LINKING is set to auto (not the default) and registration is enabled, the link-account sign-up form looked up the existing account to link by the user name or email submitted in the form instead of the identity asserted by the OAuth2 provider. An atta...
Workflows triggered by a pull request review were read from the commit named in the review's commit_id, while the fork restrictions were decided by the reviewed pull request, and the commit was not checked to belong to that pull request. A user with read access to a repository co...
Seven Gitea API routes under /api/v1/users/{username} (followers, following, following/{target}, starred, subscriptions, keys and gpg_keys) were registered without the individualPermsChecker middleware that enforces the visibility of the target user. An authenticated user could t...
Deleting a label compared the ID of the repository in the request against the organization ID of organization labels, and the two ID sequences overlap. A user with write access to the issues of a repository could therefore delete the labels of an organization that has the same nu...
Adding attachments to a release checked the repository and release of an attachment but not whether it was already linked to an issue or comment. A user with write access to the releases of a repository, who knew the UUID of an attachment in that repository, could link it to a re...
The visibility check of Gitea user profiles was applied to GET requests only, while POST /{username} (follow and unfollow) required only a signed-in user. Any authenticated user could therefore obtain the full name, location, website and description of a user with a private profi...
Creating a draft release through the API returned an assets list that was built from a release without an ID, which matched every attachment that was not linked to a release. A user who could create a draft release in a repository therefore received the metadata (file name, UUID,...
Sources: CVE.org, NVD, CISA KEV, FIRST EPSS, OSV and public exploit-reference metadata. Product matching comes from the published CVE records. A proof-of-concept means public code exists; it is not evidence of exploitation.