2026/11/4

Node-RED・Android の2026年11月セキュリティ情報まとめ：影響範囲と環境別の対処手順

10月30日以降、認証のないNode-REDの管理画面を狙う攻撃が観測され（VulnCheckは、Siemens製品向けのCVE-2026-58115〔Siemensの評価でCVSS 10.0〕として報告）、Androidでは11月の月例のセキュリティ情報で216件（うちCritical 23件、当社集計）が修正されました。影響の確認方法、Node-REDの認証の設定と更新の手順、Androidのパッチレベルの確認方法、更新後に確認することをまとめました。

Node-RED：初期設定ではエディターと管理APIに認証がありません。10月30日以降、認証のないNode-REDに悪意のあるフローを送り込む攻撃が観測されています（VulnCheck）
CVE-2026-58115：Siemensが付けたCVSS 10.0の番号で、対象はNode-REDを入れたSIMATIC IoT2050 Advancedです。Node-RED本体の脆弱性ではありません
Node-REDの対処：adminAuthで認証を有効にし、1880番ポートを外部に出さないこと。最新の5.0.9・4.1.17に更新しても、認証は自動では有効になりません
Android：11月2日のセキュリティ情報で216件（うちCritical 23件、当社集計）を修正。最も深刻なのはFrameworkのリモートコード実行（CVE-2026-58868）です
11月4日時点で、どちらもCISAのKEV（悪用が確認された脆弱性の一覧）には未掲載です。Node-REDは攻撃が観測されているため、外部に公開しているものから最優先で対処してください

この記事について

2026年11月4日（日本時間）時点で、Siemens、米国CISA、CVEの記録、Node-REDの公式文書、GoogleのAndroidのセキュリティ情報、VulnCheckの報告を確認してまとめたものです。状況は変わるため、作業前に末尾の公式リンクで最新の情報をご確認ください。

深刻度の数値は発表元によって異なります。本文では、どの機関の評価かを明記しています。

まず確認：自分の環境は影響を受けるか

Node-RED

動いているか：サーバー、IoTゲートウェイ、監視用の端末のほか、機器メーカーのゲートウェイ製品に組み込まれたものも含めて、Node-REDが動いているものを洗い出します。初期設定のポートは 1880 です
待ち受けのアドレス：初期設定（uiHost）では、すべてのIPv4のインターフェース（0.0.0.0）で待ち受けます。Linuxでは ss -ltnp | grep 1880 で、0.0.0.0:1880 や外部向けのアドレスで待ち受けていないか確認します
認証が有効か：ブラウザーで http://<ホスト>:1880/ を開き、ログイン画面が出ずにエディターが表示される場合は認証がありません。settings.js の adminAuth が設定されているか（コメントアウトのままでないか）も確認します
管理APIの確認：curl -s -o /dev/null -w '%{http_code}\n' http://<ホスト>:1880/settings が 200 を返す場合は、認証なしで管理APIを使える状態です。認証が有効なら 401 が返ります（adminAuth の default で匿名ユーザーに権限を与えている場合は、認証があっても 200 になります。httpAdminRoot を変えている場合はそのパスの下で確認し、httpAdminRoot: false にした場合は 404 になります）
バージョン：起動時のログの Node-RED version: vX.Y.Z、または管理APIの GET /settings の応答の version で確認できます。node-red -v はバージョンの表示ではなく、詳しいログを出す指定です。4系以降では node-red --version で表示できます
Siemens SIMATIC IoT2050 Advanced：製品番号 6ES7647-0BA00-1YA2 で、V4.3.4.1 未満のIndustrial OSを動かしていて、Node-REDを入れている場合が、CVE-2026-58115 の正式な対象です

Android

パッチレベル：「設定」の端末情報の中にある「Androidセキュリティアップデート」の日付を確認します（表示の場所は機種によって異なります）。2026-11-05 以降なら、今回のセキュリティ情報のすべての問題に対応しています
パソコンから確認する場合：adb shell getprop ro.build.version.security_patch で、パッチレベルの日付が表示されます
2つのパッチレベル：2026-11-01 はAndroid本体（Android runtime・Framework・System）とGoogle Playシステムアップデートの分です。2026-11-05 はそれに加えて、カーネルとチップメーカー（Arm、Imagination、MediaTek、Unisoc、Qualcomm）の部品の分を含みます

Node-RED：CVE-2026-58115 と認証のないNode-REDへの攻撃

何が起きたか

CVE-2026-58115（Siemensの評価）：CVSS v3.1 10.0（CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H）、CVSS v4.0 10.0 です。弱点の分類は CWE-306（重要な機能の認証の欠如）で、Siemensは8月11日にアドバイザリ SSA-834709 を出しました
原因（Siemensの説明）：対象の機器では、Node-REDのHTTPのインターフェースで認証が強制されていません。そのため、システムのコマンドを実行できるノードが認証なしで使え、遠隔の攻撃者が悪意のあるフローを作って、最高の権限で任意のコードを実行できるおそれがあります
公表の経緯：米国CISAは8月25日に、同じ内容を ICSA-26-237-03 として公表しました（対象の分野は化学、重要製造、エネルギー、交通）。日本ではJVNが8月12日に、Siemens製品の8月の更新をまとめた JVNVU#98375707 で取り上げています
攻撃の観測（VulnCheck）：VulnCheckは11月2日の記事で、同社のおとり（カナリア）が10月30日にこのCVEを狙う攻撃を捉えたとしています。攻撃は1回の POST /flows で、Linux用のボットをダウンロードして実行するフローを配置するものでした。同じ送信元から、10月30日〜11月1日に16件を観測し、ボットの中身は分析していないとしています
その後の攻撃：VulnCheckは、別の配布用のサーバーや、再起動しても残るWebシェル（http in ノードと exec ノードをつないだもの）を置く攻撃も確認したとしています
公式の評価との違い：CVEの記録にあるCISAの評価（8月12日）は「悪用なし」のままで、11月3日版のCISA KEVにも掲載されていません。当社が確認した範囲では、現時点で悪用を報告しているのはVulnCheckの観測だけで、同社は自社のKEVに追加しています

対象の範囲：Node-RED本体の脆弱性ではない

正式な対象：Siemens、CISA、CVEの記録では、対象は SIMATIC IoT2050 Advanced（6ES7647-0BA00-1YA2）で、V4.3.4.1 未満のIndustrial OSを動かしていて、Node-REDを入れているものだけです
Node-REDのプロジェクト：Node-REDのGitHubのセキュリティアドバイザリの一覧に、このCVEのアドバイザリはありません（11月4日時点で、アドバイザリは2021年2月の2件だけ）。このCVEに対応するNode-REDの修正版はありません
VulnCheckの見方：VulnCheckは、このCVEの説明を自社のおとりの検知の特徴と観測した通信に基づいて付けたとしています。そのうえで、adminAuth のないNode-REDが自動的に探され、攻撃されていると結論づけています。攻撃先がSiemensの機器だったとは書いていません
根本の条件：Node-REDの公式文書は、初期設定ではエディターが保護されておらず、信頼できるネットワークでのみ使うべきだとしています。今回の攻撃は、この初期設定のまま外部から届くNode-REDを狙ったものです

一部の報道は「Node-REDの重大な脆弱性」と伝えていますが、Node-REDを使っている場合に必要なのは、ソフトの更新よりも、認証を有効にして外部から届かないようにすることです。

特に危険な構成

1880 番ポートが、インターネットや信頼できないネットワークから届く状態になっている
adminAuth を設定しておらず、エディターと管理APIに誰でもアクセスできる
exec ノードなどでOSのコマンドを実行できる状態で、Node-REDを root などの強い権限で動かしている
機器メーカーのゲートウェイなどに組み込まれていて、担当者がNode-REDが動いていることを把握していない

対処：Node-REDの認証の設定と更新

外部から切り離す：まず、ファイアウォールなどで 1880 番ポートをインターネットと信頼できないネットワークから遮断します。遠隔で操作する場合は、VPNなどを経由します。Dockerで -p 1880:1880 と公開している場合、ufwなどのファイアウォールの設定が効かないことがあります。同じ端末からだけ使う場合は、コンテナを -p 127.0.0.1:1880:1880 で作り直します
認証を有効にする：settings.js の adminAuth を設定します。パスワードのハッシュは node-red admin hash-pw で作れます（Node-RED 1.1.0 以降）。OAuth・OpenIDも使えます。古い httpAdminAuth は非推奨です
公開しているHTTPの入口を守る：http in ノードで公開している画面やAPIには httpNodeAuth、静的なファイルには httpStaticAuth で、基本認証をかけられます
HTTPSにする：settings.js の https に、鍵と証明書（PEM）を設定します
待ち受けを絞る：同じ端末の中だけで使う場合は、uiHost を 127.0.0.1 にします（Dockerのコンテナの中でこう設定すると、ホストからも接続できなくなります。Dockerでは手順1の -p 127.0.0.1:1880:1880 を使います）。エディターが要らない運用では、httpAdminRoot: false で管理用の画面とAPIをすべて止められます
再起動して確認する：設定を変えたらNode-REDを再起動し、ログイン画面が出ること、/settings が 401 を返すことを確認します

Node-RED自体の更新の方法は、入れ方によって異なります。作業の前に、フローと設定のあるユーザーディレクトリ（初期設定では ~/.node-red）をバックアップしてください。

npmで全体にインストールした場合：先に node -v でNode.jsのバージョンを確認します。5.0.9 はNode.js 22.9未満では起動しないため、Node.jsを先に更新するか、4系のまま sudo npm install -g node-red@4.1.17 を実行します（4.1.17 は Node.js 18.5 以上が必要）。22.9以上なら sudo npm install -g node-red を実行します（Windowsでは sudo なし）
Raspberry Pi・Debian系でスクリプトを使った場合：同じスクリプト bash <(curl -sL https://github.com/node-red/linux-installers/releases/latest/download/install-update-nodered-deb) を実行し直します。11月4日時点のスクリプト（v2.2.1）は、Node.jsが22.9以上ならそのまま使います。Node.jsがない場合は新しく入れ、22.9未満の場合は既存のNode.jsを削除して入れ直します（入るのはNode.js 24、ARMv6のPi 1・Pi Zeroなどでは22）。そのうえでNode-REDをサービスとして設定します。公式文書の説明は「20以上」「22 LTS」のままで、実際のスクリプトとは異なります。Node.jsのバージョンが変わるため、同じ端末でほかのNode.jsアプリを動かしている場合はご注意ください
公式Dockerイメージ：nodered/node-red の新しいタグを取得し直し、コンテナを作り直します（例：docker pull nodered/node-red:5.0.9）。4系のままにする場合は nodered/node-red:4.1.17-22 などのタグを使います。データは /data のボリュームに残しておきます
snap：Node-REDの公式文書は snap を一般にはすすめていません。snap のNode-REDは閉じた環境で動き、exec ノードの外部のコマンドなどが使えません。snapで入れた場合は sudo snap refresh node-red で更新しますが、11月4日時点で snap の stable チャンネルは 3.1.0 のままで、5.0.9・4.1.17 にはなりません。新しい版が必要な場合は、npm か Docker での入れ直しを検討してください
最新版：最新は 5.0.9（Node.js 22.9 以上が必要）と、4系の保守版 4.1.17 で、どちらも10月21日の公開です。どちらもメンテナンスリリース（不具合の修正など）で、セキュリティアドバイザリは出ていません。5.0.9 には、adminAuth を設定していないときに認証の通信で落ちる不具合の修正が含まれます
Siemens SIMATIC IoT2050 Advanced：V4.3.4.1 以降に更新します。すぐに更新できない場合、Siemensは、Node-REDのアンインストールか、Node-REDの利用者ガイドに沿った強化を挙げています

すぐに対応できない場合の暫定策（いずれも不完全）

使っていないNode-REDは止めます。スクリプトで入れた場合は sudo systemctl stop nodered で止め、sudo systemctl disable nodered で起動時に自動で立ち上がらないようにします
ネットワーク機器の設定で、1880 番への接続を、決まった管理用の端末だけに絞ります
Node-REDを root で動かしている場合は、権限の弱い専用のユーザーで動かすように変えます

侵害されていないかの確認

見覚えのないフロー、特に exec ノードや http in ノードを含むものがないか、エディターと flows.json（初期設定では ~/.node-red の中。古い設定では flows_<ホスト名>.json、Dockerでは /data/flows.json）で確認します
外部への不審な通信や、見覚えのないプロセス、cron の登録がないか確認します
侵害が疑われる場合は、ネットワークから切り離し、OSの入れ直しを検討します。Node-REDに保存した資格情報（flows_cred.json、古い設定では flows_<ホスト名>_cred.json）に含まれるパスワードやキーも変更します

Android：2026年11月のセキュリティ情報

修正された主な脆弱性

公開：Googleは11月2日に、2026年11月のAndroidのセキュリティ情報（バージョン1.0）を公開しました。日本語の版もあります
件数（当社集計）：セキュリティ情報には合計の記載がないため、表を数えると216件で、Criticalが23件、Highが193件です。2026-11-01 のパッチレベルで119件（うちCritical 8件）、2026-11-05 で97件（うちCritical 15件）が加わります
CVE-2026-58868（Googleの評価でCritical）：Frameworkのリモートコード実行で、追加の権限もユーザーの操作も要りません。CVEの記録では、FrameDecoder.cpp の onOutputReceived でのヒープの境界外の書き込みが原因で、Android 14、15、16、16-qpr2、17 が対象です
そのほかのCritical：System のリモートコード実行（CVE-2026-58876、CVE-2026-58936）、カーネルの Bluetooth や pKVM の権限昇格、MediaTek のモデムの8件、Qualcomm の非公開の部品の1件などです。カーネルで最も深刻な問題は、追加の実行権限もユーザーの操作も要らない遠隔からの権限昇格につながるとしています
報道されている問題：CyberInsiderは、System の Critical（サービス拒否）である CVE-2026-58882 が、10月29日に研究者が公表した、細工した WAP Push のメッセージで通話が切れる問題だと報じています。セキュリティ情報自体には、この説明はありません
悪用の状況：今回のセキュリティ情報には「限定的な標的型の悪用」の注記はありません。CVE-2026-58868 は11月3日版のCISA KEVに未掲載で、CVEの記録にあるCISAの評価（11月2日）も「悪用なし」です
ソースの公開：Googleは、セキュリティ情報の公開から48時間以内にAOSPにソースの修正を公開するとしています。端末メーカーには、少なくとも1か月前に通知しています

端末ごとの配布の状況

Pixel：11月4日時点で、2026年11月のPixelのアップデート情報は公開されていません。最新は10月6日公開の10月版（パッチレベル 2026-10-05）です
そのほかのメーカー：配布の時期は、メーカー、機種、通信会社によって異なります。各社のセキュリティ情報のページで確認してください
サポートが終わった端末：メーカーの更新の期間が終わった端末には、今回の修正の大部分は届きません（一部はGoogle Playシステムアップデートで届く場合があります）

対処：端末の更新と確認

端末のパッチレベルを確認します
「システムアップデート」から更新を入れ、再起動します
パッチレベルが 2026-11-05 以降になったことを確認します
更新が届かない古い端末は、業務での利用、特に管理画面や認証に使う端末から、入れ替えを検討します

業務用の端末や、データセンターでの作業に使う端末は、メーカーの更新が届き次第、2026-11-05 以降にします
端末管理（MDM）を使っている場合は、パッチレベルの一覧で、更新が届いていない端末を把握します

更新後に必ず確認すること

Node-RED：再起動後に、ログイン画面が出るか、/settings が 401 を返すか、外部から 1880 に届かないかを確認します
Node-RED のフロー：見覚えのないフロー、特に exec ノードや http in ノードを含むものがないか、もう一度確認します
Docker：古いコンテナが残っていないか、docker ps で新しいイメージのタグで動いているかを確認します
Android：パッチレベルが 2026-11-05 以降になっているか、端末ごとに確認します
組み込み製品：Node-REDを組み込んだ機器は、機器メーカーの情報を確認します

公式情報（一次情報）

免責事項

本記事は2026年11月4日時点の公開情報を Two Sheep株式会社が整理したもので、各製品の動作や安全性を保証するものではありません。作業の前に、必ず各提供元の最新情報をご確認ください。記載の社名・製品名は各社の商標または登録商標です。記載の企業名は情報の出典・対象として記したもので、当社との取引関係を示すものではありません。

データセンターに設置したサーバーの再起動、コンソール作業、機器交換など、現地での作業が必要な場合は、当社のリモートハンズサービスにご相談ください。