Z3R0S6

Existe uma leitura fora dos limites (out-of-bounds read) na lógica de correspondência de blocos do remetente. Um receptor malicioso pode disparar o acesso à memória antes do início de um buffer alocado ao enviar um bloco de soma de verificação (checksum) manipulado com comprimento zero. Isso causa um cálculo de deslocamento negativo durante a computação de delta, resultando em uma leitura fora dos limites da memória do buffer de dados do arquivo no lado do remetente.

Um bypass de confinamento de caminho permite que clientes remotos escapem do confinamento da raiz do módulo interno pretendido. Isso ocorre quando a raiz do módulo contém um marcador de limite `/./`, permitindo a construção de caminhos que resolvem fora do limite do chroot. Atacantes podem explorar a manipulação inadequada da notação `/./` ou forjar transferências de base delta que referenciam caminhos xname que cruzam o limite `/./` para obter acesso de leitura ou gravação não autorizado a arquivos fora da subárvore do módulo.

Existe um estouro de inteiro assinado na implementação de tempo limite (timeout) de E/S. Um invasor pode injetar mensagens `MSG IO TIMEOUT` contendo valores não positivos (zero ou negativos), fazendo com que a variável de tempo limite envolva. Isso impede que a verificação de tempo limite seja disparada, permitindo que conexões ociosas ou travadas ocupem slots do daemon indefinidamente, resultando em exaustão de recursos.

Existe uma falha de bypass de autorização nos endpoints de anexo do nível web, onde o controle de acesso para releases em rascunho (draft) não é aplicado. Enquanto os endpoints da API restringem corretamente o acesso a releases em rascunho para usuários com permissões de escrita, o manipulador do lado web `ServeAttachment()` verifica apenas as permissões de leitura no nível do repositório. Isso permite que qualquer usuário, incluindo chamadores anônimos não autenticados, baixe o conteúdo completo de um anexo caso obtenha seu UUID. Este problema afeta os seguintes endpoints: - `/attachments/{uuid}` - `/{owner}/{repo}/attachments/{uuid}` - `/{owner}/{repo}/releases/attachments/{uuid}` A falha pode ser explorada se um UUID for vazado por canais secundários, como histórico do navegador, logs do servidor, e-mail ou links públicos. Isso pode levar à divulgação de informações sensíveis, incluindo binários de pré-lançamento, candidatos a correções de segurança, SBOMs internos ou rascunhos de notas de lançamento.