Node-RED の脆弱性が悪用され、悪意あるフローが展開される

公開されたままの自動化インターフェースは、攻撃者がログインなしで任意のコマンドを実行する足がかりになりかねません。

VulnCheckは11月2日、監視システムがNode-REDの認証欠如の脆弱性「CVE-2026-58115」に対する悪用を検知したと報告しました。この脆弱性は、先にSiemensが一部のSIMATIC IoT2050 Advancedの環境で公表していたものです。悪用されると、最高権限でのリモートコード実行を許す恐れがあります。

管理者は、アクセス制御とアプリケーションの挙動の両面から対応する必要があります。侵入口を塞いでも、不正なワークフローがすでに仕込まれていないかどうかは確認できないためです。

攻撃者は自動化フローをコマンド実行に悪用

Node-REDは「フロー」と呼ばれるワークフローで、アプリケーションの各機能を連携させます。 VulnCheckの調査によると、攻撃者は10月30日、同社のカナリアシステムに悪意あるフローを送り込みました。このフローは、自動トリガーとシェルコマンドを実行できるノードを組み合わせたものでした。

リクエストには、Linux向けペイロードをダウンロードして実行する命令が含まれていました。ほかにも、フロー内にWebシェルを作成するリクエストが確認されています。これにより、攻撃者は後からHTTPリクエストでコマンドを送り込めます。こうしたバックドアは、再起動後も残る可能性があります。

研究者は、10月30日から11月1日にかけて、単一の送信元IPからこの脆弱性を狙う16件のイベントを記録しました。ダウンロードされたペイロードは取得できておらず、その機能は確認されていません。今回の調査結果が示すのは、VulnCheckの監視システムが受信した悪用リクエストです。産業用顧客が侵害されたことや、ダウンロードされたペイロードが正常に実行されたことまでは裏付けていません。

産業分野では、こうしたツールへのアクセスが深刻な影響を招きかねません。別の事例である IconicsのSCADAの脆弱性は、支援ソフトウェアの弱点が運用システムの可用性を脅かし得ることを示しています。

注意が必要なSiemens製品の環境

8月11日に公開されたSiemensのセキュリティアドバイザリは、影響を受ける製品として、Node-REDをインストールしたIndustrial OS上で動作するSIMATIC IoT2050 Advanced（製品番号6ES7647-0BA00-1YA2）を挙げています。

影響を受けるのはV4.3.4.1より前のバージョンです。SiemensはV4.3.4.1以降へのアップデートを推奨しています。緩和策としては、Node-REDのアンインストールか、インストール環境の堅牢化を挙げています。

この脆弱性のCVSSスコアは最大値の10.0です。影響を受ける環境ではNode-REDのHTTPインターフェースで認証が強制されておらず、システムコマンドを実行できるプログラミング機能が公開されています。なお、Siemensの修正案内にあるバージョン番号は、影響を受ける製品リリースを指すものです。Node-RED全般のアップグレード先とみなしてはいけません。

エディターとフローのエンドポイントは個別に保護

Node-REDのセキュリティガイドには、エディターと管理APIを保護するadminAuthが記載されています。管理者は、認証済みユーザーや権限を設定でき、フローを変更できるユーザーの制限もできます。

フローが作成するHTTPエンドポイントには、別途保護が必要です。Node-REDのドキュメントによると、HTTP Inノードが公開するルートには、httpNodeAuthでHTTP Basic認証をかけられます。HTTPSを使えば通信も暗号化されます。管理者は、管理インターフェースとアプリケーションのエンドポイントの両方で、認証が機能していることを確認してください。

ネットワーク制限も、もう一つの防御層になります。 ネットワークのアクセス制御とセグメンテーションを適用し、管理インターフェースに承認済みシステムからしか到達できないようにしてください。あわせて、意図しない露出がないかファイアウォールルールも見直しましょう。

対応を終える前に、何が変更されたかを確認

まず、各環境の管理者と、その環境が支える業務を明らかにします。デバイスのモデル、インストール済みのリリース、アクセス経路、担当のアプリケーションチームまたは運用チームを記録してください。これで、対応担当者はアップデートや設定確認の範囲を具体的に把握できます。

次に、展開中のフローを承認済みのベースラインと比較します。説明のつかない追加や変更、特にコマンドを起動するワークフローやHTTPエンドポイントを導入するワークフローは調査が必要です。正当な自動化がこれらの機能を使うこともあるため、存在するだけで侵害の証拠にはなりません。所有者と本来の挙動を確認する必要があります。

不審な変更が見つかった場合は、組織の インシデント対応プロセスに沿って、封じ込め、証拠収集、調査、復旧を進めてください。関連する設定とログは保全します。変更が本番環境の依存関係を止める恐れがある場合は、運用担当者も巻き込みましょう。

通常のアクセスを復旧する前に、必要なアップデートが適用済みであること、認証が強制されていること、展開中のワークフローが承認された動作と一致していることを確認します。不正なコマンド実行が疑われる場合は、基盤となるホストに別の永続化手段や認証情報の漏えいがないか調べ、再構築が必要かどうかを判断してください。復旧を裏付ける証拠は文書化し、未解決の調査項目には担当者を割り当てます。

関連記事: PHPの「Black October」対応から、インシデントを終える前に過去のアクセスを調べ、修正が有効であることを確認すべき理由が見えてきます。