Adamkorcz

**Name of the Vulnerable Software and Affected Versions** Allstar versions prior to 4.5 **Description** Allstar is a GitHub App used for setting and enforcing security policies. A flaw exists in the Reviewbot component where inbound webhook requests were validated against a hard-coded, shared secret. This secret token was compiled into the Allstar binary and could not be configured during runtime. Deployments using Reviewbot validated requests with the same secret unless the operator modified the source code and rebuilt the component. This expectation was not documented and easily overlooked. Deployments that have not enabled or exposed the Reviewbot endpoint are not affected. **Recommendations** Update to version 4.5 or later. If the Reviewbot endpoint is not in use, no action is required.

**Nome do Software Vulnerável e Versões Afetadas** Versões do PowSyBl anteriores à 6.7.2 **Descrição** O problema refere-se a um ataque de entidade externa XML (XXE) e um ataque de falsificação de solicitação do lado do servidor (SSRF) em determinadas partes da análise de XML do powsybl-core. Isso permite que um atacante eleve seus privilégios para ler arquivos para os quais não possui permissão, incluindo arquivos sensíveis no sistema. A classe vulnerável é `com.powsybl.commons.xml.XmlReader`, a qual é considerada não confiável em casos de uso onde usuários não confiáveis podem submeter seu XML aos métodos vulneráveis. Isso pode ocorrer em uma aplicação multi-tenant que hospeda muitos usuários diferentes, possivelmente com diferentes níveis de privilégio. **Recomendações** Para versões anteriores à 6.7.2, atualize para com.powsybl:powsybl-commons: 6.7.2 ou superior para corrigir o problema. Como solução temporária, considere restringir o acesso à classe `com.powsybl.commons.xml.XmlReader` para minimizar o risco de exploração. Evite permitir que usuários não confiáveis importem arquivos de rede CGMES ou XIIDM não confiáveis até que o problema seja resolvido.

Nome do Software Vulnerável e Versões Afetadas: com.powsybl:powsybl-iidm-criteria versões 6.3.0 até 6.7.1 com.powsybl:powsybl-contingency-api versões 5.0.0 até 5.0.0 Descrição: O problema consiste em uma vulnerabilidade potencial de Negação de Serviço por Expressão Regular polinomial (ReDoS) na classe RegexCriterion. Esta classe compila e avalia uma expressão regular não validada, fornecida pelo usuário, contra o identificador de um objeto Identifiable via Pattern.compile(regex).matcher(id).find(). Se explorada com sucesso, um ator malicioso pode causar exaustão significativa da CPU por meio de chamadas filter(...) repetidas ou recursivas — especialmente se realizadas em grandes modelos de rede ou operações de filtragem. Recomendações: Para com.powsybl:powsybl-iidm-criteria versões 6.3.0 até 6.7.1, atualize para a versão 6.7.2 ou superior. Para com.powsybl:powsybl-contingency-api versões 5.0.0, atualize para uma versão superior a 5.0.0; no entanto, a versão exata corrigida para este componente não é especificada. Como solução temporária, considere restringir o uso da classe RegexCriterion até que uma correção esteja disponível. Evite utilizar expressões regulares não confiáveis e identificadores potencialmente controlados por atacantes na classe RegexCriterion para minimizar o risco de exploração.

**Nome do Software Vulnerável e Versões Afetadas** Versões do PowSyBl de 6.3.0 a 6.7.1 **Descrição** O problema consiste em uma falha de desserialização no método `read` da classe `SparseMatrix`, o que pode levar a diversas elevações de privilégio dependendo das circunstâncias. Este método recebe um `InputStream` e retorna um objeto `SparseMatrix`. Os usuários estão vulneráveis caso importem objetos `SparseMatrix` serializados não controlados. Isso pode ser particularmente problemático em aplicações multi-tenant onde usuários com diferentes níveis de privilégio podem submeter um `InputStream` para ser processado em um `SparseMatrix`, ou ao utilizar o método em uma ferramenta local com `InputStream` proveniente de fontes externas. **Recomendações** Para as versões de 6.3.0 a 6.7.1, considere atualizar para com.powsybl:powsybl-math:6.7.2 ou superior para resolver o problema. Como medida temporária de contorno, não utilize a desserialização de `SparseMatrix` (métodos `SparseMatrix.read(...)`) até que uma correção seja aplicada.

**Nome do Software Vulnerável e Versões Afetadas** Versões do PowSyBl anteriores a 6.7.2 **Descrição** O problema é uma vulnerabilidade potencial de Negação de Serviço por Expressão Regular polinomial (ReDoS) no mecanismo DataSource do PowSyBl. Esta vulnerabilidade pode ser explorada quando o método `listNames(String regex)` é chamado em um DataSource com uma expressão regular fornecida pelo usuário, permitindo que um ator malicioso cause consumo significativo de CPU devido ao backtracking da regex. O ataque requer controle sobre a entrada da regex e influência sobre os nomes de arquivos/recursos sendo correspondidos. Em um ambiente multi-tenant, isso pode degradar o desempenho e a disponibilidade do servidor, afetando outros usuários da aplicação. **Recomendações** Para versões anteriores a 6.7.2, atualize para com.powsybl:powsybl-commons:6.7.2 ou superior para corrigir a vulnerabilidade. Como solução temporária, considere restringir o acesso ao método `listNames(String regex)` ou validar expressões regulares fornecidas pelo usuário para minimizar o risco de exploração. Evite usar expressões regulares fornecidas pelo usuário sem validação no método `listNames(String regex)` até que o problema seja resolvido.

**Nome do Software Vulnerável e Versões Afetadas** versões do tough anteriores a 0.20.0 **Descrição** O problema surge durante um rollback de snapshot quando o cliente armazena em cache incorretamente os metadados de timestamp. Isso resulta em uma falha na validação do timestamp de atualização, impedindo atualizações futuras até que o cache seja limpo. O problema ocorre porque o cliente persiste metadados de timestamp inválidos em seu cache, o que pode fazer com que ele identifique incorretamente metadados de timestamp válidos como tendo sofrido rollback. Isso impede o cliente de consumir atualizações válidas. **Recomendações** Para versões anteriores a 0.20.0, atualize para a versão 0.20.0 ou posterior do tough e assegure-se de que qualquer código bifurcado ou derivado seja corrigido para incorporar as novas correções.

**Nome do Software Vulnerável e Versões Afetadas** versões do tough anteriores a 0.20.0 **Descrição** O problema decorre da falta de validação do número da versão dos metadados root, permitindo que um ator forneça um número de versão arbitrário ao cliente. Isso pode levar o cliente a confiar em uma função root desatualizada ou rotacionada, potencialmente confiando em conteúdo associado a uma função root anterior. Os usuários devem atualizar para uma versão que incorpore as novas correções para prevenir este problema. **Recomendações** Para versões anteriores a 0.20.0, atualize para a versão 0.20.0 ou posterior do tough e garanta que qualquer código bifurcado ou derivado seja corrigido para incorporar as novas correções.

**Nome do Software Vulnerável e Versões Afetadas** versões do tough anteriores a 0.20.0 **Descrição** O problema ocorre durante um rollback de alvo quando o cliente falha em detectar o rollback para alvos delegados, potencialmente causando a busca de um alvo de uma fonte incorreta e a alteração do conteúdo do alvo. Isso pode levar o cliente a confiar e baixar alvos desatualizados que deveria rejeitar. **Recomendações** Para versões anteriores a 0.20.0, atualize para a versão 0.20.0 ou posterior do tough e garanta que qualquer código bifurcado ou derivado seja corrigido para incorporar as novas correções.

**Nome do Software Vulnerável e Versões Afetadas** versões do tough anteriores a 0.20.0 **Descrição** O problema surge da falta de validação de delegação terminadora, fazendo com que o cliente continue pesquisando na lista de delegações definida mesmo após encontrar uma delegação terminadora. Isso pode levar o cliente a buscar um alvo de uma fonte incorreta, alterando o conteúdo do alvo. Delegações são um mecanismo que permite que múltiplas identidades forneçam e assinem conteúdo dentro de um único repositório, sendo que delegações terminadoras e prioridade de delegação conferem controle inequívoco sobre como delegações sobrepostas são resolvidas. No entanto, o cliente tough, erroneamente, não encerra a pesquisa conforme necessário e aceita informações de uma delegação de prioridade mais baixa que deveria ter sido ignorada. Ao interagir com repositórios que utilizam delegações, o cliente tough pode buscar alvos pertencentes à função incorreta, permitindo que um ator com propriedade delegada forneça conteúdos arbitrários. **Recomendações** Para versões anteriores a 0.20.0, atualize para a versão 0.20.0 ou posterior do tough e garanta que qualquer código bifurcado ou derivado seja corrigido para incorporar as novas correções.

**Nome do software vulnerável e versões afetadas** Versões do go-tuf anteriores à 2.0.1 **Descrição** O cliente go-tuf rastreia as delegações de forma inconsistente, o que pode resultar no download do artefato errado. Por exemplo, se os alvos delegarem para “A” e “B”, e “B” delegar para “C”, o cliente deveria rastrear as delegações na ordem “A”, depois “B” e depois “C”, mas pode rastrear incorretamente as delegações “B”->“C”->“A”. Esse problema está relacionado à função `GetRolesForTarget`, que retorna um mapa que causa esse comportamento. **Recomendações** Para versões do go-tuf anteriores à 2.0.1, atualize para a versão 2.0.1 para corrigir o problema de rastreamento inconsistente de delegação. Como solução alternativa temporária, considere revisar e verificar manualmente os caminhos de delegação para minimizar o risco de exploração.

**Nome do software vulnerável e versões afetadas** Versões do basic-auth-connect anteriores à 1.1.0 **Descrição** O problema diz respeito a uma comparação de igualdade com falha de segurança de temporização no basic-auth-connect, que pode vazar informações de temporização. Essa comparação pode, potencialmente, permitir que um invasor observe diferenças nos tempos de resposta, o que pode levar a problemas de segurança. O problema foi corrigido na versão 1.1.0 do basic-auth-connect. **Recomendações** Para versões anteriores à 1.1.0, atualize para o basic-auth-connect 1.1.0 para corrigir o vazamento de informações de tempo no middleware Basic Auth. Como solução temporária, considere restringir o acesso à funcionalidade Basic Auth até que a atualização possa ser aplicada.

**Nome do software vulnerável e versões afetadas** Versões do serve-static anteriores à 1.16.0 **Descrição** A vulnerabilidade permite a execução de código não confiável ao passar entradas de usuário não confiáveis para a função `redirect()`, mesmo após a sanitização. Isso pode ser explorado se um invasor controlar a entrada para `response.redirect()`, o Express não redirecionar antes que o modelo seja exibido e o navegador não concluir o redirecionamento antes que o usuário clique no link no modelo. **Recomendações** Para versões anteriores à 1.16.0, atualize para o serve-static 1.16.0 para corrigir o problema. Como solução alternativa temporária, certifique-se de que quaisquer entradas não confiáveis sejam seguras, validando-as em relação a uma lista de permissões explícita.

**Nome do software vulnerável e versões afetadas** Versões do Express.js anteriores à 4.20.0 **Descrição** O problema diz respeito à execução de código não confiável ao passar entradas de usuário não confiáveis para a função `response.redirect()` no Express.js, mesmo após a sanitização da entrada. Isso pode ocorrer quando um invasor controla a entrada para `response.redirect()`, o Express.js não redireciona antes que o modelo seja exibido e o navegador não conclui o redirecionamento antes que o usuário clique no link no modelo. **Recomendações** Para versões do Express.js anteriores à 4.20.0, atualize para a versão 4.20.0 para corrigir o problema. Como solução temporária, certifique-se de que quaisquer entradas não confiáveis sejam seguras, validando-as contra uma lista de permissões explícita antes de passá-las para a função `response.redirect()`.

**Nome do software vulnerável e versões afetadas** Versões do Send anteriores à 0.19.0 **Descrição** O problema decorre da passagem de entradas de usuário não confiáveis para `SendStream.redirect()`, o que pode levar à execução de código não confiável. Isso ocorre mesmo quando a entrada é sanitizada. A biblioteca Send é usada para transmitir arquivos do sistema de arquivos como uma resposta HTTP. **Recomendações** Para versões anteriores à 0.19.0, atualize para a versão 0.19.0 para corrigir o problema. Como solução alternativa temporária, certifique-se de que quaisquer entradas não confiáveis sejam seguras, validando-as em relação a uma lista de permissões explícita.

Nome do software vulnerável e versões afetadas: Versões do sigstore-go anteriores à 0.6.1 Descrição: O problema está relacionado a um ataque de negação de serviço que pode ocorrer quando um verificador recebe um pacote Sigstore criado de forma maliciosa contendo grandes quantidades de dados verificáveis. Esses dados podem estar na forma de entradas assinadas no registro de transparência, carimbos de data/hora RFC 3161 e assuntos de atestado. A verificação dessas estruturas de dados é computacionalmente onerosa e pode ser usada para consumir recursos excessivos da CPU, levando a um ataque de negação de serviço. Esse tipo de vulnerabilidade é classificado como um “ataque de dados infinitos” pelo modelo de segurança da TUF e pode levar à falha na conclusão da verificação e à interrupção de serviços que dependem do sigstore-go para verificação. Recomendações: Para versões anteriores à 0.6.1, atualize para o sigstore-go 0.6.1 ou posterior para corrigir a vulnerabilidade. Como solução temporária para usuários que estão vulneráveis, mas não podem atualizar rapidamente, considere adicionar uma validação manual de pacotes para impor limites semelhantes aos do patch mencionado antes de chamar as funções de verificação do sigstore-go.

**Nome do software vulnerável e versões afetadas** Versões do Minder anteriores à v0.0.52 **Descrição** O provedor Git do Minder está vulnerável a um ataque de negação de serviço (DoS) proveniente de um repositório GitHub configurado de forma maliciosa. O provedor Git clona os repositórios dos usuários utilizando a biblioteca `github.com/go-git/go-git/v5`. O método `(g *Git) Clone()` está vulnerável a um ataque DoS: um usuário do Minder pode instruir o Minder a clonar um repositório de grande porte, o que esgotará a memória e causará a falha do servidor do Minder. A causa principal dessa vulnerabilidade é uma combinação das seguintes condições: 1. Os usuários podem controlar a URL do Git que o Minder clona. 2. O Minder não impõe um limite de tamanho ao repositório. 3. O Minder clona o repositório inteiro na memória. **Recomendações** Para resolver o problema, atualize para a versão v0.0.52 ou posterior. Como solução alternativa temporária, considere restringir o tamanho dos repositórios que podem ser clonados pelo Minder para evitar o esgotamento da memória. Evite usar a biblioteca `github.com/go-git/go-git/v5` para clonar repositórios grandes até que o problema seja resolvido.

**Nome do software vulnerável e versões afetadas** Versões do Minder anteriores à 0.0.51 **Descrição** O Minder está vulnerável a um ataque de negação de serviço (DoS), o que poderia permitir que um invasor causasse uma falha no servidor do Minder e impedisse o acesso de outros usuários a ele. A causa principal da vulnerabilidade é que o verificador sigstore do Minder lê uma resposta não confiável inteiramente na memória sem impor um limite ao corpo da resposta. Um invasor pode explorar isso fazendo com que o Minder envie uma solicitação a um endpoint controlado por ele, que retorna uma resposta com um corpo grande que causará a falha do servidor do Minder. Especificamente, o ponto de falha é onde o Minder analisa a resposta do endpoint de atestados do GitHub em `getAttestationReply`. Aqui, o Minder faz uma solicitação ao endpoint do GitHub “orgs/$owner/attestations/$checksumref” e, em seguida, analisa a resposta em `AttestationReply`. A maneira como o Minder analisa a resposta o torna suscetível a DoS se a resposta for grande o suficiente, essencialmente exigindo que a resposta seja maior do que a memória disponível na máquina. O conteúdo hospedado no endpoint de atestado do GitHub “orgs/$owner/attestations/$checksumref” é controlado por usuários, incluindo usuários não autenticados, de acordo com o modelo de ameaças do Minder. No entanto, um usuário precisaria configurar suas próprias definições do Minder para fazer com que o Minder enviasse uma solicitação para buscar os atestados. O usuário precisaria conhecer um pacote cujos atestados fossem configurados de forma a retornar uma resposta grande

**Nome do software vulnerável e versões afetadas** Versões do Minder anteriores à 0.0.50 **Descrição** O mecanismo do Minder é suscetível a um ataque de negação de serviço causado por esgotamento de memória, que pode ser desencadeado por modelos criados de forma maliciosa. O mecanismo do Minder utiliza modelos para gerar strings para diversos casos de uso, como URLs, mensagens para pull requests e descrições para avisos. Em alguns casos, o usuário pode controlar tanto o modelo quanto os parâmetros associados a ele e, em um subconjunto desses casos, o Minder carrega o modelo gerado inteiramente na memória. Quando o sistema de modelos do Minder atende a ambas as condições, um invasor é capaz de gerar modelos grandes o suficiente para que o Minder esgote a memória e trave. O problema está relacionado ao ingester REST, onde um invasor pode fazer com que o Minder gere um modelo grande invocando `endpoint.String()` com controle tanto sobre o endpoint quanto sobre o parâmetro `retp`. **Recomendações** Para versões anteriores à 0.0.50, atualize para a versão 0.0.50 para corrigir a vulnerabilidade. Como solução temporária, considere limitar o tamanho dos modelos gerados antes de carregá-los na memória para evitar o esgotamento da memória. Restrinja o acesso ao mecanismo de modelagem vulnerável para minimizar o risco de exploração. Evite usar modelos grandes nos endpoints de API afetados até que o problema seja resolvido.

**Nome do software vulnerável e versões afetadas** Versões do Minder anteriores à 0.0.49 **Descrição** O Minder é uma plataforma de segurança da cadeia de suprimentos de software. O ingester REST do Minder está vulnerável a um ataque de negação de serviço por meio de um endpoint REST controlado pelo invasor, o que pode causar a falha do servidor do Minder. Ao buscar dados com o ingester REST, o Minder envia uma solicitação a um endpoint e usa os dados do corpo da resposta como dados a serem avaliados em relação a uma determinada regra. Se a resposta for suficientemente grande, ela pode esgotar a memória da máquina e travar o servidor do Minder. O invasor pode controlar os endpoints REST remotos aos quais o Minder envia solicitações e pode configurá-los para retornar respostas com corpos de grande tamanho. **Recomendações** Para versões anteriores à 0.0.49, atualize para a versão 0.0.49 ou posterior para corrigir o problema. Como solução temporária, considere restringir o acesso ao ingestor REST para minimizar o risco de exploração. Evite usar o ingestor REST para buscar dados de endpoints REST não confiáveis ou controlados por invasores até que o problema seja resolvido.

**Nome do software vulnerável e versões afetadas** Versões do Minder anteriores à 0.0.48 **Descrição** O método `HandleGithubWebhook` do Minder está suscetível a um ataque de negação de serviço proveniente de uma solicitação HTTP não confiável. A vulnerabilidade existe antes que a solicitação seja validada e, portanto, a solicitação ainda não é confiável no momento da falha. Isso permite que um invasor com a capacidade de enviar solicitações para `HandleGithubWebhook` cause uma falha no plano de controle do Minder e impeça outros usuários de utilizá-lo. O problema surge porque a função `validatePayloadSignature` gera um leitor a partir da solicitação recebida, o que pode levar ao esgotamento da memória se o corpo da solicitação for grande. **Recomendações** Para versões anteriores à 0.0.48, atualize para a versão 0.0.48 para corrigir a vulnerabilidade. Como solução temporária, considere restringir o acesso ao endpoint `HandleGithubWebhook` para minimizar o risco de exploração. Evite usar a função `readerFromRequest` com solicitações não confiáveis até que o problema seja resolvido.