Prakhar0X01

Existe um problema onde um campo de configuração, acessível a funções operacionais comuns, permite a inserção de destinos de requisição externos arbitrários sem a devida validação. Isso permite que atacantes autenticados forcem o servidor a enviar requisições para endereços de rede interna que, de outra forma, estariam inacessíveis externamente. Trata-se de um server-side request forgery (SSRF), que ocorre quando um servidor é enganado para fazer requisições a um local não pretendido.

Existe um problema em um endpoint de criação de registros que aceita o tipo de registro da requisição e insere o registro com as verificações de permissão desativadas. Isso permite que qualquer usuário autenticado, independentemente de sua função operacional, especifique um tipo de registro privilegiado para criar contas privilegiadas e assumir o controle total do site.

Existe uma falha de bypass de autorização em um endpoint que aceita uma flag fornecida pelo chamador para desativar a aplicação de permissões. Atacantes autenticados podem definir essa flag ao chamar o endpoint para ignorar as verificações de permissão e ler registros de terceiros além de sua função permitida.

O Gitea apresenta um problema onde o manipulador de hook git post-receive processa incorretamente as opções de push do git em repositórios existentes. Usuários com acesso de proprietário ou colaborador administrador podem usar as opções de push não documentadas `repo.private` e `repo.template` durante um `git push` para alternar a visibilidade de um repositório entre privado e público ou alterar seu status de template. Este processo ocorre dentro da função `HookPostReceive()` no arquivo `routers/private/hook post receive.go`. Esta ação ignora os controles de segurança padrão e o rastreamento administrativo, resultando na ausência de entradas nos logs de auditoria ou atividade do repositório, sem eventos de webhook, sem notificações em nível de organização e sem alertas de e-mail para observadores. Além disso, o uso da função `UpdateRepositoryColsNoAutoTime` suprime o carimbo de data/hora `updated at`, tornando a alteração difícil de detectar. Isso pode permitir que uma ameaça interna torne um repositório privado público temporariamente para exfiltração de dados ou manipule silenciosamente templates de repositórios para afetar pipelines de CI/CD downstream.

O Gitea contém um problema de divulgação de informações onde solicitações contendo o parâmetro de consulta `go-get` com o valor `1` ignoram as verificações de autenticação e autorização. Este comportamento é acionado nas funções `httpBase()` e `EarlyResponseForGoGetMeta()`. Quando este parâmetro é detectado no caminho de um repositório, o sistema retorna uma resposta HTTP 200 contendo tags de metadados, independentemente de o repositório ser privado ou de o usuário estar autenticado. Isso permite que invasores não autenticados confirmem a existência de repositórios privados, enumerem nomes de repositórios privados por meio de força bruta e coletem informações sensíveis, como URLs de clonagem completas, nomes de usuários proprietários e nomes de branches padrão. Isso ocorre porque o sistema foi projetado para fornecer uma solução alternativa para a maneira como a ferramenta Go lida com credenciais, resultando em um endpoint não autenticado para cada repositório.

Um Server-Side Request Forgery (SSRF) cego existe quando a configuração `[oauth2 client] UPDATE AVATAR = true` está habilitada. O problema ocorre porque o servidor busca a URL do avatar fornecida por um provedor OAuth2/OIDC — geralmente a claim `picture` — usando o cliente HTTP padrão do Go sem aplicar restrições de host ou IP de saída. Um usuário com baixos privilégios que consiga influenciar sua própria claim `picture` pode forçar o servidor Gitea a fazer requisições HTTP GET arbitrárias para endereços de loopback, endereços de rede privada RFC 1918 e endereços link-local IPv4, como `169.254.169.254`. Detalhes técnicos incluem: - **Função Vulnerável**: `oauth2UpdateAvatarIfNeed()` em `routers/web/auth/oauth.go` e `oauth2SignInSync()` em `routers/web/auth/oauth signin sync.go`. - **Variável Vulnerável**: `gothUser.AvatarURL`. Embora o problema seja primariamente cego, pois respostas que não sejam imagens são rejeitadas, o impacto aumenta se o servidor conseguir alcançar serviços de metadados de nuvem ou serviços internos que retornem dados de imagem válidos, que poderiam então ser armazenados como o avatar do usuário.

Um problema de autorização existe nos endpoints REST de Actions ao nível da organização. Os endpoints `/api/v1/orgs/{org}/actions/runs` e `/api/v1/orgs/{org}/actions/jobs` verificam apenas a associação à organização e a validade do token, falhando em realizar verificações de Lista de Controle de Acesso (ACL) por repositório. Consequentemente, qualquer membro autenticado de uma organização pode enumerar execuções e tarefas de fluxo de trabalho de todos os repositórios naquela organização, incluindo repositórios privados para os quais o usuário não possui acesso explícito ou teve permissões negadas. Esta falha permite que um invasor utilize os endpoints como um oráculo de pesquisa para coletar metadados sensíveis de repositórios privados, como nomes de repositórios, descrições, URLs de clonagem, SHAs de commit, nomes de branches, nomes de arquivos de fluxo de trabalho, mensagens de commit e identidades de contribuidores. Isso pode levar ao reconhecimento da organização, revelando planos de produtos, janelas de correções de segurança ou topologias de projetos internos.

Existe uma falha que permite a ignorar permanentemente a etapa de aprovação do fluxo de trabalho de pull request de fork. Este problema permite que um invasor contorne o processo de aprovação obrigatório ao enviar alterações de um repositório forkado.