Gitea vulnerabilities
Every vulnerability this feed holds for Gitea, merged from five public registers and ordered by what warrants attention first — exploited in the wild, then CVSS, then recency.
22 vulnerabilities tracked. 1 confirmed exploited in the wild. 1 with public exploit code.
- — Gitea Code Injection Vulnerability
- 7.5 Gitea resolved the principals of an SSH certificate by searching the content of all stored public keys instead of only principal keys.
- — The web profile and RSS/Atom feed routes of users and organizations checked only whether a signed-in viewer could see a limited-visibility…
- — The /{username} web route accepted personal access tokens over HTTP Basic authentication without checking their scope.
- — Repository and organization project boards listed the pull requests that reference each issue on the board without checking whether the…
- — DELETE /api/v1/orgs/{org}/repos deletes all repositories of an organization, but it did not enforce the public-only restriction of access…
- — The web interface blocks issue and pull request changes on archived repositories, but several issue routes of the REST API did not check…
- — Gitea 1.27.3 stopped personal access tokens restricted to public resources (public-only) from creating repositories through POST…
- — The OAuth2 userinfo endpoint (/login/oauth/userinfo) decided whether to limit the groups claim to public organizations by re-parsing the…
- — The OCI registry's cross-repository blob mount checked the target package against the token's public-only restriction, but checked the…
- — When parsing an uploaded Helm chart, Gitea decompressed the archive and read every tar entry while looking for Chart.yaml without limiting…
- — The issue timeline API and the web issue page hid cross-reference events that point at issues the reader cannot access, but not "dependency…
- — The repositories, stars and watching tabs of user profiles and the repository list of organization home pages included private repositories…
- — The /api/v1/admin route group did not enforce the public-only restriction of personal access tokens.
- — The GITEATOKEN of a Gitea Actions job authenticates as the gitea-actions system user, and the /api/v1/user email and GPG key endpoints…
- — The API routes for releases, release assets, milestones and repository labels did not reject changes to archived repositories.
- — Gitea did not reject personal access tokens restricted to public resources (public-only) on the organization Actions runner…
- — GET /api/v1/users/{username}/heatmap computed the contribution heatmap with the repository access of the token owner and ignored the…
- — Legacy (v1 to v3) Actions artifact uploads stored the request's Content-Encoding header unchecked in the column that is served as the…
- — Gitea Actions task tokens authenticate to the REST API as a shared system user with a negative ID, which repository, organization, project…
- — When [oauth2client].ACCOUNTLINKING is set to auto (not the default) and registration is enabled, the link-account sign-up form looked up…
- — Workflows triggered by a pull request review were read from the commit named in the review's commitid, while the fork restrictions were…
What this covers
This feed accumulates forward from the day it started storing records, and a name search that finds nothing here is also looked up against the registers directly — so an older advisory resolves even when it predates the corpus. It is still a reading view, not a substitute for the vendor's own advisory, and absence from this page is not a statement that Gitea is free of vulnerabilities.
Query this from an agent over MCP · Check a lockfile by version
Other vendors tracked here
Microsoft Red Hat n/a MediaTek, Inc. Linux Apache Software Foundation WAVLINK Huawei Apple Eclipse Foundation WSO2 Dell PostgreSQL Control Web Panel nodejs Hewlett Packard Enterprise (HPE) Netpbm MONGODB Cisco zephyrproject aws Petpooja Unknown Oray