Cassianstarck

**Nome do Software Vulnerável e Versões Afetadas** Gitea versão 1.26.2 **Description** Os manipuladores de feed RSS e Atom não aplicam restrições de escopo de token ou de acesso apenas público ao utilizar a autenticação Básica de token de API. Isso permite que um token de acesso pessoal, restringido a acesso apenas público ou que careça do escopo `repository`, acesse conteúdo privado, desde que a conta proprietária do token possua acesso de leitura legítimo ao repositório. Trata-se de uma falha de confinamento de token que expõe metadados de commits privados (SHA, mensagem completa, nome e e-mail do autor), nomes de versões privadas, notas, descrições, nomes de tags privadas e o fluxo de atividades privadas do proprietário do token. **API Endpoints:** - `/{owner}/{repo}.rss` e `/{owner}/{repo}.atom` - `/{owner}/{repo}/rss/branch/*` e `/{owner}/{repo}/atom/branch/*` - `/{owner}/{repo}/releases.rss` e `/{owner}/{repo}/releases.atom` - `/{owner}/{repo}/tags.rss` e `/{owner}/{repo}/tags.atom` - `/{user}.rss` e `/{user}.atom` **Recommendations** Para o Gitea versão 1.26.2, implemente uma verificação de escopo de token nos manipuladores `ShowBranchFeed`, `ShowRepoFeed`, `ShowFileFeed` e `ShowReleaseFeed` para garantir que os tokens não sejam apenas públicos e possuam os escopos necessários. Além disso, restrinja a lógica `includePrivate` no manipulador de feed de usuário para evitar que tokens confinados acessem fluxos de atividades privadas.

**Nome do Software Vulnerável e Versões Afetadas** Gitea versão 1.26.2 **Description** Existe uma violação de confidencialidade onde um fluxo de trabalho de pull-request de fork controlado por um invasor pode obter acesso de leitura a um terceiro repositório privado. Isso ocorre porque a função `GetActionsUserRepoPermission()` em `models/perm/access/repo permission.go` não implementa uma guarda de pull-request de fork no ramo de lógica de proprietário colaborativo. Enquanto outros caminhos de acesso negam corretamente o acesso a pull-requests de fork, este ramo específico permite que um token de tarefa obtenha `maxPerm` (leitura de código) se o repositório de destino B confiar no proprietário do repositório base A como um proprietário colaborativo, desde que o repositório A seja privado. Detalhes técnicos incluem: - **API Endpoints:** `/userb/repoB.git/info/refs?service=git-upload-pack` (usado durante a clonagem git-HTTP). - **Vulnerable Parameters or Variables:** `task.IsForkPullRequest` não é verificado no ramo de proprietário colaborativo. - **Function Names:** `GetActionsUserRepoPermission()` **Recommendations** Atualize o Gitea para uma versão onde a função `GetActionsUserRepoPermission()` seja corrigida para incluir a guarda `!task.IsForkPullRequest` dentro da verificação de proprietário colaborativo, garantindo que pull-requests de fork tenham o acesso entre repositórios negado.

**Nome do Software Vulnerável e Versões Afetadas** Gitea versões anteriores a 1.26.4 **Description** Um usuário autenticado pode usar um endpoint de API específico como um oráculo de enumeração e existência de IDs de etiquetas (labels) entre repositórios. Isso ocorre porque o sistema realiza uma busca global e sem escopo de etiquetas por ID e não verifica se a etiqueta pertence ao repositório ou organização especificada na requisição. Embora nenhum nome de etiqueta, cor ou repositório proprietário seja divulgado, e nenhuma gravação não autorizada ocorra, um invasor pode determinar se um ID de etiqueta existe em qualquer lugar da instância com base no status da resposta HTTP: uma resposta 204 No Content indica que o ID da etiqueta existe, enquanto uma resposta 422 indica que não. Isso permite a enumeração da população de etiquetas de toda a instância, incluindo etiquetas em repositórios e organizações privadas que o usuário não pode acessar. **API Endpoint:** `DELETE /repos/{owner}/{repo}/issues/{index}/labels/{id}` **Vulnerable Parameter:** `id` **Recommendations** No momento, não há informações sobre uma versão mais recente que contenha a correção para esta vulnerabilidade.