Gitea public-only token bypass in repository and organization creation
Only Gitea builds before 28.3.0 that register POST /org/{org}/repos without the public-only guard are affected. Fixed in 28.3.0.
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- Published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- A 0-100 score for how much a CVE matters across the industry: exploitation, exposure, how widely the software is used, severity and whether a fix exists.What do these mean? →
- 8/100 · provisional
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Specific setups only
- Fix
- Fixed in 28.3.0
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
Gitea, the self-hosted Git service, is affected. A personal access token limited to public resources could still create private repositories, create private organizations, and generate private repositories from templates through several API endpoints, bypassing a fix in a recent release.
Read the original description
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/repos/{owner}/{repo}/generate` still accepted such tokens. A holder of a public-only token with the needed write scopes could create private repositories in organizations where the token's owner may create repositories, create private organizations, and generate private repositories from templates. The token still could not read the private repositories it created.
What to do
Check whether your setup matches what the bug needs.
Affected builds register POST /org/{org}/repos without the public-only guard (Gitea 1.27.3 confirmed). The default account that can create organizations is allowed to do so, which is the site default. The token holder must have CanCreateOrgRepo on the target organization (owning an org they created is sufficient).Upgrade to a fixed version: 28.3.0.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- gitea.dev
fixed in 28.3.0
Evidence 5
- Advisory
- Patch
- Patch
- Repository
- Link
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about CVE-2026-118395
What does this mean?
A holder of a public-only personal access token can create private repositories in organizations where they may create repositories, bypassing the public-only restriction. The token still cannot read the private repositories it creates.Source: github.com, blog.gitea.com
Am I affected, and how do I check?
Gitea versions before 28.3.0 are in the affected range, and Gitea 1.27.3 is confirmed affected. A build is affected when routers/api/v1/api.go registers POST /org/{org}/repos without rejectPublicOnly(). The token holder also needs CanCreateOrgRepo on the target organization, which owning an organization they created provides, and DEFAULT_ALLOW_CREATE_ORGANIZATION is true by default.Source: github.com, blog.gitea.com
What should I do about it?
Upgrade to Gitea 28.3.0 or later, which is the release that contains the fix. The facts list no workaround.Source: github.com, blog.gitea.com
Is it being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data