MZ Automation lib60870、リモートクラッシュの脆弱性でCISAのサイバーセキュリティ警告に直面

研究者らが、1つの不正なメッセージで脆弱なlib60870の解析プロセスをクラッシュさせられることを発見したことを受け、MZ AutomationはCISAのサイバーセキュリティ警告の対象となった。この脆弱性はバージョン2.4.0までのlib60870に影響し、識別子はCVE-2026-16002である。修正はバージョン2.4.1に含まれている。

このバグは、産業制御環境でIEC 60870-5通信を処理するためのソフトウェアに存在する。こうした通信は、制御センター、変電所、遠隔端末装置、その他の運用技術システムを接続することがある。そのため、パーサーの障害は一般的なアプリケーションクラッシュとは異なる意味を持つ。

中心にあるのは、狭い範囲のコードと広範な運用上の影響との対立だ。問題のデコーダーは特殊な1種類のメッセージを処理するが、影響を受けるライブラリは、エネルギー、化学、水道、下水インフラで使われる通信を支えている。CISAは、この製品が世界中で導入されているとしている。

これは、産業設備の乗っ取りが実証された事例ではない。研究者らが確認したのは境界外読み取りとサービス拒否の結果であり、任意コード実行ではない。ただし、細工されたフレームが公開されたパーサーに到達すれば、ネットワークから到達可能な攻撃者はアカウントもユーザー操作も必要としない。

当面の対応は明確だ。lib60870の導入状況を特定し、影響を受けるメッセージタイプを処理しているか確認し、バージョン2.4.1以降へ更新する。より困難なのは、組み込み済みのコピーをすべて見つけ、気軽な停止を許容できない運用システムを安全に変更することだ。

CISAサイバーセキュリティ勧告が変えたこと

CISAは、運用環境でlib60870を使用する組織にとって、パーサーの欠陥を具体的な資産管理の期限へと変えた。

CISAのサイバーセキュリティ勧告は、MZ Automation lib60870における境界外読み取りを特定している。このメモリ安全性のエラーにより、ソフトウェアはデータバッファの意図された境界を越えて読み取ることができる。

悪用に成功すると、解析プロセスをクラッシュさせ、サービス拒否を引き起こす可能性がある。CISAはバージョン2.4.0までのlib60870を影響対象に挙げ、2.4.1を修正版としている。

この勧告は、この問題をCVE-2026-16002およびCWE-125（境界外読み取りの標準分類）に関連付けている。また、化学、エネルギー、水道、下水事業で世界的に導入されていることにも言及している。

この業種リストは、これらの業界のすべての組織が脆弱なコードを実行していることを意味しない。これは、CISAがこのライブラリを、従来型のサーバーアプリケーションを超える影響を伴う産業制御システム用ソフトウェアとして扱う理由を示している。

ベンダーの詳細なセキュリティ記録では、影響を受けるコンポーネントはCS101 masterとCS104 clientに絞られている。これらのコンポーネントは他のデバイスからメッセージを受信して解析するため、脆弱なコードは受信通信経路上に置かれる。

テストされた脆弱なリリースはバージョン2.4.0で、ソースコミット083dc8eに関連付けられている。開発ブランチも、修正コミット182ed30の前は影響を受けていた。MZ Automationは修正版としてバージョン2.4.1を公開した。

日付は緊急性を理解する助けになる。MZ Automationは2026年7月16日にバージョン2.4.1を発表し、7月17日にGitHubのセキュリティ勧告を公開した。その後、CISAはこの問題を産業向け勧告プロセスに取り込んだ。

現在、公的記録には2つの深刻度指標が示されている。CISAの資料ではCVSS v3スコアは8.2だが、ベンダーのGitHub勧告では「Moderate」ラベル付きで5.3と表示されている。

より低いベンダースコアは、低い複雑性、権限不要、ユーザー操作不要のネットワーク攻撃を記述するベクターを使用している。可用性への影響は低く、機密性または完全性への影響は確認されていないとしている。

組織は、このスコアの違いを、どちらかの記録が必ず誤っている証拠として扱うべきではない。CVSSの結果は、評価者が影響や導入状況について異なる前提を置く場合に変わり得る。産業事業者は、実際の到達可能性、プロセスの重要度、冗長性、復旧時の挙動に基づいて優先度を決めるべきだ。

冗長化されたテストシステム上で自動再起動するパーサーと、単一の本番テレメトリー経路を支えるパーサーでは、運用上の影響が異なる。ソース上の欠陥は同一でも、運用リスクは大きく変化し得る。

したがって、新たに求められることは単に「パッチを適用する」ことではない。チームはソフトウェア識別子を、実際のデバイス、ゲートウェイ、エンジニアリングシステム、アプリケーションに結び付けなければならない。このインベントリ作業が、公開された修正が必要なシステムに届くかどうかを左右することが多い。

1つの不正なフレームがバッファ境界を越える可能性

この脆弱性は、デコーダーが後で消費するデータより少ないデータしか検証しないために存在する。

影響を受けるコードは、S_IT_TC_1とも呼ばれるIEC 60870-5 ASDU TypeID 41を処理する。ASDU（Application Service Data Unit）は、IEC 60870エンドポイント間で構造化された運用情報を運ぶ。

S_IT_TC_1は、タイムタグ付きのセキュリティ統計用積算値を表す。この欠陥は、cs101_information_objects.c内のIntegratedTotalsForSecurityStatisticsデコード経路に存在する。

ベンダーのセキュリティ勧告によると、パーサーの長さチェックは、各要素で想定されるデータの一部しか確認していない。その後、デコーダーはカウンター情報とタイムスタンプを含む、より大きな構造を読み取る。

完全な要素には約14バイトが必要となる。2バイトのAID値、5バイトのバイナリカウンター値、7バイトのCP56Time2aタイムスタンプが含まれる。脆弱な検証ロジックは、主要なサイズチェックで5バイトしか考慮していない。

この不一致は、メッセージが物理的なペイロードより多い要素数を宣言した場合に危険となる。デコーダーは、宣言された数を十分長く信頼するため、提供されたバッファの末尾を越えて進む。

研究者らは、約201バイトの最小化フレームでこの挙動を実証した。そのVariable Structure Qualifierは93個の要素を宣言していたが、フレームに物理的に含まれていたのは約11個だった。

パーサーは次の要素を処理しようとしてオフセット201に到達した。アクセス不能としてマークされたガードページにより、デコーダーがバッファ境界を越えた時点で決定論的な障害が発生した。

この技術的な経路が重要なのは、悪用に長い通信交換や精密にタイミングを合わせた一連の操作を必要としないためだ。勧告によれば、1つの不正なTypeID 41 ASDUで読み取りを引き起こせる。

IEC 60870-5-104は通常、TCPポート2404経由でメッセージを伝送する。基盤となるプロトコルは組み込み認証を提供しないが、導入環境ではトランスポート層およびアプリケーション層のセキュリティ制御を追加できる。

それでも攻撃者は、細工したメッセージをパーサーへ到達させなければならない。一般に、そのためにはネットワーク到達性、中間通信経路へのアクセス、または関連リンクにトラフィックを注入する別の方法が必要となる。

この条件が満たされると、公開されたベクターでは権限もユーザー操作も不要となる。オペレーターがファイルを開いたり、プロンプトを承認したり、インターフェースにログインしたりする必要はない。

影響を受ける経路は、「すべてのlib60870通信」という表現が示唆するより限定的だ。ベンダーによると、S_IT_TC_1セキュリティカウンターオブジェクトを処理するアプリケーションが、実証されたクラッシュにさらされる。

この詳細はテストの指針になるべきだが、特定済みの脆弱バージョンを無視する口実にはならない。組織は、インテグレーター、下流アプリケーション、将来の設定によって有効化されるすべてのメッセージタイプを完全に可視化できていない可能性がある。

この修正は、デコーダーが各要素を読み取る前に、消費するすべてのデータを対象として検証を拡張する。これはネットワークレベルの回避策ではなく、境界不一致に対する直接的な修正だ。

MZ Automationは、より広範なバージョン2.4.1アップデートにこの修正を含めた。このリリースでは、メッセージ長チェック、証明書検証、サーバー通信、その他の安定性に関する問題にも対処している。

このより広いリリース範囲により、回帰テストの必要性が高まる。オペレーターは、すべての場合で単独のソース変更を適用するわけではない。複数のセキュリティ修正および挙動修正を含むパッケージへ移行する可能性がある。

小さなデコーダーバグが大規模な産業システムに圧力をかける

主なリスクは破損したメモリの量ではなく、停止するプロセスが担う運用上の役割にある。

Lib60870は、移植性の高いCコードでIEC 60870-5-101およびIEC 60870-5-104通信を実装している。前者はシリアル遠隔制御リンクをサポートし、後者はTCP/IPネットワークを通じて関連通信を伝送する。

公式リポジトリには、masterおよびslaveのサポート、CS104 clientおよびserver機能、冗長化グループ、ファイルサービスが記載されている。必要な依存関係を用いてビルドした場合は、TLS機能もサポートする。

これらの機能により、このライブラリはテレメトリーおよび制御情報をやり取りするアプリケーション内部に配置される。lib60870は単一の固定された産業用アプライアンスではなく、ソフトウェアコンポーネントであるため、正確な製品アーキテクチャは異なる。

公益事業者は、遠隔局からデータを受信する制御センタークライアントでこれを使用する可能性がある。機器ベンダーはゲートウェイに組み込む可能性がある。インテグレーターは、特化した監視アプリケーションにコンパイルする可能性がある。

この多様性が、最初の実務上の圧力点を生む。セキュリティチームはアプライアンス名を認識していても、そのファームウェアやソフトウェアバンドル内にどの通信ライブラリが含まれているか把握していない場合がある。

ソースを利用する組織は、依存関係の記録、ビルドマニフェスト、コミット履歴を確認できる。商用顧客には、ベンダー文書、ソフトウェア部品表、またはサプライヤーからの直接確認が必要になる場合がある。

第2の圧力点は稼働時間だ。産業通信は、継続的な可視性、アラーム処理、遠隔操作を支えることが多い。1つのプロセスを再起動することは技術的には容易でも、運用上は混乱を招く可能性がある。

実証された影響は、物理的損害そのものではなくクラッシュだ。それでも、通信停止は現在の測定値を見えにくくし、履歴データの収集を中断し、アラームを遅延させ、オペレーターにバックアップ手順を強いる可能性がある。

実際の影響はシステム設計に左右される。冗長化されたクライアント、プロセス監視、ネットワークセグメンテーション、ローカルの自律制御は影響を抑えられる。一方、フラットなネットワークと単一の通信経路は影響を増幅し得る。

第3の圧力点は変更管理だ。運用技術チームは通常、本番導入前に、デバイスの挙動、タイミング、証明書、ベンダー固有の拡張機能に対してプロトコルライブラリの更新をテストする。

この慎重さは可用性を保護するが、露出期間を長引かせる場合もある。組織は、既知の不正フレームによるクラッシュのリスクと、十分にテストされていないライブラリ更新を導入するリスクのバランスを取らなければならない。

CISAの影響対象セクター一覧は、このトレードオフをより明確にする。エネルギーおよび水道の事業者は、一般的なオフィスソフトウェア向けに設計された保守戦略がテレメトリーシステムに適するとは想定できない。

問題はインターネット公開にとどまらない。デバイスは公衆インターネットから保護されていても、侵害されたワークステーション、リモートアクセスサービス、ベンダー接続、隣接する運用ネットワークから到達可能な場合がある。

このため、公開TCPポート2404のエンドポイントだけを探すのでは不十分だ。外部公開は1つの経路にすぎず、攻撃対象領域のすべてではない。

資産レビューでは、完全なデータ経路を追跡すべきだ。チームは、どのシステムがIEC 60870メッセージを受信するか、どのプロセスがそれらを解析するか、どの上流ソースがTypeID 41トラフィックを配信できるかを特定する必要がある。

クラッシュ後に何が起こるかも判断すべきです。監視対象のプロセスは直ちに再起動する場合がありますが、別のサービスは手動介入まで利用不能なままとなる可能性があります。

同じトラフィックが再起動後のプロセスに到達し続ける場合、悪意あるフレームの繰り返しにより自動復旧が無効化されるおそれがあります。そのため、ネットワーク・フィルタリングとプロセス監視はパッチを補完するものではあっても、代替するものではありません。

実用的な運用テストでは、影響を受けるクライアントの喪失が制御能力、監視機能のみ、あるいはその両方にどのような影響を与えるかを確認します。この区別は、インシデントの重大度、保守スケジュール、一時的な代替統制の判断に役立ちます。

真のトレードオフは迅速なパッチ適用と安全な変更の間にある

Version 2.4.1は既知のデコード上の欠陥を解消しますが、産業事業者には依然として統制された展開と多層的な封じ込めが必要です。

最も明確な対策は、影響を受けるアプリケーションをlib60870 2.4.1以降へアップグレードすることです。MZ Automationは、S_IT_TC_1情報オブジェクトを使用するアプリケーションに対し、特にこの対応を推奨しています。

組織はまず、lib60870を含むシステムのインベントリを作成すべきです。有用な証拠には、ソースのロックファイル、ビルド記録、ファームウェア・マニフェスト、サプライヤーの証明、パッケージ・メタデータ、契約上許可される場合のバイナリ解析などがあります。

チームは、ライブラリのバージョンとアプリケーションの役割の両方を記録すべきです。メッセージを受信する脆弱なCS104クライアントは、ライブラリを含んでいても影響を受けるコンポーネントを呼び出さないソフトウェアとは異なるリスク経路を示します。

次に、到達可能性をマッピングする必要があります。関連する確認事項には、エンドポイントが信頼できないネットワーク、ルーティングされた企業ネットワーク・セグメント、保守用ノートPC、ジャンプホスト、またはサードパーティーのリモートサービスからのトラフィックを受け入れるかどうかが含まれます。

修正は、本番環境の前に代表的なテスト環境で適用すべきです。テストでは、通常のテレメトリ、不正な入力の処理、フェイルオーバー、再接続時の挙動、証明書検証、ベンダー固有のメッセージ組み合わせを確認する必要があります。

Version 2.4.1には、CVE-2026-16002以外にも複数の変更が含まれています。MZ Automationによれば、メッセージ長の検証を追加し、他のセキュリティおよび安定性上の欠陥も修正しています。これらの変更はアップグレードの必要性を強める一方、回帰テストの対象範囲も広げます。

即時展開が不可能な場合、ネットワーク制御によって露出を減らせます。事業者は、既知の通信エンドポイントにアクセスを限定し、IEC 60870セグメントへの不要な経路を遮断できます。

仮想プライベートネットワークはリモートアクセスを保護できますが、信頼された経路内のすべてのデバイスを安全にするわけではありません。盗まれた認証情報や侵害された認可済みホストでも、ネットワークへの到達可能性が提供される可能性があります。

プロトコルを認識する監視は、異常なTypeID 41トラフィック、一貫しない要素数、接続失敗の繰り返し、プロセス再起動の特定に役立つ可能性があります。事業者は、監視デバイスが関連するプロトコルの変種を正しく解析することを検証すべきです。

エンドポイント監視は、障害が発生したサービスを再起動することで停止時間を短縮できます。ただし、再起動イベントがアラートを生成せず、有用なログを保持しない場合、繰り返される悪用を隠してしまう可能性もあります。

S_IT_TC_1メッセージの一時的なフィルタリングには、慎重なエンジニアリングレビューが必要です。正当なセキュリティカウンター・オブジェクトをブロックすると、期待される監視動作が変化する可能性があり、安易に採用すべきではありません。

CISAのサイバーセキュリティ対応では、証拠も保存すべきです。関連する記録には、パケットキャプチャ、プロセスのクラッシュダンプ、再起動ログ、アプリケーションメッセージ、影響を受けるエンドポイント周辺の設定変更が含まれます。

これらの成果物は、悪用と、不具合のあるピア、破損したトラフィック、無関係なアプリケーション障害とを区別する助けになります。同じ不正な構造は、意図的にも偶発的にも生成され得ます。

優先順位付けでは、重大度評価の相違を慎重に扱う必要があります。CISAの8.2という評価は高い懸念を示す一方、ベンダーの5.3という計算は、実証されたセキュリティ影響が限定的であることを反映しています。

いずれの数値も、それだけで特定のプラントや制御センターを説明するものではありません。ローカルのリスク評価では、露出度、運用上の依存関係、再起動時の挙動、冗長性、可視性喪失による安全上の影響を考慮すべきです。

チームは、この問題を過大に表現することも避けるべきです。公開アドバイザリーが報告しているのは境界外読み取りであり、書き込みではありません。研究者は任意コード実行を実証していません。

ベンダーは、メモリレイアウトやデコードされた値がピアに返されるかどうかに応じて、特定の条件下で隣接するヒープデータが露出する可能性があると指摘しています。この可能性は、実用的な情報開示エクスプロイトとして確立されていません。

同様に、公開の概念実証は利用できません。アドバイザリーはトリガーと実験結果を説明していますが、組織は別個の証拠なしに広範な実際の悪用を想定すべきではありません。

したがって、規律ある対応は軽視と警戒の間に位置します。確認済みの欠陥にパッチを適用し、展開中は到達可能性を減らし、説明された障害パターンを監視してください。

この発見が産業ソフトウェアのテストについて示すこと

CVE-2026-16002は、現代のファジングが長期間運用されてきた産業プロトコル実装内の限定的なメモリ欠陥を見つけられることを示しています。

ベンダーのアドバイザリーによると、この問題はEldprovと呼ばれるオープンソースのLLM支援ツールが、AddressSanitizerとともにAFL++またはlibFuzzerを使用して発見しました。ファジングは、異常な入力をソフトウェアに与え、クラッシュや誤った前提を露出させます。

Automationが候補となる障害を特定しましたが、その後に人間が再現して検証しました。研究者は結果を報告する前に、ガードページ・ハーネスを使用し、関連するソースパスをレビューしました。

この一連の流れは重要です。自動生成された脆弱性報告には、偽陽性や十分に特性評価されていないクラッシュが含まれることがあるためです。今回、公開記録は決定論的な再現と、特定の境界チェック上の誤りを説明しています。

この発見は、過去の産業セキュリティ研究との有用な比較も提供します。以前のlib60870関連アドバイザリーにはメッセージ処理やサービス拒否状態が含まれており、パーサーの堅牢性が継続的な懸念であることを示しています。

プロトコルライブラリは難しい入力空間に直面します。フレームはある層では有効でも、別の層では矛盾するカウント、長さ、フラグ、オブジェクト型を含むことがあります。

通常のデバイス通信をテストするだけでは、すべての不正な組み合わせを網羅することはほとんどありません。ファジングは、特に無効なメモリアクセスを検出するサニタイザーと組み合わせることで、こうした組み合わせをより迅速に探索できます。

人間の役割は依然として中心的です。事業者が対処できるようになる前に、クラッシュは最小化、追跡、再現され、現実的な露出と結び付けられなければなりません。

この発見は、プロトコルのセキュリティと実装のセキュリティも分けて考えます。暗号化、認証、セグメンテーションは誰がトラフィックを送信できるかを制限できますが、受信側のパーサーは依然として不正なデータを安全に処理しなければなりません。

MZ Automationは、IEC 60870-5-101およびIEC 60870-5-104を、ネイティブの暗号化、認証、完全性保護なしに作られたプロトコルとして説明するガイダンスを公開しています。同社のIEC security overviewでは、展開に重ねて適用できるTLSおよびIEC 62351の保護について説明しています。

これらの制御は、正しく実装されれば不正アクセスを減らします。ただし、メモリを読み取る前にすべてのフィールドを検証するというデコーダーの責務を免除するものではありません。

逆に、修正済みのパーサーは弱いネットワーク信頼を解決しません。Version 2.4.1はこの既知の読み取り経路を防ぎますが、レガシープロトコルを完全なセキュリティ境界へと変えるものではありません。

これがインシデントの背後にある核心的なトレードオフです。産業事業者には、何年も展開されたままの可能性がある機器との互換性を維持しつつ、より安全なコードとより狭い通信経路の両方が必要です。

サプライヤーは、機械可読な依存関係情報、サポート対象のアップグレード経路、影響を受けるコンポーネントに関する明確な説明を公開することで、このバランスを改善できます。そうすれば事業者は、展開済みのすべてのバイナリをリバースエンジニアリングせずに露出を特定できます。

このライブラリのオープンソース・ミラーは、研究者がコードを調査し、ソース利用者がコミットを比較するのに役立ちます。ただし、ライブラリを組み込んだ商用製品では、顧客が直接再ビルドできない場合、依然としてサプライヤーとの連携が必要です。

次のテスト上の問いは、他のASDUデコーダーにも同様の部分的な長さチェックが存在するかどうかです。Version 2.4.1はより広範なメッセージ長検証を追加しており、このリリースが孤立した1行以上の問題に対処していることを示唆しています。

これは、追加の悪用可能な脆弱性が存在することを立証するものではありません。しかし、可変カウント、任意のアドレス、カウンター、タイムスタンプを組み合わせるデコード経路を重点的にレビューする理由にはなります。

セキュリティチームは、下流ベンダーが独自の通知を公開するかどうかも追跡すべきです。ライブラリの修正は、保守担当者が更新済みソフトウェアを再ビルド、テスト、配布するまで組み込み製品には届きません。

3つのシグナルがリスク封じ込めの成否を示す

次の段階は、パッチの採用、下流での開示、実環境における悪用の証拠に左右されます。

最初のシグナルは、実際の運用製品にVersion 2.4.1が現れることです。ライブラリのリリースは修正プロセスを開始しますが、インテグレーターが修正済みのアプリケーションやファームウェアを出荷したことを証明するものではありません。

事業者はサプライヤーに対し、自社製品にlib60870-Cが含まれるか、使用しているバージョンは何か、影響を受けるデコーダーに到達可能かを確認すべきです。回答では、修正済みリリースとサポートされる展開手順を明示すべきです。

下流アドバイザリーが強く広がれば、ベンダーが自社ポートフォリオ全体で依存関係を追跡したことが確認されます。沈黙は製品が影響を受けないことを意味するかもしれませんが、不完全なインベントリを反映している可能性もあります。

2つ目のシグナルは、アップグレードによる運用上の証拠です。組織は、2.4.1へ移行した後の相互運用性の問題、証明書動作の変化、再接続の問題、一般的でないASDUの予期しない処理を監視すべきです。

問題のない展開は、より大規模なフリート全体での迅速な採用を後押しします。重大な回帰が生じればパッチ適用は遅れ、セグメンテーション、許可リスト、監視への依存が高まります。

3つ目のシグナルは、攻撃者が制御されたテストの外でCVE-2026-16002を使用している証拠です。公開エクスプロイトコード、インシデント報告、不正なTypeID 41トラフィックの繰り返し、カタログ上のエスカレーションはいずれも緊急性を高めます。

公開されたアドバイザリーの詳細時点では、実証された結果は実験室条件下でのパーサークラッシュです。公開記録は、任意コード実行や広範な悪用を立証していません。

組織は見出しを待つのではなく、CISAの更新、サプライヤーの通知、自社の運用テレメトリを監視すべきです。境界デバイスに公的な露出が示されていない場合でも、IEC 60870クライアントで繰り返されるプロセス障害は調査に値します。

最も有用な直近の対応は、対象を絞ったインベントリレビューです。IEC 60870-5メッセージを受信するすべてのシステムを見つけ、lib60870のバージョンを特定し、そのパーサーに到達できる主体を文書化してください。

次に、代表的なトラフィックと障害シナリオに対してVersion 2.4.1をテストします。迅速な更新が不可能な場合は、通信経路を制限し、パーサーの再起動や不正なTypeID 41メッセージに対してアラートを設定してください。

このアプローチは、証拠を誇張せずに対応するものです。CISAのサイバーセキュリティ警告は、影響を受ける構成において、リモートから到達可能な確認済みのサービス拒否状態を説明しています。

未解決の問いは、欠陥のある境界チェックが存在するかどうかではありません。それを含む本番システムがどれだけあるのか、それらのシステムにどの程度到達可能なのか、そして所有者がどれほど迅速に安全な修正を展開できるのかです。