abraxaslabs.tech · github.com/abraxas · @abraxas_null · [email protected] · gitea-public-only-pat-org
Gitea 1.27.3 - Gitea
PAT 上的 public-only 本应是这样的承诺：该令牌无法触碰私有资源。POST /user/repos 有 rejectPublicOnly。POST /orgs 有 tokenRequiresScopes 和 reqToken。它没有 rejectPublicOnly。DEFAULT_ALLOW_CREATE_ORGANIZATION 默认为 true。
一个带有 write:organization 的 public-only PAT 可以创建私有组织。同一个令牌却无法创建私有用户仓库。
| ID | 暂无 CVE |
| CWE | CWE-863 |
| CVSS | 中危：6.5 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N |
| 产品 | Gitea |
| 受影响版本 | 至 v1.27.3（146cc3e） |
| 认证 | 带组织写权限的 public-only PAT |
| 许可证 | GNU Affero GPL v3.0 |
| 实验环境 | 仅 127.0.0.1 |
使用一个被盗或过度签发的 public-only PAT，且该令牌同时具有 write:organization。创建一个私有组织。该组织是一个藏身之处，而该令牌本不应能够创建它。同一个令牌仍然无法创建私有用户仓库，并且此漏洞不会打开他人已有的私有 git。
这是完整性（Integrity）问题，而非私有 git 数据泄露。当受害者有意签发 "public-only" 时（CI、机器人、他们认为无法创建私有组织的承包商令牌），此漏洞尤为有用。
组织仓库创建仅检查组织可见性。已弃用的 POST /org/{org}/repos 完全跳过 public-only 检查。我在实验环境中验证了组织创建。这就足够了。
与 hostmatcher 0.0.0.0/8 实验相同的遗留排查过程：GHSA 浪潮之后的 v1.27.3，然后检查那些仍然跳过了同级处理器已具备的关卡的处理程序。可见性和令牌作用域漏洞是那一波浪潮的主题。我在 api.go 中 grep 了 rejectPublicOnly。用户仓库创建有它。组织创建没有。
我签发了一个作用域为 public-only,write:organization,write:repository,write:user 的 PAT。私有组织创建返回 201。同一个令牌，私有用户仓库创建，返回 403 this endpoint is not available for public-only tokens。那个 403 就是对照组。如果两者都返回 201，说明中间件完全消失了。如果两者都返回 403，那就没有什么可提交的。
已记录的弯路：把组织 HTTP 201 当作足够（需在 GET 上确认 visibility=private）；私有用户仓库创建成功（那么 rejectPublicOnly 就消失了——实验要求 403）；读取已有私有 git 内容；反弹 shell。都是做戏。
cd lab
./run.sh
目标仅限 http://127.0.0.1:18132。Compose 设置了 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
在 POST /orgs 上加上 rejectPublicOnly()，并将组织仓库创建同样视为对 public-only 敏感。public-only 的组织创建必须像私有用户仓库创建那样返回 403。
api.go（rejectPublicOnly、POST /orgs、POST /user/repos）GNU Affero GPL v3.0。参见 LICENSE。仅限回环实验环境。无任何担保。