O Node.js lançou atualizações de segurança em 21 de outubro de 2026 (22.23.4, 24.22.1, 26.12.1). Elas corrigem quatro problemas de alta severidade, incluindo CVE-2026-111497, uma escrita fora dos limites no decodificador Brotli que pode permitir execução remota de código, além de dois bypasses de verificação de hostname TLS (CVE-2026-105483, CVE-2026-106069).
Nosso n8n auto-hospedado (versão estável mais recente, 2.44.4) e seu container de task-runners relatam Node v26.7.0, então ainda estão no runtime não corrigido.
Duas perguntas:
Existe um ETA para um lançamento estável cuja imagem Docker seja construída no Node 26.12.1 ou posterior?
Até lá, existe uma mitigação recomendada para auto-hospedadores com webhooks públicos?
Uma atualização: 2.44.5 agora está listado, embora eu não tenha conseguido confirmar pelas notas de lançamento se o runtime do Node incluído mudou.
A equipe poderia confirmar as primeiras tags de imagem corrigidas para n8n e task-runners, e se há uma avaliação oficial de exposição ou orientação provisória? Eu não assumiria que apenas a versão mais recente do n8n confirma o corrigimento do runtime.
Nenhuma previsão que eu saiba. Enquanto isso, eu colocaria webhooks públicos atrás de um reverse proxy ou Cloudflare que passa apenas os caminhos de webhook exatos, descarta requisições com Content-Encoding br, e adiciona um secret de header ou allowlist de IP. Também certifique-se de que o contêiner do task runner não seja acessível de fora.
Gostaria de adicionar meu apoio e enfatizar que isso merece uma resposta rápida da equipe n8n.
De acordo com o Dockerfile no master, a imagem estável atual (n8nio/n8n:2.44.5) usa Node.js 26.10.0. Os lançamentos de segurança do Node.js publicados em 21 de outubro de 2026 (incluindo 26.12.1) corrigem mais do que os problemas listados acima. Um em particular que me preocupa é o comprometimento da AC Intermediária eMudhra ( https://emudhra.we-have-a-problem.com/ ), que também é abordado nesses lançamentos mesmo não tendo CVE.
Por que acho que isso é urgente para o n8n em particular: n8n é um produto construído para se comunicar com endpoints externos arbitrários. O nó HTTP Request e muitas integrações fazem conexões TLS de saída para hosts escolhidos pelo autor do fluxo de trabalho, e frequentemente transportam credenciais e dados sensíveis. Uma AC intermediária comprometida no armazenamento de confiança afeta diretamente a confiabilidade dessas conexões.
Oi @Nickolas_Steel, os Dockerfiles 2.44.5 ainda direcionam Node 26.10.0 para n8n e task runners. Não consegui encontrar um ETA publicado para imagens estáveis usando 26.12.1, ou uma avaliação de exposição específica do n8n.
Uma ressalva à mitigação acima: bloquear requisições Content-Encoding: br apenas cobre esse caminho de entrada. Não cobre os problemas de verificação de hostname TLS, ou dados Brotli baixados e descompactados por um workflow.
Até que imagens corrigidas sejam confirmadas, eu restringiria chamadores públicos de webhook e pausaria temporariamente caminhos que processam conteúdo compactado não confiável ou buscam URLs controladas pelo atacante. Mantenha o task broker na porta 5679 privado, assim como o container runner. Essas são medidas de contenção, não um substituto para as correções de runtime.
Confirmando isso da minha parte, com a versão do Node verificada diretamente em cada imagem (docker run --rm --entrypoint node ``ghcr.io/n8n-io/n8n:``<tag> -v):
tag n8n
Node
2.38.7
v26.7.0
2.44.5 (stable, Oct 21)
v26.10.0
2.45.1 (beta)
v26.10.0
Então 2.44.5 fez o bump do Node, mas apenas para 26.10.0. Isso ainda está abaixo da versão corrigida 26.12.1, então não fecha CVE-2026-111497, CVE-2026-105483 ou CVE-2026-106069.
Olhando para o repo, docker/images/runners/Dockerfile fixa NODE_VERSION=26.10.0, e a imagem principal é construída em uma imagem base Node DHI. O bump está aguardando uma imagem DHI corrigida? Um ETA para a primeira tag stable com Node ≥ 26.12.1, tanto para n8n quanto para runners, ajudaria os auto-hospedadores a planejarem. Obrigado!
Eu também estou um pouco preocupado com essa questão. Não só pela ameaça à segurança, mas pela falta de resposta do lado do n8n. Sei que não podemos pedir uma atualização instantânea, mas pelo menos esperamos um simples post com os próximos passos e o ETA estimado.
A resposta sobre segurança é importante para nós, a comunidade
Atualização rápida: o n8n acaba de lançar novas versões em ambos os canais, estável 2.44.6 e beta 2.45.2.
Verifiquei a versão estável 2.44.6 e sua versão do Node.js agora é v26.12.1, portanto as correções de segurança do Node.js 26.12.1 (incluindo a do eMudhra Intermediate CA) estão agora na imagem do Docker.
❯ docker run --rm --entrypoint node n8nio/n8n:2.44.6 -v
v26.12.1
❯ docker run --rm --entrypoint node n8nio/runners:2.44.6 -v
v26.12.1
Oi Nickolas, Urška do suporte n8n aqui. Confirmando o que blueberrystream encontrou: 2.44.6 no stable é construído no Node 26.12.1, tanto a imagem n8n quanto a imagem dos task runners. 2.45.2 no beta define a mesma versão do Node em seus Dockerfiles.
Para a segunda pergunta, a resposta é a atualização em si. Não tenho um contorno que eu recomendaria em lugar dela, então eu migraria para 2.44.6 em vez de tentar proteger um runtime sem patch.