CVE-2026-56443

MEDIUMPre-NVD 4.34.3
EchelonGraph scoreLOW confidence

This medium-severity CVE scores 4.3 under the CNA's CVSS (NVD's own analysis pending). EPSS exploit-prediction score not yet available (the EPSS model rescores nightly; freshly-published CVEs typically appear within 48 hours). GitHub Security Advisory data not yet ingested — confidence will rise once GHSA publishes (typical lag: hours to days for open-source ecosystem CVEs; never for infrastructure-only CVEs).

Triggered by: NVD CVSS baseline
Sources: cna:github_m
4.3
EchelonGraph verdictMonitorLow exploitation likelihood right now — keep watching.
  • Lower severity and no public exploit yet
CISA-KEV: Not listedEPSS: CVSS: 4.3Exploit: NoneExposed: 0

No vendor fix yet — apply a workaround or compensating control (WAF / firewall / segmentation) and watch for a patch.

Gitea: Token public-only scope bypassed on Limited-visibility owners (Repository + Package categories) — residual after CVE-2026-25714 / PR #37118

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//...) | | 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-34

Same-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/limuser with 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-only201.
  • Create user attacker.
  • Mint PAT for attacker with scopes=["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/404

Gitea'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

CVSS v3
4.3
EG Score
4.3(low)
EG Risk
24(Track)
EG Risk 24/100SSVC: Track

EG Risk is EchelonGraph's 0–100 priority score: it fuses intrinsic severity with real-world exploitation and automatability so you can rank equal-severity CVEs and fix the most dangerous first. Higher = act sooner. Distinct from the 0–10 EG Score (severity).

How it’s computed
Severity43% × 45%
Exploitation0% × 40%
Automatability30% × 15%
Action: Routine — remediate on your standard cadence.
EPSS
KEV
Not listed

Published

July 21, 2026

Last Modified

July 21, 2026

Vendor Advisories for CVE-2026-56443(1)

These vendors published their own advisory mentioning this CVE — often with vendor-specific remediation steps + affected product lists not in NVD.

Affected Packages

(2 across 1 ecosystem)
Go(2)
PackageVulnerable rangeFixed inDependents
code.gitea.io/gitea1.27.0
gitea.dev1.27.0

Data Freshness Timeline

(refreshed 2× in last 7d / 2× in last 30d)

Each row is a source pipeline that fetched or updated this CVE on that date, with what changed. For example, "NVD update" means NVD published or revised its analysis for this CVE; "MITRE cvelistV5" means we ingested or refreshed it from the CNA feed. Most recent first.

  1. 2026-07-23 03:20 UTCEG score recompute
  2. 2026-07-21 20:19 UTCEG score recompute

Frequently asked(4)

What is CVE-2026-56443?
CVE-2026-56443 is a medium vulnerability published on July 21, 2026. Gitea: Token public-only scope bypassed on Limited-visibility owners (Repository + Package categories) — residual after CVE-2026-25714 / PR #37118 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…
When was CVE-2026-56443 disclosed?
CVE-2026-56443 was first published in the National Vulnerability Database on July 21, 2026. EchelonGraph re-ingests CVE updates from NVD on a 2-hour cycle, so this page reflects the latest published state.
What is the CVSS score of CVE-2026-56443?
CVE-2026-56443 has a CVSS v4.0 base score of 4.3 (CNA self-assessment; NVD's own analysis pending). The EG score is currently aggregating — additional source signals are being incorporated as they become available..
How do I remediate CVE-2026-56443?
Patch to the fixed version published by the affected vendor. Where vendor advisories exist for CVE-2026-56443, EchelonGraph cross-links them in the Vendor Advisories panel below — those typically contain the canonical remediation steps, fixed version numbers, and any vendor-specific mitigations.

Dependency Blast Radius

See which npm, PyPI, Go, and Maven packages are affected by CVE-2026-56443

Explore →

Is Your Infrastructure Affected by CVE-2026-56443?

EchelonGraph automatically scans your cloud infrastructure and maps CVE exposure using blast radius analysis.