Node-REDの認証なし画面に攻撃 版では見つからない機器の探し方

Node-REDの版を上げても、この脆弱性はふさがりません。Node-REDは初めから認証が切ってあり、管理画面とAPIに届けば、だれでもフローを入れ替えられるからです。

その設定を狙う攻撃を、脆弱性情報の会社VulnCheckが11月2日に報告しました。10月30日、同社のおとりのサーバーに、コマンドを動かすフローを送り込む要求が届いたといいます。工場の設備やIoTゲートウェイでNode-REDを動かしている会社は、まず機器を探すところからです。

番号はSiemensのIoT2050、SIMATICが無くても関係する

報告が挙げるCVE-2026-58115は、Siemensが8月11日に公表した番号です。対象はNode-REDを入れたSIMATIC IoT2050のAdvanced、Basic、M.2、SMの4機種で、V4.3.4-1より前です。公開のときの題はAdvancedだけでしたが、11月4日の改訂（V1.1）で対象の一覧と題が改められました。CVSSはv3.1とv4.0のどちらも10.0です。

VulnCheckの結論は、それより広いものです。adminAuth（エディタと管理APIの認証）の無いNode-REDが自動で見つけられ、悪用されているとしています。フローの配備に要るのは、HTTPの要求1回だけでした。

落とし穴はここでしょう。番号に付いた製品名はSIMATICなので、Siemensの機器が無い会社の台帳やスキャナーからは行き着きにくいはずです。しかも設定の問題なので、Node-REDの版を見ても分かりません。Node-REDを使っていない会社に、この件で要る作業はありません。逆に「SIMATICが無いから関係ない」は早計です。

VulnCheckが見たのは、おとりに届いた要求です。10月30日から11月1日に同じIPアドレスから16回届き、そのアドレスは8つのCVEに計125回の要求を送っていました。同社は、特定の相手を狙うより手当たりしだいに近いと読んでいます。

落とされるプログラムの中身は解析しておらず、実在の工場の被害も報告にはありません。同社は自社のKEVにこの番号を入れましたが、CISAのKEVには11月3日の版でも載っていません。

GET /の200では判定できない

Node-REDの手引きは、冒頭でこう断っています。

By default, the Node-RED editor is not secured - anyone who can access its IP address can access the editor and deploy changes.

信頼できるネットワークの中だけで使う前提です。今の最新版5.0.9に付いてくる設定のひな形でも、adminAuthはコメントのままで、ポートは1880、すべてのIPv4のインターフェースで待ち受けます。

編集部は5.0.9を検証用のサーバーの中だけ（127.0.0.1）で動かし、adminAuthの有無で応答を比べました。

1行目は要注意です。認証を入れても/は200を返すので、スキャナーや死活確認では区別できません。/flowsの応答を見ます。人がブラウザで開けば、ログインの窓で分かります。

もっと気がかりなのは最後の行でした。adminAuthが守るのはエディタと管理APIだけで、フローの中のHTTP Inは別の設定（httpNodeAuth）です。試したのは応答を返すだけの無害なフローですが、VulnCheckは同じ形にコマンドの実行をつないだWebシェルを確認しています。認証を足しただけでは、すでに置かれたWebシェルは閉じません。

台帳に載らない機器を探す手順

Node-REDは、Raspberry Piでもクラウドでも動きます。情シスの台帳より、生産技術や設備の担当者の頭の中にあることが多いかもしれません。探す手は4つです。

1. 人に聞きます。生産技術、設備、ビル管理、研究開発の担当者に、使っていないかを尋ねます。名前が通じなければ、「箱を線でつないでデータの流れを作る画面」と言えば伝わるはずです。
2. 装置のメーカーと保守の会社に、組み込みの有無を問い合わせます。Siemensのほか、VulnCheckはEmersonの文書にも記述があると触れています（影響は未検証）。
3. ネットワークからTCP 1880を探します。自社のグローバルIPとクラウドのVMも対象です。ポートを変えた機器は出てこないので、1の答えと合わせます。工場のネットワークは、止めてよい時間を現場と合わせてから流します。
4. サーバーの上で探します。Linuxならss -ltnp | grep 1880で待ち受けを見ます。公式のスクリプトで入れたならsystemctl status nodered.serviceでも分かります。Dockerならdocker psでnodered/node-redのイメージを見ます。

現場の声も手がかりです。POST /flowsはフローの全体を置き換えるので、手元の検証でも元のHTTP Inは404になりました。「急に動かなくなった」「フローが消えた」という話があれば、機器の.flows.json.backupと見比べます。

見つけたら、自社の機器に限って次の1行を打ちます。

curl -s -o /dev/null -w '%{http_code}\n' http://機器のIP:1880/flows

200なら、まず認証なしとみます。読み取りだけを許す設定のこともあるので、/auth/loginが{}かも見ます。401なら認証は入っています。404なら管理の場所を移している機器です（httpAdminRoot）。移した先の/flowsを見ます。HTTPSの機器はhttps://に替えて同じように見ますが、編集部はHTTPSでは試していません。

社外から届く認証なしの機器は今日、社内だけのものは今週のうちに手を付けます。社内だけなら安全とは言えません。社内のPCが1台乗っ取られれば、そこからは届くからです。認証が入っていても、過去に開いていた時期があれば次の点検も要ります。機器の~/.node-red（Dockerなら/data）にあるflows.jsonを見ます。

認証を足す前に、フローを保存して中を見る

順番は、中を見るのが先です。200を返しているうちなら、機器に入らなくてもフローを写せます。

curl -s http://機器のIP:1880/flows -o flows-機器名.json
jq -r '.[] | select(.type=="exec" or .type=="http in") | [.type, (.command // .url)] | @tsv' flows-機器名.json

execノードは正当な用途でも使われるので、作った人に覚えがあるかを聞いてください。VulnCheckの報告に出てくるのは次の形です。

• injectとexecだけをつないだフロー。配備の直後に自動で動きます
• /cmdやランダムな名前のHTTP Inから、functionを経てexecへつなぐWebシェル
• 置かれるファイル /dev/shm/.b、/tmp/.s、/tmp/.kworker
• 通信先 85.215.73[.]250:8080、45.194.90[.]57:38472。送信元は4.201.105[.]116

/dev/shmはメモリの上にあり、再起動で消えます。覚えのないフローが出たら、再起動や削除の前に機器をネットワークから切り離し、保存したファイルと一緒に調べてください。Siemensの機器では、この脆弱性から動くコードに最大の権限が与えられるとされます。

ふさぎ方は機器で分かれます。SIMATIC IoT2050はV4.3.4-1以降へ上げるか、Node-REDを外します。ほかの機器は、settings.jsのadminAuthを有効にします。パスワードのハッシュはnode-red admin hash-pwで作れます。

現場で止まらないよう、2つ注意してください。httpNodeAuthを入れると全部のHTTP Inに認証がかかり、1880をネットワークで閉じると同じポートのHTTP Inも止まります。呼び出し元を先に確認します。

変更はNode-REDの再起動で効き、起動時に動くinjectはそこでまた動きます。覚えのないフローを外してから、現場と時間を合わせて再起動します。

工場の機器を棚卸しするなら、Defender for IoTのOT監視の終了で挙げた項目と同じ表にまとめると、手間が1回で済みます。問われているのは版の管理より、社内のだれが線をつないでいるかを知っているかです。

本文の応答の比べは、編集部がNode-RED 5.0.9で2026年11月4日に確認しました。

2026年11月5日 更新：SiemensのSSA-834709が11月4日の改訂（V1.1）で対象を見直したので、SIMATIC IoT2050の4機種（Advanced、Basic、M.2、SM）と修正版の表記（V4.3.4-1）に直し、勧告の図も撮り直しました。