Schneider Electric SCADAPack x70製品、全バージョンで認証情報に関する警告
Schneider Electricは、機密性の高いRTU機能を保護する目的で設計されたSecure Lockに関し、7つのSCADAPack製品ファミリーの全バージョンに影響する認証情報の脆弱性を公表した。通常のファームウェアパッチでは問題を解消できないため、Schneider Electric SCADAPack x70製品に注目が集まっている。
CVE-2026-81861は、リモートターミナルユニット機能へのアクセス制限に使われる旧来のパスワード機構、Secure Lockに関するものだ。Schneiderは、対応製品ではこの機構をロールベースアクセス制御へ置き換えるよう推奨している。一方、旧モデルではネットワーク保護が必要となる。
この違いは重要だ。中心的な問題は、単に最新リリースを導入しているかどうかではない。導入済みコントローラーが、認証情報が露出し得る保護方式に依存し続けているかどうかにある。
影響を受ける機器は、エネルギー、製造業、水道、遠隔地インフラの拠点など、分散型の産業環境で稼働している。こうしたコントローラーは何年にもわたって運用されることが多く、アクセス制御の移行は一般的な業務ソフトウェアの更新より複雑になる。
Schneider Electric SCADAPack x70製品は全バージョンが影響対象
異例なほど広い影響範囲により、製品の脆弱性は資産発見と設定の問題へと変わる。
CISAは2026年9月15日、SCADAPackに関するアドバイザリを公開した。同アドバイザリは、CVE-2026-81861を、Schneider Electric SCADAPackリモートターミナルユニットに影響する、不十分に保護された認証情報の脆弱性として特定している。
対象製品は以下の通りである。
SCADAPack 47x、全バージョン
SCADAPack 47xi、全バージョン
SCADAPack 47xd、全バージョン
SCADAPack 470R、全バージョン
SCADAPack 57x、全バージョン
SCADAPack 3xx、全バージョン
SCADAPack 32、全バージョン
リモートターミナルユニット（RTU）は、フィールド機器と、地理的に分散した運用を監視・制御するシステムを接続する。RTUは測定値の収集、アラームの中継、設定済みロジックの実行、監視プラットフォームからのコマンド受信を行える。
Schneiderは9月8日、最初のセキュリティ通知を公開した。同社は、緩和策を適用しない場合、Secure Lockを介した不正アクセスのリスクが高まり、機密性の高いRTU設定情報が露出する可能性があると述べている。
CVEレコードでは、この問題はCWE-522、すなわち不十分に保護された認証情報に分類されている。このカテゴリは、復元や不正利用に対する十分な保護なしにシステムが保存または送信する認証情報を対象とする。
この脆弱性には、CVSS 4.0でベーススコア5.9、中程度の深刻度が付与された。ベクターは、低い複雑性、事前権限不要、能動的なユーザー操作、および追加の攻撃要件を伴うネットワーク攻撃を示している。評価された技術的影響は、高い機密性の喪失であり、ベーススコアでは完全性や可用性への直接的な影響はない。
CISAのアドバイザリでは、CVSS v3スコアは6.5とされている。これらの数値は異なるスコアリングバージョンを用いるため、その差を矛盾と見なすべきではない。どちらの評価も、認証なしのリモートコード実行ではなく、重大な認証情報露出の問題を示している。
アドバイザリ公開時点で、この脆弱性はCISAの既知悪用脆弱性カタログには掲載されていなかった。CISAの関連判断データでも、既知の悪用はないとされ、攻撃は容易に自動化できないものに分類されていた。
こうした詳細は直近の警戒を和らげるが、運用リスクをなくすものではない。中程度のベーススコアは、個々の導入環境のアーキテクチャ、リモート接続、プロセスの重要性、復旧上の制約をすべて考慮するものではない。
「全バージョン」という指定にも慎重な解釈が必要だ。これは、ベンダーの影響製品記録が、これらの製品ファミリー内に安全なリリースを特定していないことを意味する。すべての導入済みコントローラーが同じ露出状況にあることを意味するわけではない。
実際の露出は、アクセス制御モード、ネットワーク経路、デバイスモデル、利用可能な代替制御策に左右される。より強力なロールベース制御を使用する隔離済みコントローラーと、なおSecure Lockを使用して遠隔管理されるデバイスとでは、リスクが異なる。
この区別がトリアージの指針となるべきだ。運用者は、保有するモデル、各ユニットが使用するアクセス制御方式、管理トラフィックを監視または到達できるシステムを特定する必要がある。
これはスキャナーの検出結果より広い問題だ。脆弱性スキャナーは製品ファミリーやファームウェアバージョンを認識できるが、Secure Lockが有効のままか、RTUが有効なセグメンテーションの背後にあるかまでは判定できない場合がある。
Secure Lockはメッセージを保護したが、秘密そのものは保護しなかった
この欠陥は、設計で使用される暗号アルゴリズムではなく、Secure Lockの信頼モデルに疑問を投げかける。
独立研究者のAbhinav Agarwalは、検証した実装ではSecure Lockメッセージの保護にAES-128鍵ラッピングとHMAC-SHA256メッセージ認証コードが用いられていると報告した。AES鍵ラッピングは鍵素材を保護し、HMACは秘密を知らずにメッセージが改変されていないことを検証する。
研究者の技術分析によると、この実装は、Windows設定コンポーネントとRTUファームウェアに埋め込まれた定数から両方の保護機能を導出する。テストでは、結果として得られる鍵が両コンポーネント間で同一であることが確認されたという。
その結果は、パスワード不要の認証バイパスよりも具体的なものだ。関連するSecure Lockのやり取りを取得した攻撃者は、パスワードをオフラインで復元できると報告されている。オフライン復元とは、標的デバイスへ繰り返し問い合わせることなく、記録済みのトラフィックを解析することを意味する。
研究者は、パスワード設定、パスワード変更、ロック解除のメッセージをテストした。保護されたやり取りにはデバイスごとまたはセッションごとの入力がなく、テスト環境は共有された暗号素材に依存していたと報告している。
デバイスごとの値があれば、あるユニットから導出される鍵は別のユニットの鍵と異なるものになる。セッションごとの値があれば、取得された素材は別のやり取りで再利用しにくくなる。研究者は、テストした経路でいずれの性質も確認できなかった。
したがって、開示された仕組みは不都合な逆転を生む。Secure Lockはメッセージを暗号化・認証するものの、共有された埋め込み秘密に置かれた信頼が、その保護を弱めている。
強力なアルゴリズムでも、実質的に複数の導入環境で共通となる鍵を補うことはできない。攻撃者が同じラッピング鍵と認証鍵を導出できるなら、暗号的な保護層は期待される分離をもはや提供しない。
テストされたパスワードは重要な機能を制御する。研究者によれば、それらの機能には設定書き込み、コマンド実行、ファームウェアアップグレード、セキュリティ変更、特定のファイル転送または端末サービスへのアクセスが含まれる。
ただし、パスワードを復元することは、RTUを即座に制御できることと同義ではない。攻撃者には、観測可能な適格なSecure Lockのやり取りと、その後のアクセスに使えるネットワーク経路がなお必要だ。
開示されたCVSSベクターには、「攻撃要件あり」と「ユーザー操作あり」を通じて、こうした条件が反映されている。受動的な観測者が有用なトラフィックを取得するには、正当な管理者がパスワードの設定や使用など、影響を受ける操作を実行しなければならない。
攻撃者には、そのやり取りを可視化できる状況も必要となる。この可視性は、先行するネットワーク侵害、不適切に分離された通信経路へのアクセス、あるいは運用ネットワーク内の別の位置からの監視によって得られる可能性がある。
研究者は、パスワード不要のロック解除経路が疑われるものを明示的にテストし、機能しなかったと報告している。この結果は主張の範囲を限定する。CVE-2026-81861は認証情報の露出とそれに続く不正利用に関するものであり、万能な1パケットバイパスではない。
同氏の公開テストは、特定のソフトウェアおよびファームウェア成果物も対象としている。RemoteConnect R3.5.5のSCADAPack x70 Device DTMバージョン2.0.18103.4と、特定の47xファームウェアイメージを特定した。
デバイスタイプマネージャー（DTM）は、エンジニアリングツールが特定の産業用デバイスを設定し、通信するためのソフトウェアコンポーネントだ。このケースでは、テスト対象のDTMがSecure Lockワークフローに関与する。
Schneiderの影響製品に関する宣言は、研究者の直接テストより広範だ。ベンダーは、旧世代のSCADAPack 3xxおよび32を含む7つの製品ファミリーと全バージョンを対象に挙げている。
このより広い範囲は修正計画において権威あるものだが、その違いは明示しておくべきである。研究者は定義されたテスト成果物で仕組みを確立した一方、Schneiderは影響ステータスを製品ポートフォリオ全体へ拡大した。
したがって運用者は、両極端の誤りを避けるべきだ。修正を正確にテストされたビルドだけに限定すべきではないが、あらゆるデバイスがあらゆる構成で独立して実証されたと主張すべきでもない。
RBACへの移行が、欠けているファームウェア修正に代わる
Schneiderの主な対応は、Secure Lockをその場で修復するのではなく、アクセス制御アーキテクチャを変えるものだ。
対応するSCADAPack 47xおよび470Rデバイスについて、Schneiderはロールベースアクセス制御（RBAC）の実装を推奨している。RBACは、共有デバイスロック用パスワードに依存するのではなく、定義されたロールとユーザーに権限を割り当てる。
同社は、管理者向けガイダンスとRBAC運用を扱うセクションを含むセキュリティ文書を参照するよう管理者に案内している。より広範なサイバーセキュリティガイドでは、SCADAPack導入環境におけるアカウント管理、ネットワークゾーニング、ファイアウォール、安全な通信、監査手法を説明している。
Schneiderは、Secure Lockを後方互換性のために維持されているレガシー機能と位置付けている。互換製品における推奨アクセス制御機構としてRBACを推奨している。
このガイダンスは、即時の答えが「バージョンXをインストールする」ことではないことを意味する。Schneiderは、Secure Lockを維持したままCVE-2026-81861を解消する修正済みファームウェアリリースを特定していない。
新しい対応コントローラーでは、移行にはより強いパスワードを選ぶ以上の作業が必要となる。管理者は共有ロックのワークフローから、名前付きユーザー、割り当てられたロール、管理された権限へ移行しなければならない。
この移行は説明責任を向上させる可能性がある。共有パスワードでは、誰かが秘密を知っていたことは分かっても、誰が操作を実行したかを確実には特定できない。名前付きアカウントとロールは、権限を絞り込み、監査を強化できる。
移行には作業も伴う。運用者は、管理ロールの定義、アカウントのプロビジョニング、エンジニアリングツールからのアクセスのテスト、手順の更新、緊急保守が引き続き可能であることの確認を行う必要がある。
中央集約型ディレクトリを使用する組織は、RTU環境とID基盤の依存関係を検証する必要がある場合がある。また、ディレクトリサービスや広域接続が利用できないときに遠隔拠点がどのように動作するかも考慮しなければならない。
産業用制御の変更には慎重なテストが必要だ。認証の設定ミスにより、正当なエンジニアリングアクセスが遮断される可能性がある。急いだ移行は、サイバーリスクを低減する一方で運用上の問題を生むおそれがある。
このため、運用者は変更前に現在のアクセス経路を文書化すべきである。記録には、エンジニアリングワークステーション、リモートサポート接続、サービスアカウント、ローカル復旧手順、物理アクセスの選択肢を含める必要がある。
旧世代のSCADAPack 57x、3xx、32ファミリーでは、より困難な課題となる。Schneiderの緩和策ガイダンスは、これらのデバイスには同じRBAC移行パスがないため、ネットワークセグメンテーションとRTUファイアウォールを重視している。
ネットワークセグメンテーションは、システムを制御されたゾーンに分離し、それらの間の通信を制限する。RTUファイアウォールは、どのホスト、プロトコル、サービスがコントローラーに到達できるかを制限するルールを適用する。
これらの対策は、認証情報保護の仕組みそのものを修復するものではない。Secure Lockの交換を観測できるシステムや、露出した認証情報を再利用できるシステムの数を減らすものである。
運用者は、管理トラフィックを承認済みのエンジニアリングステーションと信頼できる管理経路に限定すべきである。また、インターネットへの直接公開を排除し、通常の企業エンドポイントがRTU管理サービスに到達できないようにする必要がある。
CISAの公開範囲に関するガイダンスは、インターネットからアクセス可能な産業資産の特定、不必要な公開の排除、監視対象のジャンプホストの利用、可能な場合の多要素認証の追加を推奨している。
ジャンプホストとは、管理者が機密性の高いデバイスに到達する前に経由しなければならない、制御された中継地点である。旧式のフィールド機器にこうした機能が備わっていない場合でも、ログ記録、認証、アクセス制限を一点に集約できる。
仮想プライベートネットワークは、信頼できないインフラをまたぐトラフィックを保護できる。しかし、VPNによってリモートのノートPCから制御ネットワーク全体への無制限なアクセスを許可すべきではない。
より限定的なアプローチの方が望ましい。リモートユーザーは監視されたアクセスサービスで認証し、必要な資産のみにアクセスし、定義された作業に必要な権限だけを付与されるべきである。
認証情報の露出は通信の観測に依存するため、トラフィック監視も重要となる。運用者は、予期しないDNP3 Virtual Terminalトラフィック、異常なアンロック操作、繰り返される設定アクセス、またはエンジニアリングゾーンとリモートサイト間の新たな通信を調査すべきである。
DNP3は、制御センターとフィールドデバイス間の通信に広く利用されているプロトコルである。そのVirtual Terminal機能は、研究者が説明したSecure Lockメッセージを含む、デバイス指向のやり取りにアプリケーションが使用できるチャネルを提供する。
Secure Lockのパスワードを変更するだけでは、持続的な対処にはならない。置き換えたパスワードが後に同じ脆弱な仕組みを通じて送信されるなら、十分な能力を持つ観測者は別のキャプチャされた交換から新しい秘密情報を復元できる。
実務上の目標は、影響を受けるワークフローへの依存を止めることにある。移行できない場合、運用者は多層的なネットワーク制御により、観測と再利用を大幅に困難にしなければならない。
中程度のスコアでもOTの修復は困難になり得る
この脆弱性の直接的な影響が限定的であることは、長期運用されるフィールド環境を保護するために必要な労力を測るものではない。
CVE-2026-81861は、即時の安全システム侵害のような性質を持つものではない。基本ベクターでは完全性および可用性への直接的な影響はなく、公開時点で悪用が行われているという公的な証拠も示されていなかった。
こうした制約は重要である。セキュリティチームは、この問題を、実証済みのプロセス操作、自動的なプラント停止、または認証不要のコード実行として説明すべきではない。
特定された影響は、認証情報に関する機密性の喪失である。不正なRTUアクセスにつながる可能性はあるが、悪用には依然としてネットワーク条件と管理者の活動が必要となる。
同時に、中程度という深刻度ラベルは、運用上の複雑さを過小評価する可能性がある。Schneider Electric SCADAPack x70 Productsは、リモート監視および制御向けに設計されており、多くの場合、現地スタッフが限られるサイトで運用される。
エンタープライズアプリケーションであれば、中央からパッチを適用できることが多い。フィールドコントローラーでは、アクセスのスケジューリング、運用承認、専門的なテスト、物理プロセスを担当するチームとの調整が必要になる場合がある。
影響を受けるリストには、現行機器とレガシー機器の両方が含まれる。一部のユニットはRBACを導入できるが、他のユニットはセグメンテーション、フィルタリング、安全なリモートアクセスアーキテクチャに依存しなければならない。
このため、修復プログラムは複数のトラックに分かれる。単一の脆弱性チケットでは、すべてのモデルとサイトにまたがる作業を正確に表現できない。
第1のトラックは、互換性のある47xおよび470Rの導入環境を対象とする。チームはSecure Lockの使用状況を確認し、RBACロールを設計し、管理ワークフローをテストし、レガシーモードを廃止しなければならない。
第2のトラックは、57x、3xx、32の導入環境を対象とする。チームは、ファイアウォールルールの検証、到達可能なサービスの削減、管理経路の分離、トラフィック監視を行う必要がある。これは、望ましいアクセス制御の代替手段が利用できないためである。
組織の残存リスクしきい値を満たせないデバイスには、第3のトラックが必要になる可能性がある。特にネットワーク上の配置を十分に制限できない場合、これらのユニットでは交換計画が必要になることがある。
資産インベントリの品質が決定的となる。組織は、把握していないコントローラーを移行または分離することはできず、保守記録の製品ラベルがアドバイザリで使用される名称と一致しない場合もある。
チームは、エンジニアリングデータベース、ネットワーク観測、調達記録、サイト文書を照合すべきである。正確なモデル、ファームウェア、設定済みのアクセスモード、通信経路、責任者を記録する必要がある。
設定はバージョンと同じくらい重要である。リストにあるすべてのバージョンが影響を受けるため、バージョンのみを確認するスキャナーでは、どのシステムが実際にSecure Lockを使用しているかを特定せずに大量の結果を生成する可能性がある。
これはスキャンが無用であることを意味しない。スキャナーの出力は、調査を完了させるのではなく、調査を開始するものだということである。
公開された概念実証についても、バランスの取れた扱いが必要である。研究者は、完全に復元された秘密情報を公開せず、鍵導出を実証するサニタイズ済みの検証ツールを公開した。
この慎重な対応は直近の悪用を抑えるが、公開された技術的詳細は依然として防御側のタイムラインを変える。他の研究者や攻撃者が手法を調査し、独自に再現を試みることができるためである。
CISAの「既知の悪用なし」というステータスは、予測ではなくスナップショットである。防御側は、CVEレコード、CISAのカタログ、Schneiderの通知、産業ネットワークを対象とする脅威インテリジェンスの変化を監視すべきである。
パッチが存在しないことは、クローズの意味も変える。脆弱性管理プラットフォームは、運用者がRBACまたは有効なセグメンテーションを実装した後も、影響を受けるすべてのバージョンを検出し続ける可能性がある。
組織には、証拠に基づく例外処理または代替制御の記録が必要である。そうしなければ、セキュリティダッシュボードには未解決の検出事項が表示され続け、Secure Lockが露出している導入環境と移行済みのシステムを区別できなくなる。
ただし、こうした記録を恒久的な書類上の代替手段にしてはならない。各例外には、明確な管理責任者、検証方法、レビュー日、交換のトリガーが必要である。
この問題はまた、CVSSがオペレーショナルテクノロジーにおける唯一の優先順位付け手法になり得ない理由も示している。CVSSは脆弱性固有の深刻度を測る一方で、運用者はプロセスの重要性、ネットワーク露出、復旧能力、潜在的な物理的影響を加味しなければならない。
隔離されたテストコントローラー上の中程度の脆弱性は、重大な業務アプリケーションの欠陥より優先度が低い場合がある。同じ脆弱性でも、セグメンテーションが弱い状態でリモート管理されるRTU上にあれば、より迅速な対応が必要になる可能性がある。
したがって、リスクチームは公開スコアとサイト固有の証拠を組み合わせるべきである。有用な問いには、管理トラフィックが共有ネットワークを通過するか、パケットキャプチャが現実的か、デバイスが重要なプロセスを制御しているかが含まれる。
また、パスワードを復元した攻撃者が通常のアンロックインターフェースに到達できるかも問うべきである。認証情報の漏えいは、その認証情報を使用できる場合にのみ価値を持つ。
3つのシグナルがリスク封じ込めの成否を示す
次の段階は、移行の証拠、ベンダーの更新、攻撃者が研究段階から運用段階へ移行している兆候に左右される。
第1のシグナルは、運用者がSecure Lockを特定し、廃止する速度である。影響を受ける組織は、RBACを使用するデバイス数、レガシーロックに依存するデバイス数、代替制御に依存する旧式ユニット数を報告できるべきである。
RBACへの移行率の上昇は、Schneiderの緩和戦略を支持することになる。導入済みアクセスモードに関する不確実性が続けば、攻撃が公に確認されていなくても信頼性を損なう。
最も有用な運用指標は、単に影響を受ける資産の数ではない。検証済みのアクセス制御状態とテスト済みの修復策を持つ資産の割合である。
RBAC対応デバイスでは、Secure Lockがもはや実効的なセキュリティ境界ではないことを検証で確認すべきである。また、管理ロールが正しく機能し、緊急時の手順が引き続き利用可能であることも示す必要がある。
レガシーユニットでは、検証で許可されたネットワーク経路をテストすべきである。通常のワークステーションが依然としてRTUの管理サービスに接続できるなら、文書化されたセグメンテーションポリシーの価値は限定的である。
第2のシグナルは、Schneiderが改訂版のガイダンス、拡充された技術的詳細、または製品アップデートを発行するかどうかである。初期対応は、修正済みのSecure Lock実装ではなく、アーキテクチャ上の緩和策に依存している。
後続のファームウェアまたはツール変更は、修復の状況を変える可能性がある。移行支援、脆弱な挙動の除去、ログ記録の改善、影響を受ける構成の限定が提供されるかもしれない。
反対に、代替制御への依存が継続すれば、運用者がこれを長期的なアーキテクチャ上の問題として扱わなければならないことが確認される。その場合、より強力なアクセス制御をサポートできないレガシーデバイスを交換する圧力が高まる。
セキュリティチームは、転載されたアドバイザリ要約だけに頼らず、ベンダーの通知を監視すべきである。製品アドバイザリは、テスト範囲の拡大や緩和手順の精緻化に伴い変更される可能性がある。
第3のシグナルは、悪用または再現の拡大を示す証拠である。公開時点でCISAは既知の悪用はないと報告しており、CVE-2026-81861はKnown Exploited Vulnerabilitiesカタログに掲載されていなかった。
防御側が認証情報復元活動、不正なアンロック試行、トラフィック分析を自動化するツールを発見した場合、この状況は大きく変化する。カタログへの追加も、別の強力なエスカレーションシグナルとなる。
公開された再現だけでは、稼働中の施設に対する攻撃を証明するものではない。それでも、攻撃者が直面する技術的不確実性を減らし、キャプチャされたSecure Lockトラフィックの価値を高めることになる。
運用者は、関連するログとネットワークテレメトリを今すぐ保存すべきである。悪用報告を待っていると、機密性の高い交換が過去に観測されていたかを判断するために必要な履歴データを、調査担当者が利用できなくなる可能性がある。
監視は、プロセスアラームだけでなく管理活動に重点を置くべきである。設定アクセス、パスワード変更、アンロック操作、新しいエンジニアリングホスト、異常なリモートセッションは、物理運用が変化する前にアクセス制御の問題を明らかにする可能性がある。
Schneider Electric SCADAPack x70 Productsは依然として有用なフィールドプラットフォームであり、アドバイザリは導入済みサイトが侵害されたことを立証するものではない。ただし、リストにあるすべてのバージョンについて、構成レベルのレビューが必要であることは示している。
資産所有者にとっての当面の問いは具体的である。組織は、どのコントローラーがまだSecure Lockを使用しているか、その管理トラフィックを誰が観測できるか、露出したパスワードとRTUアクセスの間に現在どの制御が存在するかを証明できるだろうか。
まずそのインベントリから始め、互換性のあるデバイスをRBACへ移行する。移行できないモデルを分離し、そのファイアウォールルールをテストし、承認済みのすべての管理経路を監視する。この脆弱性は、バージョン確認だけでは管理できない。
