1
tifon
5 min de leitura ·

Node-RED sem adminAuth está sendo explorado com um único POST em /flows (CVE-2026-58115)

Se você tem um Node-RED rodando em algum lugar, seja num Raspberry com automação de casa, num servidor da empresa ou num gateway industrial, confira hoje se o editor pede senha. Num post de 02/11, a VulnCheck conta que em 30/10 um dos canários dela (sensores-isca) pegou exploração ativa da CVE-2026-58115, e resume assim: "Node-RED instances without adminAuth are being found and exploited automatically".

A CVE foi atribuída pela Siemens e cobre um produto dela. O aviso SSA-834709, de 11/08, diz que o SIMATIC IoT2050 Advanced com Industrial OS e Node-RED instalado, antes da V4.3.4.1, não exige autenticação na interface HTTP do Node-RED. Quem alcança essa interface cria flows e executa código com privilégios máximos, sem login e sem interação. CVSS 10.0. A Siemens manda atualizar para a V4.3.4.1 ou posterior, ou desinstalar o Node-RED, ou protegê-lo seguindo o guia do próprio projeto.

Fora do IoT2050 não existe patch para aplicar, porque editor aberto é o padrão documentado do Node-RED. Ele aceita conexão em todas as interfaces IPv4, na porta 1880, e o guia de segurança avisa: "the Node-RED editor is not secured - anyone who can access its IP address can access the editor and deploy changes". O ataque usa a API padrão de deploy, então serve para qualquer instância sem adminAuth que a rede alcance.

Como o ataque funciona

Não tem bug de memória nem truque. O Node-RED existe para executar lógica definida em flows, e entre os nós nativos está o exec, que roda comando de shell. O exploit capturado pela VulnCheck é um único POST /flows com três nós:

  • uma aba vazia;
  • um inject com once: true e onceDelay: "1", que dispara sozinho um segundo depois do deploy;
  • um exec cujo comando decodifica um texto em base64 e entrega o resultado ao sh.

O base64 esconde o downloader de filtros que procuram wget ou curl no corpo da requisição. Decodificado, ele baixa um binário chamado bot-linux-amd64 (com wget, ou curl se o primeiro faltar), salva em /dev/shm/.b, dá chmod +x e solta com setsid para sobreviver ao processo do Node-RED. Como /dev/shm fica em memória, o arquivo some no reboot, a não ser que o bot crie persistência por conta própria. A VulnCheck não baixou o binário, então não sabe se é minerador, bot de DDoS, shell reverso ou outra coisa.

Até 01/11 apareceram outras variações. Uma baixa um script wget.sh e roda como /tmp/.s; outra salva um payload como /tmp/.kworker, nome que imita uma thread do kernel. A que dá mais trabalho não baixa nada: o flow cria um endpoint http in (/cmd ou um caminho aleatório) ligado por um nó function a um exec com addpay ativo, a opção que acrescenta o msg.payload ao comando. Daí em diante o atacante manda o comando num parâmetro da URL. Como o flow fica salvo, esse webshell continua lá depois do reboot.

De onde veio

Tudo partiu de um único IP da Microsoft (AS8075) geolocalizado no Brasil: 16 eventos contra o Node-RED entre 30/10 e 01/11, com pelo menos cinco user agents e vários payloads. No total, o mesmo endereço soma 125 tentativas contra 8 CVEs, entre elas falhas de Apache Solr, Camunda, Gitea, MLflow, Traefik e Joomla. A VulnCheck lê isso como varredura oportunista em massa, numa máquina provavelmente alugada ou compartilhada por mais de um operador, e não diz quem está por trás. Ela pôs a falha no próprio KEV; no da CISA, até a atualização de 30/10, não está.

O que eu conferiria

1. Se a porta aparece de fora. Teste de outra rede (o 4G do celular serve): se o editor abre na porta 1880 sem pedir senha, qualquer um que chegue nela faz deploy.

2. Ligar o adminAuth. Gere o hash com node-red admin hash-pw (Node-RED 1.1.0 ou mais novo), ponha no settings.js e reinicie o Node-RED:

adminAuth: {
    type: "credentials",
    users: [{
        username: "admin",
        password: "<hash gerado pelo hash-pw>",
        permissions: "*"
    }]
},

Isso protege o editor e a API de administração, onde entra o POST /flows. As rotas dos nós http in são outra coisa: para elas existe o httpNodeAuth, com autenticação básica. Se ninguém precisa acessar de fora, descomente a linha do uiHost que o settings.js padrão já traz (a que só aceita conexão da própria máquina) e entre por VPN ou túnel SSH.

3. Procurar sinais. Nó exec que você não lembra de ter posto, endpoint http in estranho como /cmd, e os arquivos dos droppers:

cd ~/.node-red   # pasta padrão; na imagem Docker oficial, /data
# o que cada exec roda e os caminhos dos nós HTTP
grep -Eo '"(command|url)": ?"[^"]*"' flows*.json
# arquivos deixados pelos droppers
ls -la /dev/shm/.b /tmp/.s /tmp/.kworker 2>/dev/null

O flows*.json cobre os dois nomes padrão (flows.json e flows_<hostname>.json), com ou sem pretty-print. Um exec de comando vazio roda o que chega na mensagem, como no webshell. Ter exec no flow não prova nada, muita automação usa; o que importa é se você reconhece cada um. Não achar os arquivos também não prova nada, porque /dev/shm se apaga no reboot. Os IPs dos servidores de payload estão no post da VulnCheck.

4. Se achou algo. Eu trataria como comprometido. Reiniciar não remove o webshell, que está no flow salvo. E o comando rodou com o usuário do Node-RED (no IoT2050, com privilégio máximo), então as credenciais guardadas nos nós, como MQTT, banco e APIs, devem ser trocadas.

Juntamos as reportagens do caso numa página do Tifon, projeto nosso de notícias de segurança: tifon.dev/materia/151ab667…. Primárias: VulnCheck, aviso da Siemens e guia de segurança do Node-RED.

Carregando publicação patrocinada...