Cedric Bonhomme

Um problema de cross-site scripting (XSS) armazenado existe no filtro Jinja `render tag badges` usado para exibir tags de referência de registros de vulnerabilidades. A aplicação interpola diretamente valores de `containers.cna.references[].tags[]` em elementos de badge HTML e envolve o resultado em `markupsafe.Markup`, o que ignora a a escape automática de HTML do Jinja. Um usuário autenticado com permissões `vulnerability:create` ou `vulnerability:modify` pode enviar tags de referência manipuladas via API CNA contendo HTML ou JavaScript arbitrário. Este conteúdo malicioso é armazenado e posteriormente executado no navegador de qualquer usuário que visite os endpoints públicos `/cve/<id>` ou `/vuln/<id>`. Isso pode permitir que um invasor realize ações em nome da vítima, acesse informações de sessão ou modifique o conteúdo da página, afetando potencialmente usuários não autenticados.

Existe uma falha de bypass de autorização devido à aplicação inconsistente de regras entre a API REST e a interface de streaming Server-Sent Events (SSE). A interface Pub/Sub utiliza um decorador `token required` que autentica requisições comparando o cabeçalho `X-API-KEY` com a chave de API do usuário, mas não verifica se a conta está ativa ou confirmada. Como as chaves de API são emitidas durante o auto-registro antes da conclusão da confirmação, usuários não autorizados podem acessar o endpoint `/pubsub/subscribe/<topic>`. Isso permite o acesso a eventos de stream, como comentários não moderados, que estariam restritos através da API REST.

Existe uma fraqueza de autenticação no mecanismo de ativação de conta e recuperação de senha. O sistema utiliza tokens assinados sem estado que contêm apenas o login do usuário. Embora a assinatura e a idade sejam validadas, a aplicação não rastreia se um token já foi utilizado. Consequentemente, um link de ativação ou recuperação capturado permanece válido durante todo o `TOKEN VALIDITY PERIOD`, mesmo após a alteração da senha. Isso permite que um invasor com um token válido o utilize repetidamente para redefinir a senha e assumir o controle da conta. Além disso, os tokens não são vinculados a um propósito específico, permitindo que o mesmo token seja usado nos fluxos de ativação e recuperação. A exploração requer a obtenção de um link válido, mas não exige a senha atual da vítima ou uma sessão ativa.

Um problema de server-side request forgery (SSRF) existe na funcionalidade de sincronização de instâncias remotas. O sistema validava os endereços de instâncias remotas apenas quanto à sintaxe básica de URL antes do armazenamento, enquanto o worker de sincronização posteriormente processava esses endereços usando `requests.get()` com manipulação automática de redirecionamento e sem restrições de limite de rede. Um administrador autenticado com a permissão `admin:access` poderia configurar uma instância remota apontando para serviços HTTP(S) internos, de loopback, link-local ou de metadados de nuvem. Além disso, uma URL publicamente acessível poderia ser usada para redirecionar para um destino interno, pois os redirecionamentos eram seguidos sem revalidação. Isso permite que um invasor privilegiado explore ou interaja com serviços acessíveis a partir do contexto de rede do servidor, como serviços de rede privada ou endpoints de metadados de instâncias em nuvem.

O validador de URL de webhook em `website/notifications/webhooks.py` utiliza `ip.is global` para rejeitar endereços não públicos após a resolução de DNS. No entanto, endereços de transição IPv6, como NAT64 `64:ff9b::/96`, 6to4 `2002::/16` e Teredo `2001:0000::/32`, são classificados como roteáveis globalmente pela IANA. Consequentemente, `is global` retorna `True` mesmo quando o IPv4 incorporado visa um destino privado, de loopback ou de metadados de nuvem. Isso permite que um invasor registre um webhook apontando para um nome de host que resolve para um endereço de transição, ignorando a proteção contra Server-Side Request Forgery (SSRF) para exfiltrar dados para um endpoint interno.