CVE-2026-20706: 
취약성 분석 및 완화

CVE-2026-20706 is a token scope bypass vulnerability in Gitea affecting the web archive download endpoint (/archive/*). It allows a personal access token with any non-repository scope (e.g., read:issue or read:misc) to download full repository archives (zip/tar.gz) of private repositories the token owner has access to. All Gitea versions up to and including 1.26.1 are affected; the issue is patched in version 1.26.2. It carries a CVSS v4.0 base score of 5.3 (Medium) (GitHub Advisory).

The root cause is an incomplete authorization check (CWE-863: Incorrect Authorization) introduced when PR #37698 added checkDownloadTokenScope to the /raw/*, /media/*, and attachment download endpoints but omitted the /archive/* endpoint. The Download function in routers/web/repo/repo.go:372 accepts OAuth2 tokens via webAuth.AllowOAuth2 middleware but never calls checkDownloadTokenScope or CheckRepoScopedToken, meaning token scope is not validated for this route. By contrast, the equivalent API endpoint (/api/v1/repos/{owner}/{repo}/archive/*) correctly enforces scope via tokenRequiresScopes(AccessTokenScopeCategoryRepository), and git HTTP endpoints enforce scope via CheckRepoScopedToken in httpBase. The suggested fix is to add checkDownloadTokenScope(ctx) to both Download and InitiateDownload functions in routers/web/repo/repo.go (GitHub Advisory, Gitea Advisory).

Successful exploitation results in unauthorized disclosure of full private repository contents — including all source code, configuration files, and potentially embedded secrets — to any token holder whose token carries a non-repository scope. Because the /archive/* endpoint serves the entire repository as a zip or tar.gz archive, the confidentiality impact is broader than the previously patched individual file download endpoints. There is no integrity or availability impact, but exposed source code could facilitate further attacks such as credential harvesting or supply chain compromise (GitHub Advisory).

1. Obtain a token: Create or obtain a Gitea personal access token scoped to any non-repository category, such as read:misc or read:issue, for an account that has read access to the target private repository.
2. Identify target repository: Determine the owner and repository name of a private Gitea repository accessible to the token's owner.
3. Send archive download request: Issue an authenticated HTTP GET request to the archive endpoint using the token:

   GET /{owner}/{private-repo}/archive/main.tar.gz
   Authorization: token <your_non-repo-scoped_token>

4. Receive full repository archive: The server responds with HTTP 200 OK and delivers the complete repository archive (zip or tar.gz), bypassing the expected 403 Forbidden response that would be returned for properly scoped endpoints like /raw/* (GitHub Advisory).

• Network: HTTP GET requests to /{owner}/{repo}/archive/*.tar.gz or /{owner}/{repo}/archive/*.zip authenticated with tokens that have non-repository scopes (e.g., read:misc, read:issue).
• Logs: Gitea access logs showing 200 OK responses to /archive/* endpoints from tokens not expected to have repository read access; cross-reference token scope against the download activity.
• Behavioral: Repeated or automated archive downloads of private repositories, especially across multiple repositories in a short time window, using the same token.

Upgrade Gitea to version 1.26.2 or later, which adds checkDownloadTokenScope(ctx) to the Download and InitiateDownload functions in routers/web/repo/repo.go, closing the scope bypass. No configuration-based workaround is available for unpatched versions; restricting network access to the Gitea instance can reduce exposure but does not eliminate the risk for authenticated users. Organizations should also audit existing personal access tokens and revoke any with broader-than-necessary scopes (GitHub Advisory, Gitea Release).

The vulnerability was discovered via variant analysis of PR #37698 by researcher geoo115 and responsibly disclosed to the Gitea maintainers. The advisory was published by Gitea maintainer lunny on June 5, 2026, and added to the GitHub Advisory Database on June 16, 2026. No significant broader media coverage or notable community commentary beyond the official advisory has been identified (GitHub Advisory).