Siemensが2026年10月30日、産業用エッジ基盤「Industrial Edge Management (IEM)」の管理アプリ7製品に、CVSS 9.8の脆弱性 (CVE-2026-111497) があると公表しました。7製品とも修正版はまだ出ていません。この記事では公表内容を整理したうえで、Siemens Industrial Edgeの脆弱性にいま何をすべきか、そして他社のライブラリを抱えたまま製品や業務システムを納める開発会社は何を見直すべきかを、システム開発会社の代表として考えます。
要点 (事実のみ)
- Siemens ProductCERTは2026年10月30日、アドバイザリ「SSA-443410」を公開した。対象はCVE-2026-111497 (通称Node2Shell)。CVSS v3.1の基本値は9.8、v4.0では9.2。種別はCWE-787 (範囲外書き込み)。
- 脆弱性の本体はSiemensのコードではなく、Googleの圧縮ライブラリ「Brotli」のデコーダにある。Brotli 1.0.3〜1.2.0が対象で、細工した圧縮データにより、認証なしの遠隔攻撃でメモリ内容の漏えい、サービス停止、任意コード実行に至るおそれがあるとされる。Brotli側の修正版は1.0.10、1.1.1、1.2.1。
- 修正版が無いのは、Cloud Connector Configurator、Common Configurator (CC on Edge / CC on IEM)、Data Flow Monitoring、Databus Configurator、Edge OPC UA Server Configurator、Flow Creator Configuratorの7製品 (いずれも全バージョン)。Siemensは製品ごとに「修正版が出るまで停止」または「管理アプリをすべてアンインストールし、IEMをFirewall/WAFで保護」を推奨している。
- 管理アプリを1つも入れていないIEMは対応不要とされる。IEMのソフトウェアにも該当のBrotliは含まれるが、該当機能は使われず、外部にも公開されていないためだ。Siemensが運用するIndustrial Edge HubとIndustrial Edge Management Cloudは、10月28〜29日にサービス側で修正済み。
- Help Net Securityによると、Node.jsは10月21日にこの欠陥を公表した。Brotliへの修正コミットは2026年2月27日に入っていたが、リリースもアドバイザリも無いまま8か月公開状態だった。GitHubには概念実証コードが公開され、CISAは既知の悪用された脆弱性 (KEV) カタログに追加している。
徐 聖博の見解
「入っている」と「攻撃が届く」を分けて答えられるかが、今回の分かれ目だ
今回のアドバイザリで私が一番注目したのは、修正版が無いことよりも、IEM本体には脆弱なBrotliが入っているのに「対応不要」と書かれている点です。入っているが、その機能は使っておらず、外にも出していない。だから影響しない。Help Net Securityの記事でも、Rapid7が「影響を受けるデコーダが存在することと、実際に露出していることは同じではない」と述べています。
これは正しい整理ですが、この線を引けるのは、自社製品のどこで何を展開 (解凍) しているかを把握している作り手だけです。依存ライブラリの一覧を持っているだけでは「入っている」までしか言えません。「攻撃者の送ったデータがそこまで届くか」を答えるには、通信の入口から処理の流れまでを知っている必要があります。Siemensがアプリ単位で「停止」と「アンインストールとFirewall/WAF」を書き分けられたのも、その把握があったからだと私は読んでいます。
修正版が出るまでの「止める」判断は、工場側が決めることになる
もう1つの論点は、推奨策が「停止」や「アンインストール」であることです。設定や監視を担う管理アプリを止めれば、そのアプリに頼っていた業務は止まるか、手作業に戻ります。どのアプリを止めると何が困るのかは、Siemensには分かりません。利用者側が、使っているアプリと外部との接続を洗い出し、止めた場合の影響を見積もって決めるしかありません。
この「誰が止めてよいと判断するか」で手が止まる構図は、先日取り上げた 製造業のOTセキュリティで予算と責任が分断している問題 と同じです。修正版を待つ期間が読めない以上、止める判断の担当者と手順は、脆弱性が出る前に決めておくべきだと考えています。
開発を生業にする会社の事業判断にどう効くか
Brotliの修正コミットが入ってから公表まで8か月、Brotliの修正版が出てからもSiemensの7製品にはまだ修正が届いていません。ライブラリ → 実行環境 → 製品 → 利用企業と、依存が1段深くなるごとに修正が届くのは遅れます。私たちのように、OSSを組み込んだシステムを顧客に納める開発会社は、この連鎖の途中に立っています。
だから、開発会社として次の3つを見直す価値があると考えています。
- 依存の一覧に「どこで外部データを処理するか」を添える。 依存ライブラリの一覧だけでは、今回のIEMのように「入っているが届かない」と顧客に説明できません。圧縮データの展開、画像や文書の解析など、外から来たデータを処理する箇所を設計書に残しておくと、問い合わせに当日中に答えられます。
- 上流の修正が届かない期間の手当てを、保守の作業として見積もる。 今回のように製品ベンダーの修正が遅れるとき、利用企業が頼るのは経路の制限や機能停止です。その判断材料を出す作業は、毎回の臨時対応ではなく、保守契約の定常作業として工数に入れておくほうが顧客にも説明しやすくなります。前回取り上げた EPICS Baseの脆弱性と保守契約の見直し と同じ結論ですが、今回は「修正版が無い期間」がより長く読めない分、重みが増します。
- 自分たちが上流になる場面も想定する。 業務システムや連携アプリを他社に提供している会社は、Siemensと同じ立場にもなります。依存先の修正版が出た日から、自社の修正版と利用者向けの案内を出すまでの日数を、自社で測っておくべきです。そこが短い会社ほど、保守を任せられる会社として選ばれると私は考えています。
まとめ
CVE-2026-111497はBrotliという1つの圧縮ライブラリの欠陥ですが、Siemensの産業用エッジ製品では7製品が修正待ちになっています。IEMを使っている企業は、入れている管理アプリと外部接続を確認し、止めた場合の影響を見たうえで、停止か経路の保護を選ぶ必要があります。開発会社にとっては、「入っているか」ではなく「攻撃が届くか」を答えられる設計情報を、納品と保守の中に持っておくことが今回の教訓だと私は考えています。
関連して読んでいただきたい記事:
- 製造業のOTセキュリティは誰の予算か｜IT・工場の責任分断を「誰が設備を止めてよいか」の権限設計から読む
- EPICS Base 7.0.11の脆弱性4件と、制御系にOSSを組み込む開発会社の備え
- LiteLLM改ざん版1.107.0の攻撃経路と、OSS配布経路のリスク
参考: Brotli bug reaches far beyond Node.js (CVE-2026-111497) (Help Net Security, 2026-10-27)
