{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/tags/lfs/feed.json","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[{"cvss":7.7,"id":"CVE-2026-58423"}],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Gitea (1.23.0 to 1.26.2)"],"_cs_severities":["high"],"_cs_tags":["gitea","lfs","ssh","authentication-bypass","information-disclosure","vulnerability"],"_cs_type":"advisory","_cs_vendors":["Gitea"],"content_html":"\u003cp\u003eA critical flaw identified as CVE-2026-58423 exists within Gitea's handling of Git Large File Storage (LFS) over SSH. This vulnerability affects Gitea versions from 1.23.0 up to, but not including, 1.26.3, when deployed in production mode with SSH and LFS enabled. Any authenticated SSH user, regardless of their repository access permissions, can craft a malformed \u003ccode\u003egit-lfs-authenticate\u003c/code\u003e SSH command with an unrecognized sub-verb (e.g., \u0026quot;badverb\u0026quot;). This crafted command bypasses Gitea's standard permission checks, leading to the generation of valid LFS JWT tokens. Attackers can then leverage these tokens to download LFS objects from any private repository on the instance, leading to a significant confidentiality breach. The issue stems from insufficient validation of LFS sub-verbs in \u003ccode\u003ecmd/serv.go\u003c/code\u003e and \u003ccode\u003erouters/private/serv.go\u003c/code\u003e, combined with lax token validation for download operations in \u003ccode\u003eservices/lfs/server.go\u003c/code\u003e.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn authenticated attacker, possessing a valid SSH key and access to a Gitea instance, targets a private repository for which they have no legitimate read permissions.\u003c/li\u003e\n\u003cli\u003eThe attacker executes a crafted SSH command against the Gitea instance, using a malformed \u003ccode\u003egit-lfs-authenticate\u003c/code\u003e command with an invalid sub-verb (e.g., \u003ccode\u003essh git@gitea-instance \u0026quot;git-lfs-authenticate admin/private-repo.git badverb\u0026quot;\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eGitea's \u003ccode\u003egetAccessMode\u003c/code\u003e function, when encountering the unrecognized LFS sub-verb in a production environment, defaults to returning \u003ccode\u003eperm.AccessModeNone\u003c/code\u003e (value \u003ccode\u003e0\u003c/code\u003e) due to a logging-only error handling.\u003c/li\u003e\n\u003cli\u003eThe subsequent permission check within \u003ccode\u003eServCommand\u003c/code\u003e (at line ~322) evaluates \u003ccode\u003euserMode \u0026lt; mode\u003c/code\u003e as \u003ccode\u003euserMode \u0026lt; 0\u003c/code\u003e, which is always false, effectively bypassing the authorization check for private repositories.\u003c/li\u003e\n\u003cli\u003eGitea proceeds to generate and return a valid LFS JWT token to the attacker, containing an \u003ccode\u003eOp: \u0026quot;badverb\u0026quot;\u003c/code\u003e claim.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the obtained JWT token to send an HTTP POST request to the Gitea LFS batch endpoint (e.g., \u003ccode\u003ehttps://gitea-instance/admin/private-repo.git/info/lfs/objects/batch\u003c/code\u003e), requesting download details for specific LFS objects.\u003c/li\u003e\n\u003cli\u003eThe Gitea LFS server processes the request; importantly, it does not validate the \u003ccode\u003eOp\u003c/code\u003e field in the JWT token for download operations, thus accepting the illicit token.\u003c/li\u003e\n\u003cli\u003eThe attacker then uses the provided download URLs and the stolen JWT token to \u003ccode\u003ecurl\u003c/code\u003e and retrieve the private LFS object content, achieving unauthorized data exfiltration.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThis vulnerability constitutes a severe confidentiality breach, enabling any user with authenticated SSH access to a Gitea instance to gain unauthorized read access to Git LFS objects stored in \u003cem\u003eany\u003c/em\u003e private repository on that instance. This includes scenarios where self-registration is enabled, allowing a malicious actor to register, obtain SSH access, and then compromise the confidentiality of all LFS data. The impact is significant for Gitea deployments relying on private repositories for sensitive code or data, as all LFS content within these repositories becomes vulnerable to unauthorized disclosure.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003ePatch CVE-2026-58423 immediately by updating Gitea instances to version \u003ccode\u003e1.26.3\u003c/code\u003e or newer.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026quot;Detect CVE-2026-58423 Exploitation - Gitea LFS Auth Bypass Attempt\u0026quot; provided in this brief to your SIEM.\u003c/li\u003e\n\u003cli\u003eEnable comprehensive \u003ccode\u003eprocess_creation\u003c/code\u003e logging on Gitea servers to monitor SSH command executions for unusual \u003ccode\u003egit-lfs-authenticate\u003c/code\u003e sub-verbs for detection of exploitation attempts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-07-21T20:44:27Z","date_published":"2026-07-21T20:44:27Z","id":"https://feed.craftedsignal.io/briefs/2026-07-gitea-lfs-auth-bypass/","summary":"A high-severity authentication bypass vulnerability (CVE-2026-58423) in Gitea's SSH Git LFS handling allows any authenticated SSH user to obtain valid LFS credentials for any private repository, enabling unauthorized download of all LFS objects from instances running Gitea versions 1.23.0 through 1.26.2.","title":"Gitea LFS Authentication Bypass via Malformed SSH Sub-Verb","url":"https://feed.craftedsignal.io/briefs/2026-07-gitea-lfs-auth-bypass/"}],"language":"en","title":"CraftedSignal Threat Feed - Lfs","version":"https://jsonfeed.org/version/1.1"}