Gitea: LFS authentication bypass via malformed SSH sub-verb allows unauthorized read access to private repositories (CVE-2026-58423)
A vulnerability in Gitea's SSH LFS sub-verb handling allows any authenticated SSH user to bypass access controls and obtain valid LFS credentials for private repositories they do not have permission to access. This flaw enables unauthorized read access to all LFS objects in any private repository on the instance. The issue arises because unknown LFS sub-verbs cause the permission check to incorrectly grant access. This affects Gitea versions from 1.23.0 up to but not including 1.26.3. No official patch or fix has been confirmed yet.
AI Analysis
Technical Summary
Gitea versions >=1.23.0 <1.26.3 contain a vulnerability (CVE-2026-58423) in the SSH LFS sub-verb handling logic. When an SSH LFS command is issued with an unknown sub-verb, the permission check incorrectly grants read access to private repositories regardless of the user's actual permissions. This occurs because the access mode defaults to AccessModeNone (0), and the permission comparison logic treats this as sufficient for access, bypassing intended restrictions. Consequently, an attacker with SSH access can generate a valid LFS JWT token for any private repository and download all LFS objects without authorization. The vulnerability affects production deployments with SSH and LFS enabled (default configuration).
Potential Impact
Any authenticated SSH user on a vulnerable Gitea instance can bypass repository access controls to read LFS objects from any private repository. This results in a confidentiality breach exposing potentially sensitive or proprietary data stored in LFS objects. The vulnerability does not affect integrity or availability but compromises data privacy across all private repositories on the instance.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The suggested fix involves validating the LFS sub-verb before permission checks and rejecting unknown verbs with an error instead of defaulting to AccessModeNone. Until an official fix is released, restrict SSH access to trusted users only and consider disabling LFS over SSH if feasible.
Gitea: LFS authentication bypass via malformed SSH sub-verb allows unauthorized read access to private repositories (CVE-2026-58423)
Description
A vulnerability in Gitea's SSH LFS sub-verb handling allows any authenticated SSH user to bypass access controls and obtain valid LFS credentials for private repositories they do not have permission to access. This flaw enables unauthorized read access to all LFS objects in any private repository on the instance. The issue arises because unknown LFS sub-verbs cause the permission check to incorrectly grant access. This affects Gitea versions from 1.23.0 up to but not including 1.26.3. No official patch or fix has been confirmed yet.
CVSS v3.1
Score 7.7high
Affected software
Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
Gitea versions >=1.23.0 <1.26.3 contain a vulnerability (CVE-2026-58423) in the SSH LFS sub-verb handling logic. When an SSH LFS command is issued with an unknown sub-verb, the permission check incorrectly grants read access to private repositories regardless of the user's actual permissions. This occurs because the access mode defaults to AccessModeNone (0), and the permission comparison logic treats this as sufficient for access, bypassing intended restrictions. Consequently, an attacker with SSH access can generate a valid LFS JWT token for any private repository and download all LFS objects without authorization. The vulnerability affects production deployments with SSH and LFS enabled (default configuration).
Potential Impact
Any authenticated SSH user on a vulnerable Gitea instance can bypass repository access controls to read LFS objects from any private repository. This results in a confidentiality breach exposing potentially sensitive or proprietary data stored in LFS objects. The vulnerability does not affect integrity or availability but compromises data privacy across all private repositories on the instance.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The suggested fix involves validating the LFS sub-verb before permission checks and rejecting unknown verbs with an error instead of defaulting to AccessModeNone. Until an official fix is released, restrict SSH access to trusted users only and consider disabling LFS over SSH if feasible.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- Gitea
- Date Reserved
- 2026-06-30T18:57:20.614Z
- Cvss Version
- 3.1
- State
- PUBLISHED
- Remediation Level
- null
- Gcve Source
- db.gcve.eu
Threat ID: 6a483c9d27e9c79719d7f5d4
Added to database: 07/03/2026, 22:50:05 UTC
Last enriched: 07/22/2026, 01:47:10 UTC
Last updated: 07/31/2026, 19:22:59 UTC
Views: 59
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.