CVE-2025-67906

---

Visão Geral da Vulnerabilidade

CVE-2025-67906 (GCVE-1-2025-0031) é uma vulnerabilidade de Cross-Site Scripting Armazenado (XSS) no MISP (Plataforma de Compartilhamento de Informações sobre Malware) nas versões até 2.5.27 inclusive.

A vulnerabilidade reside em app/View/Elements/Workflows/executionPath.ctp, no componente Workflow execution path view (visão do caminho de execução do workflow). O campo name dos triggers de workflow é persistido no banco de dados sem sanitização no servidor e posteriormente renderizado no DOM por meio do mecanismo de templates doT.js sem escape de HTML. Um atacante autenticado pode injetar HTML/JavaScript arbitrário que é executado na sessão do navegador de qualquer usuário que visualize o workflow comprometido.

Como o payload é armazenado no banco de dados e renderizado a cada carregamento de página, o XSS é persistente — ele sobrevive a atualizações da página, afeta vários usuários e permanece até que o workflow seja explicitamente excluído.

Descoberta: Esta vulnerabilidade foi identificada e divulgada de forma responsável por Franck FERMAN.

---

Pontuações CVSS

Existem múltiplas avaliações CVSS para esta vulnerabilidade:

Origem	Pontuação	Severidade	Vetor
NIST NVD	9.0	Crítica	CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H
GCVE (CIRCL)	7.1	Alta	CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:A/VC:H/VI:N/VA:N/SC:H/SI:H/SA:H
CNA (MITRE)	5.4	Média	CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N

A divergência nas pontuações reflete diferentes avaliações da profundidade do impacto. A pontuação do NIST NVD (9.0) considera impacto total em Confidencialidade, Integridade e Disponibilidade, dado que o payload de XSS executa com os privilégios da sessão da vítima, permitindo exfiltração de dados em nível de administrador e manipulação de workflows. A pontuação do CNA (5.4) considera apenas impacto limitado de C/I para um XSS genérico. A pontuação GCVE CVSS 4.0 (7.1) introduz os modificadores Requisitos de Ataque (Privilégio) e Interação Ativa do Usuário.

O Escopo é Alterado em todas as avaliações porque o payload do atacante (injetado via API do MISP) executa em um contexto de segurança diferente (a sessão do navegador da vítima).

---

Análise da Causa Raiz

O Vetor de Injeção

O Workflow Engine do MISP permite que usuários autenticados criem e editem workflows por meio da API REST. O modelo de dados do workflow inclui um componente trigger com um campo name. Este campo:

1. É aceito pela API sem validação de entrada ou codificação de entidades HTML
2. É persistido no banco de dados como texto bruto (sem sanitização no servidor)
3. É renderizado no navegador por meio do mecanismo de templates JavaScript doT.js

Por que o doT.js é Vulnerável Aqui

O doT.js é um mecanismo de templates JavaScript rápido. Ele usa {{= }} para interpolação, que não faz escape de HTML por padrão. O Editor de Workflow do MISP usa doT.js para renderizar os metadados do trigger (incluindo o campo name) no DOM. Quando o campo name contém HTML como ``, o mecanismo de template o insere como HTML bruto, e o navegador executa o JavaScript incorporado.

A correção requer uma das seguintes opções:

• Migrar para a sintaxe de saída codificada do doT.js {{! }}, que faz escape HTML do valor
• Sanitização no servidor antes da inserção no banco de dados
• Ambas (defesa em profundidade)

Ponto de Injeção

POST /workflows/edit/{id}

{
  "Workflow": {
    "id": "1",
    "data": "{\"1\":{\"data\":{\"name\":\"\"}}}"
  }
}

O valor name dentro do campo JSON data é o ponto de injeção. Todo o grafo do workflow é serializado como uma string JSON no corpo da requisição.

O Contexto de Renderização: Mecanismo Gráfico no Lado do Cliente

A vulnerabilidade é amplificada pela escolha arquitetural de usar um mecanismo de templates no lado do cliente (doT.js) para renderizar o editor visual de workflows. O Editor de Workflow é uma interface gráfica de arrastar e soltar em que cada trigger/ação é exibido como um bloco visual. O campo name do trigger é renderizado como um rótulo dentro desses blocos gráficos.

O doT.js constrói os componentes visuais gerando strings HTML a partir de templates e inserindo-as no DOM. A sintaxe de interpolação {{= }} produz saída sem escape — qualquer dado interpolado no template é tratado como marcação (markup), não como texto. Se o mesmo campo name fosse renderizado via element.textContent (que trata a entrada como texto simples) ou por meio da sintaxe de saída codificada {{! }} do próprio doT.js, nenhum XSS seria possível independentemente do conteúdo da entrada.

A superfície de ataque existe precisamente porque:

1. Um editor gráfico exige renderização HTML rica (blocos estilizados, ícones, layouts)
2. O mecanismo de template escolhido (doT.js) usa por padrão saída sem escape ({{= }}) em nome do desempenho
3. Metadados fornecidos pelo usuário (nomes de triggers) chegam a esses templates sem sanitização
4. Como resultado, qualquer string armazenada no campo name é interpretada como HTML pelo navegador

Este é um padrão comum de vulnerabilidade em aplicações web que usam mecanismos de templates no lado do cliente para construir interfaces visuais interativas: a necessidade de renderização rica cria uma relação de confiança implícita entre o template e suas fontes de dados, e qualquer entrada de usuário não sanitizada que atinja o template torna-se código executável.

Por que `` e não <script>

Uma tag <script> bruta injetada via interpolação de template normalmente não será executada nesse contexto. Os navegadores não executam elementos <script> inseridos no DOM após o parsing inicial da página (via innerHTML ou equivalente). Atributos manipuladores de eventos como onerror, onload ou onmouseover em elementos HTML contornam essa restrição porque disparam JavaScript inline quando o navegador processa os atributos do elemento, independentemente de como o elemento foi inserido.

O vetor <img src="https://raw.githubusercontent.com/franckferman/cve-2025-67906/HEAD/x" onerror="..."> é o preferido porque:

• O src="x" garante falha imediata no carregamento, acionando onerror sem interação do usuário
• Funciona em todos os navegadores e não exige que o elemento esteja visível
• Ele contorna as restrições de CSP script-src que bloqueiam tags <script> inline, pois a execução ocorre via um manipulador de eventos em um elemento que não é script

Bypass de CSP via Navegação (Exfiltração)