Ohxorud-Dev

**Nome do Software Vulnerável e Versões Afetadas** Gitea (versões afetadas não especificadas) **Description** Um problema de escalação de privilégios existe no endpoint de API `POST /users/{username}/tokens` utilizado para criar Tokens de Acesso Pessoal. O endpoint é protegido pelo middleware `reqBasicOrRevProxyAuth`, que foi projetado para exigir autenticação baseada em senha para evitar que um token comprometido seja usado para gerar novos tokens. No entanto, se um token for fornecido no formato `Authorization: Basic <token>:x-oauth-basic`, o sistema define incorretamente o `AuthedMethod` como `basic` e `IsBasicAuth` como `true`, ignorando a proteção do middleware. Uma vez superada a proteção, a função `CreateAccessToken` não aplica um limite de escopo, o que significa que ela não verifica se os escopos solicitados são um subconjunto dos escopos atuais do solicitante. Consequentemente, um invasor que possua um token restrito (como um com permissões apenas de `write:user`) pode criar um novo token com o escopo `all`, obtendo acesso total à conta sem saber a senha do usuário. **Recommendations** No momento, não há informações sobre uma versão mais recente que contenha a correção para esta vulnerabilidade.

**Nome do Software Vulnerável e Versões Afetadas** Gitea versões anteriores a 1.27.0 **Description** O Gitea permite que um token com restrições `public-only,write:repository` atualize o branch de cabeça (head branch) de um pull request privado. Isso ocorre porque o sistema valida a restrição de apenas-público do token em relação à rota do repositório base público, mas não reaplica essa restrição ao repositório de cabeça privado durante o processo de atualização. Consequentemente, um invasor com tal token pode fazer com que o Gitea envie commits de um repositório base público para um branch de cabeça privado, ignorando as limitações de acesso pretendidas. Detalhes técnicos incluem: - **API Endpoint:** `POST /api/v1/repos/{public-owner}/{public-repo}/pulls/{index}/update` - **Função Vulnerável:** `UpdatePullRequest()` Se o Gitea Actions estiver habilitado no repositório de cabeça privado, esse envio não autorizado também pode disparar a execução de fluxos de trabalho (workflows) de `push` do repositório privado. **Recommendations** Atualize o Gitea para a versão 1.27.0.

**Nome do Software Vulnerável e Versões Afetadas** Gitea versões anteriores a 1.26.1 **Description** No caminho do Git Smart HTTP, o sistema falha ao aplicar as permissões de token de acesso com escopo de repositório quando os tokens são fornecidos via autenticação Bearer. Embora a função `CheckRepoScopedToken()` seja projetada para validar escopos, ela retorna prematuramente se a requisição não estiver utilizando autenticação HTTP Basic. Consequentemente, um Token de Acesso Pessoal (PAT) ou token OAuth2 enviado como `Authorization: Bearer <token>` ignora completamente as verificações de escopo. Isso permite que um token com permissões limitadas (por exemplo, apenas `read:notification`) realize operações como clonar ou buscar repositórios privados sem o escopo `read:repository`, ou enviar alterações (push) para repositórios sem o escopo `write:repository`, desde que o proprietário do token possua as permissões de RBAC de repositório necessárias. O problema afeta a função `CheckRepoScopedToken()` e impacta as rotas do Git Smart HTTP. **Recommendations** Atualize o Gitea para a versão 1.26.1 ou posterior.