Proof-of-concept lab for a Gitea authorization bypass where a public-only PAT with write:organization creates a private organization via POST /api/v1/orgs.
abraxaslabs.tech · github.com/abraxas · @abraxas_null · [email protected] · gitea-public-only-pat-org
Gitea 1.27.3 - Gitea
public-only on a PAT is supposed to be the promise that the token cannot touch private resources. POST /user/repos has rejectPublicOnly. POST /orgs has tokenRequiresScopes and reqToken. It does not have rejectPublicOnly. DEFAULT_ALLOW_CREATE_ORGANIZATION defaults true.
A public-only PAT with write:organization creates a private organization. The same token cannot create a private user repository.
| ID | no CVE yet |
| CWE | CWE-863 |
| CVSS | Medium: 6.5 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N |
| Product | Gitea |
| Affected | through v1.27.3 (146cc3e) |
| Auth | public-only PAT with org write |
| License | GNU Affero GPL v3.0 |
| Lab | 127.0.0.1 only |
Use a stolen or over-issued public-only PAT that also has write:organization. Create a private organization. That org is a hiding place the token was not supposed to be able to make. The same token still cannot create a private user repository, and this bug does not open someone else's existing private git.
Integrity, not a private-git dump. Useful when the victim issued "public-only" on purpose: CI, a bot, a contractor token they thought could not grow a private org.
Org-repo create only checks org visibility. Deprecated POST /org/{org}/repos skips public-only entirely. I labbed org create. That is enough.
Same leftover pass as the hostmatcher 0.0.0.0/8 lab: v1.27.3 after the GHSA wave, then the handlers that still skip a gate a sibling already has. Visibility and token-scope bugs were a theme of that wave. I grepped rejectPublicOnly in api.go. User-repo create has it. Org create does not.
I minted a PAT with scopes public-only,write:organization,write:repository,write:user. Private org create returned 201. Same token, private user-repo create, 403 this endpoint is not available for public-only tokens. That 403 is the control. If both had 201, the middleware would be gone entirely. If both had 403, there would be nothing to file.
Wrong turns already recorded: treating org HTTP 201 as enough (confirm visibility=private on GET); private user-repo create succeeding (then rejectPublicOnly is gone - lab requires 403); reading existing private git contents; a reverse shell. Theatre.
cd lab
./run.sh
Target only http://127.0.0.1:18132. Compose sets DEFAULT_ALLOW_CREATE_ORGANIZATION=true.
token-scopes=public-only,write:organization,write:repository,write:user
org-create status=201
org-visibility='private'
user-repo-create status=403 this endpoint is not available for public-only tokens
SUCCESS GITEA-PUBLIC-ONLY-PAT
Put rejectPublicOnly() on POST /orgs, and treat org-repo create as public-only-sensitive too. Public-only org create must 403 the same way private user-repo create already does.
api.go (rejectPublicOnly, POST /orgs, POST /user/repos)GNU Affero GPL v3.0. See LICENSE. Loopback lab only. No warranty.