MZ Automation libIEC61850、CISAのサイバーセキュリティ指針を試す

MZ Automationは、4件の脆弱性によって産業ネットワーク向けCISAサイバーセキュリティ指針の深刻な矛盾が浮き彫りになったことを受け、libIEC61850 1.6.2をリリースした。脆弱性はバージョン1.0.0から1.6.1に影響し、電力系統に不可欠な通信を処理するサービスをクラッシュさせる可能性がある。特定のメモリ構成では、任意のコード実行を可能にする脆弱性も1件含まれる。

CISAは2026年7月23日、産業用制御システムに関するアドバイザリーを公表した。同機関は、認証されていないネットワーク隣接の攻撃者が、保護、可視化、制御の各機能を妨害または侵害できる可能性があると説明した。こうした影響を踏まえると、これは通常のオープンソースのパッチ適用サイクルにとどまる問題ではない。

主要な矛盾は明確だ。運用者は、変電所などの重要環境で標準化された相互運用可能な通信に依存している。一方で、その接続性は、侵害されたシステムや未承認のシステムからのトラフィックに複雑なメッセージパーサーをさらすことにもなる。

MZ Automationはアドバイザリー公表と同日にバージョン1.6.2をリリースした。この更新には該当する脆弱性の修正が含まれるが、運用技術環境でライブラリを更新することは、めったに一段階で完了しない。資産の把握、ベンダーによる検証、互換性テスト、保守スケジュールの調整により、露出期間が長引く可能性がある。

CISAサイバーセキュリティアドバイザリー、4つの攻撃経路を特定

脆弱なパーサーは保護・制御ワークフローを支えるソフトウェア内に存在するため、アドバイザリーは不正なプロトコルトラフィックを運用上の懸念事項へと変える。

影響を受けるコンポーネントは、MZ Automationが提供するIEC 61850通信サービスのC言語実装、libIEC61850だ。IEC 61850は、電力自動化システム内でデータを交換するために用いられる標準規格群である。一般に、変電所の監視、保護協調、イベント報告、設備制御を支援する。

産業向けアドバイザリーは、バージョン1.0.0から1.6.1を対象としている。導入環境は、重要製造業、エネルギー、輸送システムを含む世界各地に及ぶとみられる。MZ Automationはドイツに拠点を置く。

開示の中心となるCVEは4件ある。

• CVE-2026-49035は、細工されたMMS Initiateリクエストによって引き起こされるヒープベースのバッファオーバーフローを扱う。MMS（Manufacturing Message Specification）は、産業用デバイスとアプリケーション間の構造化されたクライアント・サーバー通信を担う。

• CVE-2026-50039は、MMS ReadRequestを通じて到達可能なスタックベースのバッファオーバーフローを扱う。不正なリクエストはメモリを破損させ、影響を受けるプロセスをクラッシュさせる可能性がある。

• CVE-2026-50103は、共有のGOOSEおよびR-GOOSEパーサーにおける無効な構造の処理を扱う。細工されたフレームにより、購読側アプリケーションがクラッシュする可能性がある。

• CVE-2026-50032は、MMS Write Named Variable ListハンドラーのNULLポインターデリファレンスを扱う。空のlistOfDataフィールドにより、サーバーが停止する可能性がある。

GOOSEはGeneric Object Oriented Substation Eventの略である。保護・制御に関連する状態変化を含む、時間に敏感なイベントを配信する。R-GOOSEは、ローカルEthernetセグメントを超えたルーティング可能な配信を提供する。

文書化されたシナリオでは、3件の脆弱性は主に可用性を脅かす。CVE-2026-49035は、Address Space Layout Randomization（ASLR）が無効な場合に研究者がリモートコード実行を実証しているため、より広範な影響を持つ。

ASLRは、信頼性の高いコード実行を困難にするため、メモリ上の配置をランダム化する。その有無は根本的な脆弱性を解消するものではない。CVEレコードによれば、ASLRが有効な構成でもメモリ破損やサービス拒否が発生する可能性がある。

CVE-2026-49035にはCVSS 3.1で8.1、CVSS 4.0で9.2のスコアが付与された。より新しいフレームワークではクリティカルと評価されている。CVSS 3.1では攻撃の複雑性は高く、コード実行の成功は特定のメモリ保護条件に依存する。

残るスコアは、異なるクラッシュ経路を示している。CVE-2026-50039とCVE-2026-50032には、それぞれCVSS 3.1で7.5が付与された。CVE-2026-50103は、攻撃ベクターが広範なネットワーク到達性ではなく隣接性であるため、CVSS 3.1で6.5となった。

これらのスコアはトリアージに役立つが、すべての運用上の影響を測定するものではない。テスト環境での短時間の中断と、稼働中の変電所ゲートウェイで同じ中断が起きる場合とでは、大きな差がある。実際の影響は、アーキテクチャ、冗長性、プロセス監視、復旧手順によって左右される。

今回の開示は、攻撃者がこれらの脆弱性を運用環境で悪用したとは述べていない。公開済みCVEレコードに対するCISAの拡充情報では、悪用は「なし」とされている。この区別は重要である。技術的な悪用可能性と、実際に確認された悪意ある利用は別の問題だからだ。

それでも、既知の悪用がないことは、修正を遅らせても無害であることを意味しない。脆弱性の詳細はすでに公開され、影響を受けるバージョン範囲も判明しており、修正内容も調査できる。防御側は、開示後に攻撃者の理解が深まると想定すべきだ。

libIEC61850サービスが特異な運用上の重要性を持つ理由

影響を受けるプロセスが運用者や保護システムに適時かつ信頼できる情報を提供している場合、パーサーのクラッシュはより重大な意味を持つ。

libIEC61850は、組み込みシステムおよび一般的なコンピューター向けに、MMS、GOOSE、Sampled Valuesなどのサービスを実装している。MZ Automationによると、このライブラリは商用ソフトウェアやデバイスに組み込まれているが、完全な導入一覧は公開していない。

プロジェクトのライブラリドキュメントでは、クライアント、サーバー、レポーティング、データアクセス、制御モデル、ロギング、データ探索のサポートが説明されている。Linux、Windows、macOSで動作し、組み込みプラットフォーム間での移植性を考慮して設計されている。

この柔軟性が、露出状況の評価を複雑にする。一部の組織は、ライブラリを社内アプリケーションへ直接コンパイルしている。別の組織は、機器、ゲートウェイ、シミュレーター、監視制御ソフトウェアに含まれる推移的なコンポーネントとして受け取っている。

そのため、運用者は製品インターフェースにその名称が表示されないままlibIEC61850を使用している可能性がある。デバイスベンダーがフォークを維持していたり、古いリリースに固定していたりする場合もある。標準的なソフトウェア資産管理ツールでは、このような静的リンクされたコンポーネントを見落とすおそれがある。

攻撃経路は複数の信頼境界もまたぐ。MMSサーバーは、ネットワークレベルでは認可されているように見えるクライアントからリクエストを受け取ることがある。クライアントは、侵害またはなりすましを受けたサーバーからの応答を処理する可能性がある。

GOOSEトラフィックは別のパターンを示す。多くの場合、メッセージはローカルEthernetドメイン内で移動するレイヤー2で運用される。ネットワーク隣接性は攻撃者の出発地点を狭めるが、信頼性を保証するものではない。

攻撃者は、侵害されたエンジニアリングワークステーション、保守用ノートPC、スイッチポート、リモートアクセス経路、または別の産業用デバイスを通じて、その位置を得る可能性がある。仮想ネットワークの設定ミスにより、予期しないシステムが信頼されたブロードキャストドメイン内に配置されることもある。

CVE-2026-50103は、セグメンテーションだけではコンテンツを検証できない理由を示している。脆弱なパーサーは、細工されたGOOSEフレーム内の不正なtype-length-valueフィールド、すなわちTLVに遭遇する可能性がある。想定されたプロトコルトラフィックを許可するファイアウォールでも、悪意あるメッセージを通過させる場合がある。

想定される影響は、単一プロセスの停止にとどまらない。IEC 61850アプリケーションは、測定値、アラーム、イベント記録、設備状態、制御アクセスを提供し得る。物理設備が稼働を続けていても、1つのサービスを失えば運用上の可視性が低下する可能性がある。

クラッシュは、自動再起動、フェイルオーバー、縮退モードを引き起こす場合もある。こうした制御がリスクを低減するのは、組織が繰り返される不正トラフィックに対して検証済みである場合に限られる。攻撃者は、再起動のたびにトリガーとなる入力を再送できる可能性がある。

任意のコード実行は、異なる懸念を生む。脆弱な構成でCVE-2026-49035の悪用に成功した場合、攻撃者はサービス中断を超えた行動に移れる。コード実行により、プロセスの改変、データの調査、またはその権限境界内での永続化が行われる可能性がある。

このCVEは、影響を受けるすべての導入環境で信頼性の高いコード実行が可能であることを証明するものではない。ASLRの状態、コンパイラー保護、OSの挙動、アーキテクチャ、アプリケーション設計はいずれも重要である。防御側は、デフォルト設定から安全性を推測するのではなく、これらの制御を検証すべきだ。

これがアドバイザリーによって生じる核心的な圧力である。資産所有者は、目に見える導入環境と組み込みコピーの両方を特定しなければならない。機器ベンダーは、自社製品に影響を受けるコードが組み込まれているかを判断し、検証済みの更新を提供する必要がある。

インテグレーターも同様の圧力に直面する。古いインターフェースを前提にカスタムソフトウェアを構築していたり、特定のリリース向けに静的データモデルを生成していたりする可能性がある。ライブラリの置き換えには、再ビルド、回帰テスト、デバイス間相互運用性の再検証が必要になる場合がある。

接続性とメモリ安全性が主なトレードオフ

IEC 61850の相互運用性は運用上の価値をもたらす一方、受け入れるすべてのメッセージは、メモリ安全ではないCのパースロジックへの入力にもなる。

これは本記事の中心的なトレードオフだ。産業通信は、共有フォーマットと予測可能なサービスに依存している。しかしパーサーは、別のエンドポイントが提供するあらゆる長さ、フィールド、ネスト構造、任意値を処理しなければならない。

libIEC61850はC99標準に基づくCで記述されている。Cは移植性とメモリに対するきめ細かな制御を提供し、組み込み環境やリアルタイム環境に適している。一方で、境界、ポインター、割り当てサイズ、オブジェクトのライフタイムを検証する大きな責任を開発者に負わせる。

4件の脆弱性は、この経路における異なる失敗を示している。ヒープオーバーフローは動的に割り当てられたメモリの範囲外に書き込む。スタックオーバーフローは固定サイズのローカルバッファを超過する。NULLポインターデリファレンスは無効なポインターを使用し、一般にプロセスを停止させる。

無効な構造の不適切な処理も、不正な構文を通じて同じ運用上の結果に至る。パーサーはメッセージの一部を受け入れて危険な状態に入り、予期しないフィールドを処理する過程でクラッシュする。

CVE-2026-49035は、最も広範な技術的影響を持つ。ヒープオーバーフローのレコードでは、細工されたMMS Initiateリクエストが説明されている。このリクエストは、エンドポイント間でMMSアソシエーションを確立する初期段階に現れる。

この位置づけは重要である。攻撃者は、脆弱なコードを標的にする前に専門的な業務機能へ到達する必要がない。攻撃は、プロトコルスタックが通信を確立・交渉する過程で発生する。

CVEでは、必要な権限もユーザー操作もないとされている。また、ベクターはネットワークベースと説明される。ただし、攻撃の複雑性が高いこととASLRの条件により、実証されたリモートコード実行経路には制約がある。

CVE-2026-50039は、より直接的な可用性への影響というパターンをたどる。スタックオーバーフローのレコードは、メモリ破損をMMS ReadRequestに関連付けている。CVSSでは、攻撃の複雑性は低く、必要な権限およびユーザー操作はいずれもなしとされている。

CVE-2026-50032は、Write Named Variable Listハンドラーを標的とする。空のlistOfDataフィールドを含むWriteRequestは、NULLポインターデリファレンスに到達する。この状態は、有効なアプリケーションデータを必要とせずにサーバーをクラッシュさせる可能性がある。

認証済みのアプリケーション操作と、受け入れられるプロトコルトラフィックの違いがここでは重要となる。リクエストは、正当な運用コマンドを表していなくても、ハンドラーに到達するほどには構文的に認識可能であり得る。パーサーのセキュリティは、業務上の認可に先行しなければならない。

CVE-2026-50103は別の通信経路に存在します。このGOOSEパーサーの欠陥には隣接ネットワークからのアクセスが必要ですが、GOOSEメッセージは迅速な運用シグナリングを支えることがよくあります。この問題により、上位レベルの検証でワークフローが保護される前に、購読側アプリケーションがクラッシュする可能性があります。

これらは異なる識別子を持つ同一の4つのバグではありません。広範なプロトコル実装を通る別々の経路が、悪意ある入力によってどのように破綻し得るかを示しています。MMSのアソシエーション、読み取り、書き込み、GOOSEサブスクリプションは、それぞれ異なるパーサーの攻撃対象領域を露出させます。

この広がりを踏まえてテストを設計すべきです。ある入力検証が1つ修正されたことを確認しても、隣接するハンドラーが安全であることは証明されません。ベンダーには、ファジング、サニタイザー支援テスト、不正メッセージのテストスイート、およびプロトコルサービス全体にわたる回帰テストが必要です。

ファジングは、クラッシュや安全でない挙動を発見するため、自動生成した入力をソフトウェアに与える手法です。AddressSanitizerはテスト中のメモリエラーを検出します。いずれも慎重なレビューの代替ではありませんが、組み合わせることで、リリース前にエッジケースを露呈させることができます。

産業事業者がこの開発作業を自ら実施することはできません。サプライヤーに対し、より明確なコンポーネントインベントリ、セキュリティアドバイザリー、サポート期限、検証の証拠を求めることは可能です。調達文言では、組み込みプロトコルライブラリを保守対象の依存関係として扱うべきです。

オープンソースは、コード、コミット、リリース履歴を公開することでこのプロセスを支援します。しかし、更新が導入済みの機器に自動的に届くわけではありません。公開された修正と、その修正を含むすべての導入済み製品との間には、依然として運用上の隔たりがあります。

バージョン1.6.2はコードを修正するが、導入上の隔たりは埋めない

MZ Automationは直接的な修正策を提供したものの、各事業者は依然として脆弱なコードがどこに存在するか、また更新が安全に機能するかを証明する必要があります。

MZ Automationは最新ビルドへの更新を推奨しています。同プロジェクトは2026年7月23日、1.6系向けの脆弱性およびバグ修正を含むlibIEC61850 1.6.2をリリースしました。

バージョン1.6.2のリリースでは、修正された複数のパーサーおよびメモリ安全性に関する問題が示されています。これには、NULLポインター参照、境界外読み取り、スタックオーバーフロー、不正なfree、異常メッセージによるクラッシュが含まれます。

リリースノートには機能変更も含まれています。TLS統合が更新され、実行時のTLS設定変更が可能になり、GOOSEパブリッシングには新しい制御機能が追加されました。したがって、事業者はセキュリティ修正と併せて機能動作もテストすべきです。

すでに1.6系を利用している導入環境では、1.6.1から1.6.2への移行が直接的な経路となるはずです。より古い導入環境では、互換性に関する問題がより複雑になる可能性があります。

1.6系では、以前のバージョンと比べて配列処理とデータモデルが変更されました。MZ Automationのリリース履歴によると、1.6より前のリリースから移行する場合、静的モデルコードの再生成が必要です。動的モデル生成でも、新しい配列表現を考慮する必要があります。

この注意は、軽率な結論を避けるべきことを示しています。修正は存在しますが、長期間更新されていない導入環境が、エンジニアリング作業なしに常にバージョンを飛び越えて更新できるわけではありません。アプリケーションは、古いAPI、生成済みモデル、パッチ、またはベンダー固有のラッパーに依存している可能性があります。

デバイス所有者は、ライブラリを独自に更新できない場合もあります。libIEC61850が署名付きファームウェアに組み込まれている場合、サポート対象のパッケージを発行できるのは機器ベンダーだけです。アップストリームのビルドを導入すると、サポートが無効になったり、未テストの構成になったりする可能性があります。

責任ある対応はインベントリから始まります。チームは、ソースリポジトリ、ビルドマニフェスト、ソフトウェア部品表、ファームウェア記録、バイナリ文字列、パッケージメタデータ、ベンダーの証明を調査すべきです。ライブラリのバージョンと有効化されているサービスの両方を記録する必要があります。

サービスの公開状況は優先順位付けに影響します。脆弱なMMSサーバーを使用するアプリケーションは、読み取り、書き込み、アソシエーションの各経路について緊急のレビューが必要です。GOOSEサブスクライバーは、異常フレームの問題を追加します。無効化されたサービスは露出を減らせますが、チームはコンパイル時および実行時の構成を検証しなければなりません。

次に、アーキテクチャの検証が必要です。チームは、影響を受けるプロセスに到達できるすべてのシステムをマッピングすべきです。このリストには、ローカルピア、踏み台ホスト、エンジニアリングワークステーション、リモートアクセスゲートウェイ、テストツール、Layer 2接続を共有するシステムが含まれます。

その後、事業者は代表的な環境でバージョン1.6.2をテストすべきです。テストには、通常の読み取りおよび書き込み操作、レポーティング、アソシエーション処理、GOOSEトラフィック、フェイルオーバー、ログ、タイミング、異常トラフィック後の復旧を含める必要があります。

メモリ防御には明示的な確認が必要です。チームは、影響を受けるプロセスとプラットフォームでASLRが有効かどうかを確認すべきです。また、実行不可メモリ、スタック保護、コンパイラのハードニング、プロセス権限、サービス監視も確認する必要があります。

これらの制御はパッチ適用の代替ではありません。更新までの期間に悪用可能性を下げたり、影響を限定したりできます。その価値は、プラットフォームの名目上の機能ではなく、実際の導入設定に依存します。

直ちにパッチを適用できない組織は、露出を絞り込むべきです。CISAは、ネットワークアクセスの最小化、制御システムの業務ネットワークからの分離、リモートアクセスに安全な手段を使うことを推奨しています。これらの対策には、インターネット境界だけでなく、ローカルの産業ネットワークも含める必要があります。

監視も役立ちます。チームは、異常なアソシエーション試行、予期しないMMSリクエスト、不審なGOOSE送信元、繰り返されるプロセス再起動、クラッシュダンプ、サービス監視機能の活動を確認できます。ベースラインでは、保守ツールと説明不能なピアを区別すべきです。

CISAのサイバーセキュリティガイダンスが立証していないこと

このアドバイザリーは信頼できる技術的リスクを示していますが、広範な悪用、普遍的なコード実行、あるいは導入環境全体で同一の影響を示すものではありません。

セキュリティ報道では、脆弱性が取り得る最も深刻な結果へと簡略化されることがあります。ここでは、重要インフラを対象とした認証不要の任意コード実行がそれに当たります。しかし、根拠となる証拠はより正確に位置付ける必要があります。

実証されたリモートコード実行を記録しているのはCVE-2026-49035だけです。この結果は、ASLRが無効な場合に適用されます。ASLRが有効な場合、記録されているのはメモリ破壊またはサービス拒否であり、確認済みで信頼性の高いコード実行ではありません。

ほかの3件のCVEは主にクラッシュを説明しています。特に可視性や制御が失われる場合、産業環境ではクラッシュも重大になり得ます。追加の証拠なしにコード実行として報告すべきではありません。

ネットワーク到達可能性も異なります。CVE-2026-50103はLayer 2のGOOSEまたはR-GOOSE解析を標的とするため、隣接する位置を必要とします。MMSの脆弱性はネットワーク攻撃ベクトルを利用しますが、特定の導入環境に誰が到達できるかは、依然としてファイアウォールとルーティングによって決まります。

「認証不要」という言葉にも同様の注意が必要です。これは、スコアリングモデル上、脆弱な経路でアプリケーション権限を必要としないことを意味します。影響を受けるすべてのサービスがインターネット上の誰にでも公開されていることを意味するわけではありません。

CISAは、製品が3つの重要インフラ分野で世界中に導入されていると述べています。この記述は幅広い関連性を示すものであり、脆弱なデバイス数を示すものではありません。CISAもMZ Automationも、包括的な導入ベースを公表していません。

影響を受ける範囲についても、慎重に読む必要があります。バージョン1.0.0から1.6.1が影響を受けるものとして記載されています。ベンダーが修正をバックポートしたり、カスタマイズしたブランチを保守したりする可能性があるため、バージョン番号だけではコードを含むすべての製品を特定できません。

逆に、製品のバージョンラベルが影響を受ける依存関係を隠していることもあります。機器ファームウェアは、古いlibIEC61850リリースを組み込みつつ、独自のバージョン番号を使用する場合があります。事業者にはサプライヤーの確認または技術的な調査が必要です。

CISAの評価では、公表後に利用可能となったCVEエンリッチメントにおいて、既知の悪用はないとされています。これは安心材料ですが、悪用が一切起きていないことの証明ではありません。特に短時間のプロセスクラッシュについては、産業ネットワーク内での検出が不完全なことがよくあります。

公開後には、公開された概念実証の状況も変わり得ます。この開示は、特定のハンドラーとメッセージタイプに研究を集中させるのに十分な技術的方向性を示しています。防御側は、新たなエクスプロイトコードを注視しつつ、それが現れるまで対応を遅らせるべきではありません。

もう1つの不確実性は復旧に関するものです。一部の導入環境では、クラッシュ後に自動的に再起動する可能性があります。ほかでは手動介入が必要になったり、一時データが失われたりする可能性があります。組織は、アプリケーション全体とその監視システムをテストせずに回復力を推測することはできません。

冗長性も精査が必要です。同じ脆弱なパーサーを実行する2台の冗長サーバーは、同一の悪意ある入力によって障害を起こす可能性があります。同じソフトウェア欠陥を共有し、同じトラフィックを受け取る場合、重複コンポーネントは独立性をもたらしません。

正しい解釈は、無関心と警戒の間にあります。世界規模の運用キャンペーンを示す公開された証拠はありません。一方で、影響を受けるバージョンでは、異常メッセージが安全でないメモリ処理経路に到達し得るという明確な証拠があります。

この証拠は迅速な修正対応を正当化します。また、文書化された条件と最悪ケースの想定を区別する、慎重な報道を裏付けます。事業者は、この作業をほかの安全性および可用性に関する義務と並行して優先順位付けする必要があるため、信頼性は重要です。

リスクが封じ込められているかを示す3つのシグナル

次の段階は、サプライヤーの対応、検証済みの露出状況、そして攻撃者が開示から悪用へ移行していることを示す証拠に左右されます。

最初のシグナルは、下流ベンダーの対応です。機器およびソフトウェアのサプライヤーは、影響を受ける製品を特定し、修正版を公開し、脆弱なMMSまたはGOOSE機能を使用しているかを説明すべきです。

明確なアドバイザリーは、このエコシステムがこの露出を迅速に解消できるという見方を強めます。沈黙、不完全なインベントリ、長期化するファームウェア提供の遅延は、導入上の隔たりがソースコードの修正より依然として大きいことを示すでしょう。

2つ目のシグナルは、事業者によるバージョン1.6.2の検証です。資産所有者は、特定済みの導入環境のうち、パッチ適用済み、隔離済み、またはベンダー承認済みの代替的統制で保護されているものがどれだけあるかを追跡すべきです。

実際の保護および監視ワークフロー全体にわたる回帰テストの成功は、迅速な導入を後押しします。互換性の失敗や文書化されていない組み込みコピーは、短期的な修正対応への信頼を弱めるでしょう。

3つ目のシグナルは、悪用の証拠です。CISAのKnown Exploited Vulnerabilitiesカタログ、ベンダーのインシデント報告、セキュリティ研究者、産業監視チームは、これらのCVEが活発なキャンペーンに移行するかどうかを明らかにできます。

ASLRが有効なシステムに対する検証済みのエクスプロイトは、文書化された実証を超えてリスクを大きく高めます。コード実行がなくても、公開されたMMSサービスに対する繰り返しのクラッシュ試行は、緊急性を高めるでしょう。

現時点では、チームは対応前にこれらのシグナルを待つべきではありません。影響を受けるアプリケーションを特定し、到達可能なプロトコル経路を確認し、メモリ保護を検証し、現行リリースをテストすべきです。

実務上の問いは、CVSSスコアが深刻に聞こえるかどうかではありません。異常メッセージが、重要なワークフローを支える脆弱なプロセスに到達できるかどうかです。それには、各組織のアーキテクチャから得られる証拠が必要です。

CISAのサイバーセキュリティアドバイザリーを、調査の終わりではなく始まりとして扱ってください。サプライヤーにコンポーネントのバージョンを問い合わせ、到達可能なすべてのピアをマッピングし、テスト済みの復旧計画を文書化してください。これらの回答が欠けている場合、運用上の露出は依然として解消されていません。