Siemens IoT2050のNode-RED RCE、実際に悪用される(CVE-2026-58115)
Siemens SIMATIC IoT2050ゲートウェイ上の認証なしのNode-REDインターフェイスがコマンド実行を許す。V4.3.4.1で修正済み、実際に悪用されている。
TL;DR
- SIMATIC IoT2050 Advanced産業ゲートウェイは、Node-REDのHTTPインターフェイスに認証を課さずに動作する。デバイスに到達できる攻撃者は誰でも、シェルコマンドを実行するフローを配備できる。Siemensは2026年8月11日にこの欠陥を公表し、CVSS v3.1とv4.0で10.0と評価している。
- 参照番号6ES7647-0BA00-1YA2のSIMATIC IoT2050 Advancedのうち、イメージバージョンV4.3.4.1未満のすべてが影響を受ける。VulnCheckは、adminAuthなしのNode-REDインスタンスならどれも同じ1リクエストの配備を受け入れると補足している。
- 悪用は実際に起きている。VulnCheckのカナリア(おとり)は2026年10月30日以降、完全なエクスプロイトを記録した。このCVEは2026年11月3日時点でCISAのKEVカタログに載っていない(フィードを確認済み)。VulnCheckは自社カタログに追加した。
- すべてのIoT2050をV4.3.4.1以降に更新すること。すべてのNode-RED配備について、インターフェイスが外部から到達可能でないことを確認し、adminAuthを有効化すること。「修正方法」に強化手順がある。
影響を受けますか?
以下の条件がすべて成り立つとき、露出しています:
- 対象がIndustrial OSでNode-REDをインストールしたSIMATIC IoT2050 Advanced(6ES7647-0BA00-1YA2)で、イメージバージョンがV4.3.4.1未満であること。Siemensは他の影響モデルを挙げていない。
- Node-REDのインターフェイスに攻撃者が到達できること。Node-REDは設定ドキュメントの記載どおり、デフォルトですべてのIPv4インターフェイスのポート1880で待ち受ける。
- そのインターフェイスに認証が課されていないこと。IoT2050についてSiemensは、影響デバイスがNode-REDのHTTPインターフェイスに認証を課さないと述べている。
同じ配備攻撃は、Siemensデバイスに限らず、認証なしのNode-REDインスタンスすべてに成立する。Node-REDは広く使われている。node-redパッケージのnpm週間ダウンロード数は92,432件、公式Dockerイメージのプル数は327,470,066回である(いずれも2026年11月3日確認)。
| ブランチ | 影響バージョン | 修正バージョン |
|---|---|---|
| SIMATIC IoT2050 Advanced、Node-RED入りIndustrial OS | V4.3.4.1より前のすべて | V4.3.4.1以降 |
| Node-RED、全バージョン、未保護の配備 | すべてのリリース。エディターはデフォルトで未保護 | なし。adminAuthを設定のこと |
各ホストとゲートウェイで何が動いているか確認してください:
# Node-RED on any host: which interface and port it listens on
ss -tlnp | grep ':1880 '
# Node-RED on any host: is editor authentication configured?
grep -n "adminAuth" ~/.node-red/settings.js
//で始まるコメントのままのadminAuth行は、エディターとAdmin APIが資格情報なしでリクエストを受け入れることを意味する。自組織のネットワーク外から、各配備のエディターURL http://<host>:1880 を開いてみてください。
ログイン画面なしで読み込まれるエディターは露出している。IoT2050については、配備済みのIndustrial OSイメージのバージョンをV4.3.4.1と比較すること。更新エントリはSiemens Industry Online Supportポータルの109741799である。
修正方法
ゲートウェイを更新し、他のすべてのNode-RED配備を強化します:
- 影響を受ける各SIMATIC IoT2050 Advancedを、Siemensサポートエントリ109741799からV4.3.4.1以降に更新する。Siemensは修正済みイメージを公開しており、更新を推奨している。
- 他のすべてのNode-RED配備では、設定ファイルの
adminAuthプロパティのコメントを外して記入し、Node-REDを再起動して、エディターとAdmin APIの認証を有効にする:
// ~/.node-red/settings.js, adapted from the Node-RED securing guide
adminAuth: {
type: "credentials",
users: [ {
username: "admin",
password: "$2a$08$zZWtXTja0fB1pzD4sHCMyOCMYz2Z6dNbM6tl8sJogENOMcxWV9DN.",
permissions: "*"
} ]
}
例のハッシュはガイドがパスワードpasswordに使っているものなので、node-red admin hash-pwで生成したハッシュに置き換えてください。
- HTTPSアクセスを有効化し、HTTP NodesとNode-REDダッシュボードをBasic認証かOAuth/OpenIDプロバイダで保護する。Siemensはこの同じ3手順、またはNode-REDそのもののアンインストールを推奨している。
これを単体で修正するNode-REDのリリースは存在しない。npmパッケージを更新しても状況は変わらない。ホストでエディターが不要なら、設定ファイルのhttpAdminRoot: falseで管理エンドポイントを完全に無効化する。
Siemensの一般推奨は、適切な仕組みでデバイスへのネットワークアクセスを保護することである。更新後もポート1880を信頼できないネットワークから切り離しておくこと。
根本的な原因は何ですか?
Node-REDのエディターとAdmin APIは、設計上コマンドを実行するHTTPインターフェイスを提供し、影響デバイスはそこに認証を課していない。
Node-REDはNode.js上に構築されたフロー型プログラミングツールである。操作者がブラウザーのエディターでノードを接続すると、サーバーはそのフローが記す内容を実行する。2種類の組み込みノードが、このインターフェイスを直接危険にする。
injectノードは、スケジュールまたは起動時に一度だけメッセージを発火し、execノードはホスト上でシステムコマンドを実行する。
Admin APIはその能力をHTTPで露出する。POST /flowsエンドポイントは「アクティブなフロー構成を設定」し、権限flows.writeを要求する。ドキュメントではAuthorization: Bearer [token]ヘッダーは「認証が有効な場合のみ」とされている。
保護ガイドはデフォルトを明言している:"By default, the Node-RED editor is not secured - anyone who can access its IP address can access the editor and deploy changes."
IoT2050について、Siemensの勧告は結果を説明する。影響デバイスはNode-REDのHTTPインターフェイスに認証を課さない。その結果、認証なしで、システムコマンドを実行できるプログラミングノードにアクセスできる。CVEレコードはこれをCWE-306(Missing Authentication for Critical Function)に分類している。
Node-REDがこの既定で配布されるのは、ドキュメントが述べるとおり、このツールが信頼できるネットワークを前提としているからである。ネットワークから到達できるインターフェイスを持つ産業ゲートウェイでは、この前提が崩れる。
どのように悪用されますか?
公開されている概念実証はエクスプロイト通信そのものである。VulnCheckが2026年11月2日にデコードして公開した:
- 攻撃者はNode-REDのインターフェイスに
POST /flowsリクエストを1件送る。VulnCheckが2026年10月30日に捕捉したリクエストはcurl/8.5.0からのものだった。 - ボディは3ノードのフローを運ぶ。空のタブ、
injectノード、execノードである。injectノードは1秒後に一度だけ発火する。これは分析から引用した第1層のエンコードである:
{"flows":[
{"id":"t","type":"tab"},
{"id":"inj","type":"inject","z":"t","once":true,"onceDelay":"1","wires":[["e"]]},
{"id":"e","type":"exec","z":"t","command":"echo <base64> | base64 -d | sh","addpay":false,"wires":[[],[],[]]}
]}
- インターフェイスは
HTTP/1.1 200 OKと新しいフローリビジョンのハッシュで応答する。このため、このイベントは成功したエクスプロイトとして記録される。 - 配備の1秒後、
injectノードが発火する。execノードはデコードされたドロッパーを実行する。VulnCheckのデコードによると、ドロッパーはwgetでバイナリーを取得し(失敗時はcurl)、/dev/shm/.bに保存して実行ビットを立て、setsidかnohupでデタッチして実行する。
そのバイナリーは取得されていないため、VulnCheckは何をするものかについて主張しない。同じ発信元からの後続リクエストはペイロードを変えた。/tmp/.sとして保存・実行される段階的スクリプトwget.sh、/tmp/.kworkerとして保存されるインプラント、そしてダウンローダーをまったく配備しないフローである。
攻撃の流れはどうなりますか?
認証なしのインターフェイスへのHTTPリクエスト1件が、1秒で攻撃者のコマンドを実行するフローを配備する。
POST /flowsリクエストを送信"] --> B["Node-REDのHTTPインターフェイスが
配備を受け入れる:
認証が課されていない"] B --> C["フロー配備完了:
injectノードが1秒後に
一度だけ発火するよう設定"] C --> D["execノードがbase64で
ラップされたドロッパーを実行"] D --> E["ボットのバイナリーが
/dev/shm/.bに保存され実行される"]
攻撃者は何ができますか?
実証された影響は、Node-REDを実行するホスト上での任意のコマンド実行である。
- Siemensは、認証なしのリモート攻撃者が悪意あるフローを作成し、HTTPインターフェイスを通じて基盤サーバー上で「最大権限で任意のコードを実行」できると評価している。
- VulnCheckは2種類の悪用後の形を観測した。メモリ上の
/dev/shmに保存されるボットと、持続的なウェブシェルである。ウェブシェルのフローは、たとえば/cmdのようなHTTPエンドポイントを、functionノードを介してaddpayを有効にしたexecノードへ接続する。攻撃者は後からクエリパラメーターでコマンドを渡す。 - 条件は最小限である。インターフェイスへのネットワーク到達可能性、
adminAuthなし、そしてユーザー操作は不要。VulnCheckはこの配備をHTTPリクエスト1件と表現している。
犠牲者の確認は報告されていない。VulnCheckのイベントは単一の発信元IP 4.201.105[.]116からであり、ペイロードは取得も分析もされていない。ボットの能力について主張することはできない。
なぜ修正が効くのですか?
V4.3.4.1更新がベンダーの是正措置であり、勧告は影響範囲がこれ未満で終わると確認している。Siemensはクローズドソースの産業イメージを配布しているため、引用できる公開のパッチ差分はない。
他のすべてのNode-RED配備に対する設定の修正は、エクスプロイトが使う隙間そのものを閉じる。adminAuthを設定すると、エディターとAdmin APIの資格情報ベースの認証が有効になる。
するとPOST /flowsはAPIドキュメントが記すAuthorization: Bearer [token]ヘッダーを要求し、認証なしのリクエストは拒否される。httpAdminRoot: falseを設定するとエンドポイントそのものが消える。残りの強化手順、HTTPSとHTTP Nodes・ダッシュボードのBasic認証は、フローが開ける他の扉を閉じる。
これらの手順はNode-RED自体を変えるのではなく、問題を絞り込む。execノードは設計上その力を保つ。修正は、認証済みの操作者だけがそれを配線し配備できるようにすることである。
侵害されたかどうかを確認するには?
VulnCheckは観測された悪用の指標を公開している。一致は調査すべき手がかりであって侵害の証明ではなく、失敗した試みは痕跡を残さないこともある。
# Look for the dropped files on the Node-RED host
ls -la /dev/shm/.b /tmp/.kworker /tmp/.s 2>/dev/null
# Find every exec node and every HTTP endpoint in the deployed flows
grep -nE '"type": ?"exec"' ~/.node-red/flows*.json
grep -nE '"type": ?"http in"' ~/.node-red/flows*.json
VulnCheckが公開した、遮断と接続ログ捜索の対象となるネットワーク指標:
- 4.201.105[.]116。MicrosoftのASN AS8075内にあるエクスプロイト発信元。2026年10月30日から11月1日の間にこの欠陥を16回叩いた。
- ポート8080の85.215.73[.]250。
bot-linux-amd64とwget.shのペイロードサーバー。 - ポート38472の45.194.90[.]57。
/tmp/.kworkerとして保存される.sys_updateインプラントの背後のサーバー。
フローそのものを確認し、自分が作成していないノードを探すこと。予期しないコマンドを持つexecノード、または/cmdのようなhttp inエンドポイントがそれに接続されている場合である。アクセスログでは、不明な発信元からのPOST /flowsがHTTP 200とrevハッシュで応答されているものを探す。
VulnCheckの分析ページに指標の全表と、捜索用の初期アクセス成果物がある。
タイムライン
- 2026-08-11:Siemensが勧告SSA-834709を公開。CVE-2026-58115、CVSSスコア、修正イメージバージョンV4.3.4.1を含む。
- 2026-08-12:CVEレコード内のCISA ADP評価が、この日時点のSSVC Exploitationを「none」と記録。
- 2026-10-27:VulnCheckがこのCVE向けの検知成果物を公開。エクスプロイトPoC、バージョンスキャナー、Suricata・Snort・YARAルールを含む。
- 2026-10-30:VulnCheckのカナリアが最初の完全なエクスプロイトを捕捉。VulnCheckは自社KEVカタログにこのCVEを追加。
- 2026-10-30から2026-11-01:同じ発信元IPが16件のイベントを送信。11月1日に段階的ペイロードとウェブシェルが現れる。
- 2026-11-02:VulnCheckが悪用分析を公開。
FAQ
Node-REDプロジェクト自体は影響を受けますか?
Node-RED向けのCVEは存在せず、この件を修正するNode-REDのリリースもない。このCVEはSiemensの製品に帰属する。同社はツールを組み込み、そのインターフェイスに認証を課さなかった。Node-REDのドキュメントは、エディターがデフォルトで未保護であり、信頼できるネットワーク向きであると明言している。
この欠陥はCISAのKEVカタログに載っていますか?
載っていない。2026年11月3日時点で、カタログのJSONフィードにCVE-2026-58115のエントリーはない。VulnCheckは2026年10月30日に自社KEVカタログへ追加した。その日は同社のカナリアが最初のエクスプロイトを捕捉した日である。
誰かが侵害されましたか?
犠牲者の報告はない。VulnCheckは単一の発信元IPからカナリア網に対する悪用の試みを記録し、ペイロードは取得しなかった。ボットの能力についての主張はない。
CISA ADP評価は、10月の観測前である8月12日にExploitation「none」を記録していた。
攻撃はSiemensデバイスだけを狙っていますか?
カナリアはNode-REDインスタンスをエミュレートしており、観測された攻撃は見つけた認証なしのNode-REDすべてを叩いている。発信元IPは無関係な製品の他7件のCVEも叩いており、VulnCheckはこれを機会主義的な大量スキャンと読んでいる。
VulnCheckは、Node-REDが商用ICS・OT製品に組み込まれていると指摘している。また、Emersonのドキュメントが同社のNode-RED利用を強調しているとも指摘しており、影響は検証されていない。
「最大権限」とは何を意味しますか?
Siemensは、攻撃者がゲートウェイの基盤サーバー上で「最大権限」で任意のコードを実行すると述べている。一般的なNode-REDホストでは、コマンドはNode-REDプロセスのユーザーとして実行される。同じ配備の仕組みが当てはまる。
Node-REDはデフォルトでどこで待ち受けますか?
エディターとAdmin APIは、Node-REDの設定ドキュメントの記載どおり、デフォルトですべてのIPv4インターフェイス0.0.0.0のポート1880で待ち受ける。複数のインターフェイスを持つゲートウェイでは、配備がuiHostを上書きしない限り、ブリッジするすべてのネットワークから到達できる。
Ostorlabで露出した産業インターフェイスを見つける
Ostorlabの攻撃面探索は、指定範囲のインターネット向け公開ホストを棚卸しし、Node-REDインターフェイスで応答するすべてのデバイスを見つける。それぞれを修正済みバージョンと照合してください。Ostorlabでスキャンを始めると、どのホストを最初に更新すべきかが分かります。
参考文献
- Siemensセキュリティ勧告SSA-834709。2026年8月11日公開。CVSS v3.1・v4.0 10.0のベクトル、影響製品一覧、V4.3.4.1の是正措置、緩和策を含む:https://cert-portal.siemens.com/productcert/html/ssa-834709.html(2026年11月3日確認)
- CVE-2026-58115レコード。Siemens CNA。2026年8月11日公開。CISA ADPのSSVCブロックを含む:https://www.cve.org/CVERecord?id=CVE-2026-58115(2026年11月3日確認)
- VulnCheck、「Exploitation Targeting Node-RED, a Tool Embedded in ICS Products」。2026年11月2日公開。デコード済みエクスプロイト、指標表、後続ペイロードを含む:https://www.vulncheck.com/blog/exploitation-targeting-node-red(2026年11月3日確認)
- The Hacker News、「Attackers Exploit Critical Siemens IoT2050 Flaw to Plant Remote Command Backdoors」。2026年11月3日公開:https://thehackernews.com/2026/11/attackers-exploit-critical-siemens.html(2026年11月3日確認)
- Node-RED保護ガイド「Securing Node-RED」。エディターがデフォルトで未保護という明言と、adminAuth・HTTPS・HTTPノードの手順:https://nodered.org/docs/user-guide/runtime/securing-node-red(2026年11月3日確認)
- Node-RED Admin HTTP API、POST /flows。「認証が有効な場合のみ」のBearerトークンヘッダー:https://nodered.org/docs/api/admin/methods/post/flows/(2026年11月3日確認)
- Node-RED設定ドキュメント。uiHost・uiPortのデフォルト値とhttpAdminRoot:https://nodered.org/docs/user-guide/runtime/configuration(2026年11月3日確認)
- npmのnode-redパッケージページ、週間ダウンロード数:https://www.npmjs.com/package/node-red(2026年11月3日確認)
- Docker Hubのnodered/node-redページ、イメージのプル数:https://hub.docker.com/r/nodered/node-red(2026年11月3日確認)
- CISA KEVカタログのJSONフィード。CVE-2026-58115を検索し、2026年11月3日時点で一致なし:https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json(2026年11月3日確認)