GHSA-7wvc-rvp7-w99x

Summary

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...