Gitea
CVE-2026-56443
MEDIUM
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Requires valid instance account to mint PAT (PR:L); read-only bypass of Limited-visibility content (C:L); write denied by PoC (I:N, A:N); no scope change.
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Lifecycle Timeline
2DescriptionGitHub Advisory
Summary
After PR #37118 / CVE-2026-25714 (fix: Unify public-only token filtering in API queries and repo access checks, merged 2026-05-18, backport #37773 to 1.26.2 - the May 2026 unification pass for public-only token filtering, reporter Medoedus per the 1.26.2 release notes), the public-only PAT scope is still bypassable on Repository and Package scope categories when the owner's Visibility = Limited (instance-internal).
The sibling Org / User / ActivityPub cases in the same checkTokenPublicOnly switch correctly reject Limited owners via !Visibility.IsPublic(). The Repository / Package cases use repo.IsPrivate or Owner.Visibility.IsPrivate(), both of which return false for VisibleTypeLimited - so a public-only PAT strictly exceeds anonymous reach on a Limited owner.
Tested on gitea/gitea:1.26.2. The decisive marker is that PR #37118's unification IS applied in the version under test (User-category PROBE returns 403 "token scope is limited to public users"). Despite that, the Repository-category PROBE on the same Limited owner with the same PAT returns 200 and serves content.
Affected entry points (4 spots)
| File:Line | Function | Affected surface |
|---|---|---|
routers/api/v1/api.go:292 | checkTokenPublicOnly Package case | API v1 packages |
routers/api/packages/api.go:76 | reqPackageAccess middleware | All 24 native package registries (/api/packages/<type>/...) |
services/context/api.go | TokenCanAccessRepo helper | All API v1 Repository-category endpoints - content, issues, PRs, releases, labels, milestones, etc. |
services/context/permission.go:32 | CheckTokenScopes (called via CheckRepoScopedToken) | Web download endpoints /raw, /media, /attachments. LFS routes (services/lfs/server.go:470/472, services/lfs/locks.go:62/151/216/284) also chain through this helper. |
All four sinks check repo.IsPrivate or Owner.Visibility.IsPrivate() only. VisibleTypeLimited falls through.
// modules/structs/visible_type.go
func (vt VisibleType) IsPrivate() bool { return vt == VisibleTypePrivate } // line 39-40
func (vt VisibleType) IsLimited() bool { return vt == VisibleTypeLimited } // line 33-34Same-file evidence (routers/api/v1/api.go:246-299 after PR #37118)
case auth_model.AccessTokenScopeCategoryOrganization:
orgPrivate := ... && !ctx.Org.Organization.Visibility.IsPublic() // !IsPublic ✓
case auth_model.AccessTokenScopeCategoryUser:
if ... && !ctx.ContextUser.Visibility.IsPublic() { ... } // !IsPublic ✓
case auth_model.AccessTokenScopeCategoryActivityPub:
if ... && !ctx.ContextUser.Visibility.IsPublic() { ... } // !IsPublic ✓
case auth_model.AccessTokenScopeCategoryPackage:
if ctx.Package != nil && ctx.Package.Owner.Visibility.IsPrivate() { // IsPrivate ONLY ✗
ctx.APIError(http.StatusForbidden, "token scope is limited to public packages")
return
}TokenCanAccessRepo (services/context/api.go) reduces to !repo.IsPrivate:
// A public-only token cannot reach a private repo; any other token is unrestricted by this check.
func (ctx *APIContext) TokenCanAccessRepo(repo *repo_model.Repository) bool {
return repo == nil || !ctx.PublicOnly || !repo.IsPrivate
}CheckTokenScopes (services/context/permission.go:32):
if publicOnly && repo != nil && repo.IsPrivate {
ctx.HTTPError(http.StatusForbidden)
return
}PoC (Docker e2e VERIFIED on gitea/gitea:1.26.2, 2026-06-05)
Full script in the report (run-poc.sh). Setup:
- Create user
limuser.PATCH /api/v1/admin/users/limuserwith body
{"visibility":"limited", ...} - response confirms "visibility":"limited".
- Upload a generic package as
limuser:
PUT /api/packages/limuser/generic/secretpkg/1.0.0/secret.txt with body secret-content-internal-only → 201.
- Create user
attacker. - Mint PAT for
attackerwithscopes=["read:package","read:user","read:repository","public-only"].
Result on gitea/gitea:1.26.2 - nine PROBEs:
PROBE A (download package via attacker PAT)
HTTP=200 Body: secret-content-internal-only
PROBE C (read README of limuser's PUBLIC repo)
HTTP=200 Body: {"name":"README.md", ...}
PROBE F (sanity - User category, same PAT, same owner)
HTTP=403 Body: {"message":"token scope is limited to public users"}
PROBE G (Repository category, same PAT, same owner)
HTTP=200 Body: {"name":"README.md", ...} ← bypass
PROBE H (list limuser's repos, User category)
HTTP=403 Body: {"message":"token scope is limited to public users"}
PROBE M (git HTTPS smart protocol - info/refs)
HTTP=200 Body: 001e
# service=git-upload-pack ... HEAD ... ← full clone enabled
PROBE N (write attempt: POST contents/hacked.txt)
HTTP=403 Body: {"message":"user should have a permission to write to the target branch"}
Integrity:N confirmed
PROBE O (Limited ORG - same bypass class)
Org category : HTTP=403 {"message":"token scope is limited to public orgs"}
Repo category : HTTP=200 README content ← bypass
Anonymous baseline (no auth) on every above endpoint: HTTP=401/404Gitea's own server error string in PROBE F / H / O - *"token scope is limited to public users"* / *"public orgs"* - is the explicit declaration of intent. Repository / Package category violates that intent on the same Limited owner.
Why this is not a duplicate of CVE-2026-25714
CVE-2026-25714 / PR #37118 (the May 2026 unification pass for public-only token filtering, merged 2026-05-18, backported to 1.26.2 via PR #37773) realigned checkTokenPublicOnly's Org / User / ActivityPub cases on !Visibility.IsPublic() and introduced the TokenCanAccessRepo helper for the Repository / Issue / Notification cases.
PROBE F on 1.26.2 returns 403 "token scope is limited to public users" for the User category - i.e. PR #37118's unification IS in effect on the version under test. The Repository / Package leak occurs *after* that fix; the Limited gap is the next residual issue on the same hygiene effort (the Package case was not touched, and TokenCanAccessRepo reduces to !repo.IsPrivate without consulting owner visibility), not the same bug.
Suggested fix (4 spots, 1-line shape each)
// routers/api/v1/api.go:292 (checkTokenPublicOnly Package case)
- if ctx.Package != nil && ctx.Package.Owner.Visibility.IsPrivate() {
+ if ctx.Package != nil && !ctx.Package.Owner.Visibility.IsPublic() {
// routers/api/packages/api.go:76 (reqPackageAccess middleware)
- if ctx.Package != nil && ctx.Package.Owner.Visibility.IsPrivate() {
+ if ctx.Package != nil && !ctx.Package.Owner.Visibility.IsPublic() {
// services/context/api.go (TokenCanAccessRepo helper)
- return repo == nil || !ctx.PublicOnly || !repo.IsPrivate
+ return repo == nil || !ctx.PublicOnly ||
+ (!repo.IsPrivate && repo.Owner != nil && repo.Owner.Visibility.IsPublic())
// services/context/permission.go:32 (CheckTokenScopes)
- if publicOnly && repo != nil && repo.IsPrivate {
+ if publicOnly && repo != nil &&
+ (repo.IsPrivate || (repo.Owner != nil && !repo.Owner.Visibility.IsPublic())) {This aligns the Repository / Package categories with the User / Org / ActivityPub siblings already shipped in PR #37118.
Reporter
JebeenLee
AnalysisAI
Public-only PAT scope enforcement in Gitea is bypassed for Repository and Package categories when the resource owner has Visibility = Limited (instance-internal), allowing a low-privileged attacker with a public-only token to read internal content that exceeds anonymous reach. Affected are all API v1 Repository endpoints, all 24 native package registries, web download routes (/raw, /media, /attachments), and LFS routes in Gitea versions prior to 1.27.0. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Two conditions must be met: (1) the attacker holds a valid Gitea account on the target instance - this is required to mint any PAT, including a public-only one; and (2) at least one user or organization on the instance has Visibility configured as Limited (instance-internal), which is a non-default setting that must be explicitly chosen by the account owner or an administrator. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | The CVSS 3.1 vector AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N (score 4.3) is well-calibrated: network-accessible, low complexity, requires a valid Gitea account (PR:L) to mint a PAT, no user interaction, scoped to the vulnerable instance, with confidentiality impact limited to reading Limited-visibility content. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | An attacker who holds any valid Gitea account on a target instance mints a public-only PAT (with read:repository and read:package scopes) and issues API requests to `/api/v1/repos/limuser/secretrepo/contents/` or `/api/packages/limuser/generic/secretpkg/1.0.0/secret.txt`, where `limuser` has Visibility set to Limited. The requests return HTTP 200 with full content despite the public-only restriction, matching the behavior demonstrated in the verified PoC (run-poc.sh, gitea/gitea:1.26.2). … |
| Remediation | Upgrade to Gitea 1.27.0, which fixes all four affected code paths by aligning the Repository and Package category checks to use `!IsPublic()` (consistent with the Org/User/ActivityPub branches corrected in PR #37118). … Detailed patch versions, workarounds, and compensating controls in full report. |
Threat intelligence, references, and detailed analysis are available after sign-in.
Broken access control in Gitea's Composer package registry (versions up to and including 1.26.1) lets remote attackers r
Gitea before 1.16.7 does not escape git fetch remote. Rated high severity (CVSS 7.5), this vulnerability is remotely exp
The git hook feature in Gitea 1.1.0 through 1.12.5 might allow for authenticated remote code execution in customer envir
Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in Gitea Gitea
Container escape in Gitea act_runner (Docker backend, through act 0.262.0) lets an authenticated user with workflow-exec
models/repo_mirror.go in Gitea before 1.7.6 and 1.8.x before 1.8-RC3 mishandles mirror repo URL settings, leading to rem
An issue was discovered in Gitea through 1.11.5. Rated high severity (CVSS 7.5), this vulnerability is remotely exploita
Missing Authorization in GitHub repository go-gitea/gitea prior to 1.16.4. Rated high severity (CVSS 7.1), this vulnerab
Open Redirect on login in GitHub repository go-gitea/gitea prior to 1.16.5. Rated medium severity (CVSS 6.1), this vulne
Reverse-proxy authentication bypass in the official Gitea Docker image (versions up to and including 1.26.2) allows any
Branch-protection bypass in Gitea's self-hosted Git server (all versions before 1.26.0) allows a user with push access t
Migration transport protections in Gitea are bypassed for Git LFS operations, affecting all self-hosted instances before
Same weakness CWE-863 – Incorrect Authorization
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today
GHSA-7p4h-3gxq-x3h3