Ni8mare & CVE-2026-21858

01Sumário executivo

Este relatório perfila a vulnerabilidade crítica identificada como CVE-2026-21858 e batizada de "Ni8mare" pela equipe da Cyera Research Labs [1]. Trata-se de uma falha de confusão de tipo de conteúdo (Content-Type Confusion) que afeta todas as versões do n8n anteriores à 1.121.0, permitindo execução remota de código (RCE, Remote Code Execution) sem autenticação prévia [1] [2] [3].

O n8n consolidou-se como um dos ecossistemas de automação de fluxo de trabalho e agentes de inteligência artificial mais adotados no mundo, acumulando mais de 100 milhões de downloads via Docker e presença maciça em ambientes corporativos [1]. Em implantações corporativas, formulários de entrada (Form Webhook nodes) são frequentemente publicados para receber dados de clientes, currículos de candidatos ou anexos de chamados técnicos [4].

A raiz da vulnerabilidade reside na divergência de tratamento de requisições HTTP pelo middleware de entrada: enquanto o nó de webhook de chat (ChatTrigger) conferia se o cabeçalho Content-Type era multipart/form-data antes de processar uploads, o manipulador de formulários (formWebhook) dispensava essa verificação [1]. Um atacante pode enviar uma requisição contendo Content-Type: application/json e injetar um objeto forjado files com o caminho de qualquer arquivo interno do sistema. Esse arquivo é copiado para a esteira de dados do n8n.

A escalada de privilégios ocorre de forma direta: o invasor lê o banco de dados local SQLite (onde constam os usuários e os hashes de senha) e o arquivo de configuração de instância (onde reside a chave de criptografia de segredos) [1]. Com esses dois artefatos, o atacante calcula e assina um cookie administrativo legítimo, autentica-se na interface gráfica e instancia nós de execução de comando do sistema (Execute Command), alcançando RCE irrestrito com os privilégios do processo [1] [2].

02Identificação do objeto analisado

03Arquitetura do n8n e manipulação de webhooks

O n8n adota uma arquitetura orientada a eventos na qual os fluxos de trabalho são instanciados a partir de nós de gatilho (Trigger Nodes) ou de Webhooks [1]. Ao invés de consultar repetidamente serviços externos em busca de alterações, o n8n expõe terminais HTTP públicos que aguardam eventos de entrada enviados por sistemas terceiros, como plataformas de pagamento, mensageria ou formulários web [1].

Quando uma requisição HTTP atinge um terminal de webhook no n8n, ela ingressa em um fluxo compartilhado de pré-processamento. Esse fluxo executa uma função de middleware designada parseRequestBody() [1]. O objetivo dessa função é inspecionar o corpo da mensagem HTTP e prepará-lo para que o nó de destino possa operar sobre dados limpos e estruturados [1].

A lógica do middleware parseRequestBody() ramifica o fluxo em dois caminhos totalmente distintos com base no valor do cabeçalho Content-Type da requisição [1]:

// parseRequestBody() examina o cabeçalho Content-Type
if (req.headers['content-type']?.includes('multipart/form-data')) {
    // Encaminha para o analisador de upload de arquivos (Formidable)
    await parseFormData(req);
} else {
    // Encaminha para o analisador de corpo genérico (JSON, URL-encoded, texto)
    await parseBody(req);
}

No primeiro caminho, reservado para requisições do tipo multipart/form-data, o n8n utiliza uma função wrapper em torno da biblioteca Formidable [1]. A biblioteca Formidable foi concebida para lidar com uploads de arquivos em Node.js e incorpora controles de segurança rigorosos contra ataques de travessia de diretório (Path Traversal): ao receber arquivos binários, ela os grava automaticamente com identificadores alfanuméricos aleatórios dentro de uma pasta temporária (por exemplo, /tmp/upload_1a2b3c) [1]. Os metadados resultantes são alocados no objeto req.body.files [1].

No segundo caminho, voltado para qualquer outro tipo MIME (como application/json ou application/x-www-form-urlencoded), o middleware invoca parseBody() [1]. Essa função decodifica o payload recebido e atribui o resultado integral diretamente à variável global do objeto de requisição, ou seja, req.body [1].

04A falha: confusão de Content-Type e injeção de propriedades

A premissa fundamental de segurança do n8n para manipulação de arquivos estipulava que todas as rotas que leem arquivos deveriam confiar no conteúdo de req.body.files, uma vez que este deveria ser originado exclusivamente do motor Formidable [1]. Para garantir essa premissa, os nós que manipulam arquivos deveriam verificar explicitamente se a requisição tratada continha o tipo de conteúdo apropriado [1].

4.1A quebra de validação no nó Form Webhook

Em nós como o ChatTrigger, a equipe de engenharia do n8n implementou a validação de cabeçalho de maneira estrita: a função handleFormData() somente era executada após confirmar que o cabeçalho Content-Type continha o valor multipart/form-data [1]. Caso contrário, a requisição era rejeitada com erro, impedindo o processamento de anexos falsificados [1].

No entanto, no nó de formulário (formWebhook), essa verificação foi esquecida [1]. A função de atendimento ao envio do formulário invocava diretamente a sub-rotina prepareFormReturnItem() sem conferir previamente o cabeçalho Content-Type [1]. Essa omissão pontual abriu espaço para o ataque de confusão de tipo de conteúdo (Content-Type Confusion) [1] [6].

4.2Injeção de propriedades arbitrárias em req.body.files

Ao submeter uma requisição HTTP ao terminal de formulário contendo Content-Type: application/json em substituição ao padrão multipart/form-data, o atacante engana o middleware parseRequestBody() [1]. Em vez de acionar a biblioteca Formidable, o n8n executa parseBody(), aceitando o payload JSON estruturado pelo invasor [1].

O invasor pode enviar uma estrutura JSON especificando manualmente a chave files, configurando campos internos que a aplicação esperaria receber da biblioteca de upload [1]:

POST /form/c1a2b3d4-0000-1111-2222-333344445555 HTTP/1.1
Host: n8n.empresa.com.br
Content-Type: application/json

{
  "files": {
    "arquivo": {
      "filepath": "/etc/passwd",
      "originalFilename": "passwd.txt",
      "mimetype": "text/plain"
    }
  }
}

4.3Leitura arbitrária de arquivos via copyBinaryFile

Ao receber o objeto injetado, a função prepareFormReturnItem() percorre as entradas de req.body.files e despacha cada registro para a função copyBinaryFile() [1]. Em condições normais, copyBinaryFile() recebe o caminho de um arquivo temporário gravado pelo Formidable e o copia para o armazenamento persistente do fluxo de trabalho, que pode ser o disco local ou um bucket no Amazon S3 [1].

Como o atacante possui o controle irrestrito da propriedade filepath, ele substitui o arquivo temporário aleatório por qualquer caminho absoluto existente no sistema de arquivos do servidor n8n [1]. O sistema operacional lê o arquivo requisitado (como /etc/passwd, arquivos de banco de dados ou configurações) e grava sua cópia no armazenamento interno do fluxo de trabalho [1].

Qualquer nó posicionado na sequência do formulário passa a receber o conteúdo desse arquivo interno como se fosse um documento anexado legitimamente por um usuário [1].

05Cadeia de exploração e escalonamento para RCE

A simples leitura de arquivos locais (LFI, Local File Inclusion) já constituiria uma falha de severidade alta. Todavia, na arquitetura do n8n, a falha escala de maneira determinística para execução remota de código (RCE) sem qualquer necessidade de credenciais de login ou privilégios preexistentes [1].

5.1Vazamento de dados via fluxos de trabalho e RAG

Em um caso de uso amplamente difundido no mercado corporativo, o n8n é utilizado para alimentar bases de conhecimento organizacionais integradas a motores de RAG (Retrieval-Augmented Generation) e modelos de linguagem [1]. Nesses fluxos, funcionários utilizam o nó de formulário para enviar manuais, relatórios e políticas, que são convertidos em vetores e indexados [1].

Ao injetar /etc/passwd ou qualquer arquivo confidencial no nó de formulário, o fluxo subsequente divide e indexa o arquivo no repositório de dados [1]. Logo em seguida, o atacante acessa a interface de bate-papo pública conectada à base de conhecimento e solicita o conteúdo indexado, obtendo a leitura completa do arquivo do sistema de maneira automatizada [1]. Mesmo em fluxos sem RAG, se os nós posteriores enviarem o anexo por correio eletrônico, salvarem-no em armazenamento público ou o devolverem em resposta HTTP, o arquivo é recuperado com a mesma facilidade [1].

5.2Sequestro de banco de dados e chave mestra

Para obter acesso à camada administrativa da aplicação, o invasor visa dois artefatos específicos do n8n que residem obrigatoriamente no sistema de arquivos local das instâncias instaladas via Docker ou pacotes padrão [1]:

1. Banco de dados SQLite (/home/node/.n8n/database.sqlite): contém a tabela user com o identificador único do administrador, seu endereço de e-mail e o hash criptográfico da senha de acesso [1].
2. Arquivo de configuração de instância (/home/node/.n8n/config): armazena parâmetros essenciais de inicialização, incluindo o valor do segredo encryptionKey, que é gerado na primeira inicialização da instância para cifrar credenciais salvas e assinar sessões [1].

O atacante executa a primitiva de leitura arbitrária de arquivos duas vezes consecutivas: na primeira requisição, aponta filepath para o banco de dados e extrai os dados do administrador; na segunda requisição, aponta para o arquivo de configuração e recupera a chave encryptionKey [1].

5.3Forja de sessão administrativa e execução de comandos

A autenticação da interface web do n8n é gerenciada por um cookie de sessão chamado n8n-auth [1]. Ao autenticar um usuário, a plataforma gera um dicionário contendo o identificador do usuário e os primeiros 10 caracteres de um hash SHA256 calculado a partir da concatenação do e-mail e do hash da senha [1]. Esse dicionário é então assinado utilizando a chave mestra encryptionKey [1].

De posse do e-mail, do hash da senha e da chave mestra obtidos na etapa anterior, o atacante executa o algoritmo de forja de sessão offline [1]:

// 1. Concatena e calcula o hash SHA256
const authString = email + userPasswordHash;
const userHash = crypto.createHash('sha256').update(authString).digest('hex').substring(0, 10);

// 2. Estrutura o payload de sessão administrativa
const sessionPayload = {
    id: adminUserId,
    hash: userHash
};

// 3. Assina o payload utilizando a chave de criptografia de instância
const forgedAuthCookie = jwt.sign(sessionPayload, encryptionKey);

O atacante injeta o cookie n8n-auth forjado em seu navegador e atualiza a página do n8n, sendo imediatamente reconhecido pelo sistema como o administrador geral da instância, sem que nenhum alerta de credencial incorreta seja emitido [1].

Na condição de administrador, o invasor desfruta de controle total sobre a plataforma. Para materializar a execução remota de código, basta criar um novo fluxo de trabalho e incluir o nó nativo denominado Execute Command (n8n-nodes-base.executeCommand) [1]. Esse nó permite a execução direta de instruções no shell do sistema operacional com os privilégios do usuário sob o qual o contêiner ou serviço está rodando (geralmente o usuário node ou root), consumando o RCE total [1] [2].

06Superfície de ataque e raio de explosão organizacional

O n8n raramente atua como um sistema isolado. Em organizações modernas, a ferramenta funciona como o conector central entre dezenas de ferramentas heterogêneas, orquestrando fluxos entre provedores de computação em nuvem (AWS, Microsoft Azure, Google Cloud), bancos de dados corporativos (PostgreSQL, MySQL, MongoDB), ferramentas de produtividade e comunicação (Slack, Microsoft 365, Google Workspace) e gateways de pagamento [1].

Essa posição privilegiada faz com que o raio de explosão de um comprometimento do n8n seja devastador [1]. Ao obter controle administrativo da instância e posse da chave encryptionKey, o atacante ganha capacidade de decifrar todas as credenciais guardadas no repositório de credenciais da plataforma [1]. Senhas de bancos internos, chaves mestras de API de inteligência artificial (OpenAI, Anthropic) e tokens de acesso OAuth com amplos privilégios tornam-se imediatamente acessíveis ao invasor em texto claro [1].

Varreduras públicas em motores de busca de infraestrutura, como Shodan e Censys, revelam mais de 100.000 instâncias do n8n diretamente acessíveis via internet através da porta padrão 5678 ou de proxies reversos [1]. Em muitas dessas instâncias, formulários e webhooks são disponibilizados para clientes e parceiros externos sem autenticação, expondo o vetor de ataque em escala global [1].

07Detecção

A identificação de tentativas de exploração da vulnerabilidade Ni8mare deve cobrir camadas complementares de telemetria, abrangendo borda, proxy reverso, logs do n8n e auditoria de processos no sistema operacional [1] [2].

7.1Telemetria de borda e proxies reversos

Como a falha reside na confusão entre o manipulador de formulários e o corpo da mensagem, a anomalia é altamente visível na camada HTTP [1]. Requisições legítimas a nós de formulário do n8n utilizam invariavelmente multipart/form-data. Portanto, qualquer requisição enviada a endpoints com os prefixos /form/* ou /webhook/* cujo cabeçalho Content-Type seja application/json (ou equivalente) e contenha campos indicando files ou filepath representa uma anomalia severa [1].

A regra Sigma abaixo documenta a lógica de caça para sistemas SIEM (Security Information and Event Management) e logs de proxy web [1] [2]:

title: Tentativa de Exploracao CVE-2026-21858 Ni8mare no n8n
id: a8f4b01e-72c1-4b52-9c1a-n8n202621858
status: experimental
description: Detecta requisicoes HTTP POST direcionadas a formularios ou webhooks do n8n com Content-Type JSON contendo chaves de injecao de arquivos.
references:
    - https://www.cyera.com/pt-br/research/ni8mare-unauthenticated-remote-code-execution-in-n8n-cve-2026-21858
    - https://github.com/n8n-io/n8n/security/advisories/GHSA-v4pr-fm98-w9pg
author: Lucas Rayan Guerra (CiberLab)
date: 2026/09/21
logsource:
    category: webserver
detection:
    selection_path:
        cs-method: 'POST'
        cs-uri-stem|contains:
            - '/form/'
            - '/webhook/'
            - '/webhook-test/'
    selection_header:
        cs-content-type|contains: 'application/json'
    selection_body:
        cs-body|contains|all:
            - 'files'
            - 'filepath'
    condition: selection_path and selection_header and selection_body
falsepositives:
    - Webhooks customizados que recebam intencionalmente payloads JSON contendo as palavras files e filepath (avaliar contexto do payload)
level: critical
tags:
    - attack.initial_access
    - attack.t1190

7.2Assinatura de rede (Suricata)

Para sensores NIDS (Network Intrusion Detection System), a inspeção de pacotes na porta padrão do n8n (TCP 5678) ou na saída de balanceadores TLS permite interceptar a tentativa de injeção de arquivos do sistema antes que o fluxo seja concluído [1] [2]:

alert http any any -> any $HTTP_PORTS (msg:"CIBERLAB EXPLOIT n8n Ni8mare Content-Type Confusion Arbitrary File Read (CVE-2026-21858)"; flow:established,to_server; http.method; content:"POST"; http.uri; pcre:"/(form|webhook(-test)?)\/[a-zA-Z0-9_-]+/"; http.header; content:"Content-Type: application/json"; nocase; http.request_body; content:"files"; nocase; content:"filepath"; distance:0; nocase; classtype:attempted-admin; sid:10000858; rev:1; metadata:cve CVE-2026-21858, author Lucas_Rayan_Guerra;)

7.3Auditoria de integridade e pós-exploração

Caso haja suspeita de que uma instância esteve exposta sem patch, a equipe de resposta a incidentes deve conduzir buscas forenses diretamente na base do n8n e no histórico de execuções [1]:

• Execuções de fluxo suspeitas: examinar a tabela execution_entity no banco de dados para auditar execuções acionadas a partir de nós formWebhook que tenham manipulado arquivos com caminhos do sistema [1].
• Criação de novos fluxos de trabalho: auditar na tabela workflow_entity a criação recente de fluxos de trabalho contendo o nó n8n-nodes-base.executeCommand ou nós de código genérico (Code node) que importem bibliotecas como child_process [1].
• Novos usuários administradores: verificar se novos usuários com permissão de administração foram cadastrados ou se o endereço de e-mail do administrador principal foi alterado [1].

08Mitigação e resposta a incidentes

A resposta ao CVE-2026-21858 deve obedecer estritamente às quatro fases do ciclo de incidentes, pois simplesmente aplicar a atualização não anula os efeitos de credenciais já roubadas ou cookies já forjados por atacantes [1] [2].

8.1Contenção imediata

Se a instância estiver rodando versão vulnerável (inferior a 1.121.0) e exposta à rede pública, execute as seguintes ações de contenção [1] [2]:

1. Isole a porta de serviço na borda: bloqueie imediatamente o acesso público direto à porta TCP 5678 nos firewalls e grupos de segurança de nuvem [1]. O acesso à interface de administração do n8n deve ser restrito exclusivamente a redes corporativas internas ou canais protegidos por VPN (Virtual Private Network) e Zero Trust [1].
2. Desative temporariamente formulários públicos não autenticados: caso formulários precisem permanecer expostos externamente para coleta de informações de terceiros, ative a opção obrigatória de autenticação no nó de formulário (Require Authentication) ou despublique o fluxo até a aplicação do patch [1].

8.2Erradicação e atualização

A equipe do n8n corrigiu a vulnerabilidade a partir da versão 1.121.0 [1] [2]. Não existem mitigações ou soluções de contorno oficiais (workarounds) fornecidas pelo fabricante capazes de proteger integralmente a plataforma sem a atualização do software [1].

Atualize a imagem do contêiner Docker para a versão mais recente da branch de lançamento ou execute o upgrade através do gerenciador de pacotes corporativo [1] [2]. Verifique na interface gráfica ou via terminal executando n8n --version se o número da versão em execução é igual ou superior a 1.121.0 [1].

8.3Avaliação de alcance e rotação mandante de credenciais

Se a sua organização manteve uma instância do n8n desatualizada exposta à internet, adote o princípio de presunção de comprometimento (Assume Breach) [1]. O atacante pode ter extraído o banco de dados e as chaves de criptografia sem deixar registros óbvios de indisponibilidade [1].

Execute as seguintes ações de renovação de credenciais com caráter de urgência [1]:

1. Gire a chave mestra de instância: substitua a chave encryptionKey no arquivo de configuração do n8n e recriptografe os segredos da base para invalidar permanentemente qualquer cookie de sessão n8n-auth anteriormente forjado por atacantes [1].
2. Gire todas as credenciais de terceiros armazenadas: renove todas as senhas de bancos de dados, chaves de API de provedores de IA (OpenAI, Anthropic, Cohere), chaves de acesso AWS/GCP, segredos de clientes OAuth (Google, Microsoft, Slack, GitHub) e tokens de serviços corporativos cadastrados na instância [1].
3. Redefina as senhas dos administradores: force a redefinição de senhas para todos os usuários cadastrados na instância, aplicando políticas fortes de complexidade e autenticação de dois fatores (MFA, Multi-Factor Authentication) [1].

8.4Prevenção estrutural e mapeamento MITRE ATT&CK

Para reduzir a superfície de risco de execuções arbitrárias no futuro, restrinja o carregamento de nós com poderes de execução no sistema operacional [1]. Isso pode ser configurado definindo a variável de ambiente NODES_EXCLUDE='["n8n-nodes-base.executeCommand"]' nos arquivos de implantação Docker Compose ou Kubernetes, impedindo que administradores criem rotinas de execução no host [1].

09Indicadores de comprometimento

A tabela a seguir consolida os indicadores técnicos, caminhos de arquivo padrão e padrões observados na exploração da vulnerabilidade Ni8mare para incorporação em plataformas de segurança e regras de caça [1] [2]:

10Limitações da análise

A leitura deste relatório deve levar em conta as seguintes fronteiras metodológicas e técnicas [1]:

• Ausência de detonação em laboratório controlado: a reconstituição do mecanismo adversário baseou-se exclusivamente no relatório de pesquisa divulgado pela Cyera Research Labs [1], no boletim oficial da equipe do n8n [2] e no código-fonte público do projeto no GitHub. Não houve execução de exploração contra sistemas de terceiros nem criação de exploits ofensivos não autorizados.
• Regras de detecção derivadas e não validadas em produção: as assinaturas Sigma e Suricata apresentadas na seção 07 foram formuladas teoricamente a partir das especificações do protocolo HTTP e do comportamento do middleware parseRequestBody(). Cada equipe de segurança deve homologar as regras em ambiente de teste para avaliar falsos positivos causados por integrações legítimas com estruturas similares.
• Variabilidade de caminhos de arquivos em instalações customizadas: os caminhos de dados descritos (/home/node/.n8n/database.sqlite e /home/node/.n8n/config) representam o padrão oficial das imagens de contêiner Docker. Em servidores com instalação manual via NPM ou com bancos de dados relacionais externos (PostgreSQL/MySQL), os caminhos físicos e a estratégia de recuperação de credenciais pelo invasor podem variar.
• Dependência da topologia de fluxo de trabalho para vazamento passivo: a exfiltração imediata do arquivo lido por meio do nó Form depende de como os nós subsequentes do fluxo tratam o anexo. Em fluxos que apenas descartam ou não transmitem o arquivo binário processado, a exfiltração pelo invasor exige etapas adicionais de extração.