Spingarbor

Existe uma autorização incorreta na interface experimental `/v2`.

O Gogs, um serviço Git de código aberto e auto-hospedado, contém um problema de bypass de controle de acesso. Colaboradores do repositório com permissões de escrita podem excluir branches protegidas, incluindo a branch padrão, ao enviar uma solicitação POST direta. Isso contorna o mecanismo de proteção de branch, permitindo escalonamento de privilégios do nível de escrita para o nível de administrador. A vulnerabilidade existe na função `DeleteBranchPost` dentro do arquivo `internal/route/repo/branch.go`, especificamente nas linhas 110-155. A operação de exclusão pela interface web não aciona os Git Hooks, os quais previnem corretamente a exclusão de branch protegida via push SSH. Os atacantes devem ter permissões de escrita no repositório alvo e acesso à interface web do Gogs para explorar este problema. O código vulnerável carece de verificações para branches protegidas e padrão, enquanto a camada de interface de usuário e os Git Hooks implementam corretamente essas verificações. O endpoint de API vulnerável é '/delete/*' e o parâmetro vulnerável é o nome da branch.

O Gogs, um serviço Git auto-hospedado, possui uma falha de controle de acesso. Usuários autenticados com acesso de escrita em um repositório podem modificar rótulos pertencentes a outros repositórios. Isso ocorre devido a uma falha na função `UpdateLabel` dentro da Interface Web (`internal/route/repo/issue.go`) ao verificar se o rótulo sendo modificado pertence ao repositório correto. O problema reside no endpoint de atualização de rótulos da Interface Web, `POST /:username/:reponame/labels/edit`, onde a função handler `UpdateLabel` utiliza uma consulta ao banco de dados que ignora a validação de propriedade do repositório. Especificamente, a função `database.GetLabelByID(f.ID)` é chamada com `repoID=0`, o que ignora as restrições do repositório. A vulnerabilidade permite a potencial interrupção da classificação de issues, ocultação de issues de segurança e sabotagem de fluxos de trabalho. O código vulnerável está localizado em `internal/route/repo/issue.go:1040-1054`. O endpoint da API utilizado para exploração é `/api/v1/labels/edit`. O parâmetro vulnerável é `id`.

O Devtron é uma plataforma de integração de ferramentas para Kubernetes. Existe uma falha na interface da API de Attributes que permite a usuários autenticados obter a chave de assinatura do Token de API global acessando o endpoint `/orchestrator/attributes?key=apiTokenSecret`. A obtenção desta chave permite que atacantes forjem tokens JWT para identidades de usuário arbitrárias offline, potencialmente concedendo controle completo sobre a plataforma Devtron e permitindo movimento lateral para o cluster Kubernetes subjacente. O problema foi resolvido com o commit d2b0d26.

O software não valida corretamente a propriedade do projeto ao lidar com operações de projetos da organização. Isso permite que um usuário com acesso de escrita ao projeto em uma organização potencialmente modifique projetos pertencentes a outra organização. Este é um problema de IDOR (Referência Direta a Objeto Insegura).

Nome do Software Vulnerável e Versões Afetadas Gitea (versões afetadas não especificadas) Descrição A API de notificação não revalida as permissões de acesso ao repositório ao fornecer detalhes das notificações. Especificamente, após o acesso de um usuário a um repositório privado ser revogado, ele ainda pode visualizar os títulos de problemas e pull requests por meio de notificações recebidas anteriormente. Recomendações No momento, não há informações sobre uma versão mais recente que contenha uma correção para esta vulnerabilidade.

Nome do Software Vulnerável e Versões Afetadas Gitea (versões afetadas não especificadas) Descrição A API do cronômetro no Gitea não revalida as permissões de acesso ao repositório. Isso significa que, se o acesso de um usuário a um repositório privado for revogado, ele ainda poderá visualizar títulos de problemas e nomes de repositórios por meio de cronômetros previamente iniciados. Este problema afeta a capacidade de controlar o acesso às informações do repositório após as permissões terem sido alteradas. Recomendações No momento, não há informações sobre uma versão mais recente que contenha uma correção para esta vulnerabilidade.

O Gitea não verifica adequadamente a autorização ao cancelar auto-merges agendados através da interface web. Um usuário com acesso de leitura a pull requests pode conseguir cancelar auto-merges agendados por outros usuários. Isso impacta o processo de autorização para o cancelamento de auto-merges agendados.

O Gitea não valida corretamente a propriedade do repositório durante a exclusão de bloqueios do Git LFS. Isso permite que um usuário com acesso de gravação a um repositório exclua potencialmente bloqueios do LFS que pertencem a outros repositórios. O problema envolve validação inadequada ao excluir bloqueios do Git LFS.

Nome do Software Vulnerável e Versões Afetadas Gitea (versões afetadas não especificadas) Descrição Um usuário autenticado pode ser capaz de modificar as configurações de visibilidade das identidades OpenID de outros usuários devido à validação incorreta de propriedade ao alternar a visibilidade do URI OpenID. Recomendações No momento, não há informações sobre uma versão mais recente que contenha uma correção para esta vulnerabilidade.

O software não verifica corretamente a propriedade dos repositórios ao gerenciar anexos vinculados a releases. Isso pode levar a uma situação em que um anexo de um repositório privado é incorretamente associado a um release em um repositório público, expondo potencialmente o anexo ao acesso não autorizado.

O Gitea não valida corretamente o contexto do repositório durante a exclusão de anexos. Um usuário que fez upload de um anexo para um repositório pode conseguir excluí-lo mesmo após perder o acesso a esse repositório, ao enviar a solicitação através de um repositório diferente ao qual ele está autorizado a acessar. Isso ocorre porque o sistema falha em confirmar adequadamente a permissão do usuário para excluir o anexo dentro do repositório original.

O Gitea pode enviar e-mails de notificação de lançamento de repositórios privados para usuários cujo acesso foi revogado. Isso ocorre quando um repositório é alterado de público para privado, potencialmente divulgando títulos de lançamento, tags e conteúdo a usuários que anteriormente acompanhavam o repositório.