B-Hermes

**Nome do Software Vulnerável e Versões Afetadas** Budibase versões anteriores a 3.35.4 **Descrição** As funções `buildMatcherRegex()` e `matches()` em `packages/backend-core/src/middleware/matchers.ts` compilam padrões de rota em expressões regulares não ancoradas e as testam contra `ctx.request.url`, que inclui a string de consulta completa. O middleware CSRF utiliza este sistema para decidir se a validação do token CSRF deve ser ignorada. Um invasor não autenticado pode ignorar a validação do token CSRF para qualquer endpoint da API do Worker injetando um padrão de rota pública na string de consulta. Isso permite a execução de requisições cross-origin que alteram o estado, como a modificação da configuração global, gerenciamento de usuários e envio de convites de administrador. **Recomendações** Atualizar para a versão 3.35.4.

**Nome do Software Vulnerável e Versões Afetadas** Portainer Community Edition versões 2.33.0 a 2.33.7 Portainer Community Edition versões 2.39.0 a 2.39.1 Portainer Community Edition versões anteriores a 2.41.0 **Description** O Portainer suporta a implantação de stacks a partir de repositórios Git. Quando uma stack baseada em Git é criada ou atualizada, o software clona o repositório usando `go-git` v5, que traduz entradas de blob do Git com o modo `0o120000` (symlink) em links simbólicos reais do SO no sistema de arquivos do host via `os.Symlink`. Com exceção do `.gitmodules`, todos os outros caminhos são criados como symlinks sem validação. O endpoint `GET /api/stacks/{id}/file` lê o ponto de entrada da stack usando `os.ReadFile`, que segue symlinks do SO de forma transparente. Se um repositório contiver o `docker-compose.yml` como um symlink para um caminho arbitrário do sistema de arquivos, o conteúdo desse alvo é retornado na resposta HTTP. Qualquer usuário autenticado com permissões para criar ou atualizar uma stack baseada em Git pode ler arquivos arbitrários acessíveis ao processo do Portainer, que normalmente é executado como root. Isso pode levar à exposição do `/etc/shadow`, tokens de conta de serviço do Kubernetes, segredos do Docker e do banco de dados do Portainer. O problema pode ser explorado via auto-atualização de stack Git, onde um repositório legítimo é posteriormente atualizado com um symlink malicioso que é acionado durante o próximo ciclo de atualização agendado. **Recommendations** Atualize o Portainer Community Edition para a versão 2.33.8. Atualize o Portainer Community Edition para a versão 2.39.2. Atualize o Portainer Community Edition para a versão 2.41.0. Desative a configuração Allow non-admin users to manage their stacks nas configurações de ambiente para restringir a criação de stacks baseadas em Git apenas a administradores. Evite implantar stacks baseadas em Git de repositórios não confiáveis ou não revisados. Desative a auto-atualização em stacks existentes para evitar a exploração diferida. Audite os caminhos dos projetos em `/data/compose/` em busca de entradas de symlink inesperadas usando `find /data/compose -type l`.

**Nome do Software Vulnerável e Versões Afetadas** nuxt-og-image versões 6.2.5 até 6.4.8 @nuxtjs/og-image versões 6.2.5 até 6.4.8 **Descrição** Existe um problema na função `isBlockedUrl()` onde a lista de bloqueio (denylist) usada para prevenir Server-Side Request Forgery (SSRF) está incompleta. Isso permite que atacantes ignorem as verificações de segurança de duas maneiras. Primeiro, a lista de prefixos IPv6 é insuficiente, falhando ao bloquear vários intervalos, incluindo endereços de loopback IPv4 mapeados para IPv6 (ex: `[::ffff:7f00:1]`), endereços site-local (`[fec0::/10]`), SIDs SRv6 (`[5f00::/16]`), documentação IPv6 v2 (`[3fff::/20]`) e endereços de uso local NAT64 (`[64:ff9b:1::/48]`). Segundo, o software carece de re-validação de redirecionamento; a verificação `isBlockedUrl()` é realizada apenas na requisição inicial, mas a operação `$fetch()` subsequente segue redirecionamentos HTTP 3xx sem validar o destino. Isso permite que um atacante utilize uma origem permitida que redirecione para um endereço IP interno para completar um ataque de SSRF. A vulnerabilidade é acionada quando URLs influenciadas pelo usuário são usadas em componentes de imagem OG em builds de produção. **Recomendações** Atualize o nuxt-og-image e o @nuxtjs/og-image para a versão 6.4.9. Como medida paliativa temporária, restrinja a entrada influenciada pelo usuário em componentes de imagem OG para evitar o uso de URLs arbitrárias.

**Nome do Software Vulnerável e Versões Afetadas** Twenty versões anteriores a 1.18.1 **Descrição** Um problema no `SecureHttpClientService` do twenty-server permite a evasão das proteções contra Server-Side Request Forgery (SSRF). Isso ocorre porque o analisador de URL do Node.js normaliza endereços IPv6 mapeados para IPv4 em uma forma hexadecimal compactada, enquanto o utilitário `isPrivateIp` reconhece apenas a notação decimal pontuada. Consequentemente, a forma hexadecimal passa pela verificação de SSRF sem ser detectada. Além disso, o evento de validação de busca de socket não é acionado para endereços literais de IP, ignorando a segunda camada de validação. Um usuário autenticado pode explorar isso para acessar IPs internos, incluindo endpoints de metadados de nuvem, para exfiltrar credenciais, como chaves IAM. **Recomendações** Atualize para uma versão posterior a 1.18.0.

**Name of the Vulnerable Software and Affected Versions** Wallos versions prior to 4.7.0 **Description** Wallos is a self-hostable, open-source personal subscription tracker. An authenticated user can potentially access internal network services, cloud metadata endpoints like AWS IMDSv1, GCP, and Azure IMDS, or services bound to localhost. This is possible by providing a manipulated URL to the AI Ollama host parameter, the AI recommendations endpoint, or the notification cron job. The patch introduced in commit e8a513591 added Server-Side Request Forgery (SSRF) protection to notification test endpoints but did not cover these additional attack surfaces. **Recommendations** Update to version 4.7.0 or later.