mySCADA myPRO Manager、2件の認証不備を修正 うち1件は重大評価

mySCADA myPRO Managerでは、機微なインターフェースが認証なしでリクエストを受け付けていたことから、評価9.8の脆弱性を含む2件のセキュリティ上の欠陥が公開された。影響を受けるのはバージョン2.1以前で、ベンダーによる修正はバージョン2.2に含まれている。

より深刻な脆弱性は、製品のコマンドAPIを通じて特権管理機能を露出させる。もう一方は、接続済みGSMモデムを介して任意のテキストメッセージを送信できるHTTPエンドポイントを露出させる。いずれの経路でも、該当リクエストを受け付ける前に認証済みアカウントを必要としない。

これは、利便性の高い産業管理と基本的なアクセス制御との間に深刻な矛盾を生む。myPRO Managerは運用者による接続環境の設定を支援するが、脆弱なインターフェースは、機微なコマンドを発行する主体を検証していなかった。mySCADA製品は世界各地の運用技術環境で利用されているとみられるため、この問題は一般的なWebアプリケーションの範囲を超える。

当面の対応は明確だ。運用者は影響を受ける導入環境を特定し、更新を適用し、どのネットワークから管理インターフェースに到達できるかを確認する必要がある。とりわけ、隔離されたシステム、管理対象外の導入環境、停止時間がアップグレードを難しくする環境では、その後により困難な作業が始まる。

mySCADA myPRO Managerで何が変わったのか

今回の開示では2件の個別の認可不備が示されているが、コマンドAPIの脆弱性の方が運用上のリスクは大きい。

2026年9月15日、CISAはmySCADA myPRO Managerを対象とする産業向けアドバイザリーを公開した。そこでは、バージョン2.1以前に存在するCVE-2026-73807およびCVE-2026-82567が特定されている。

バージョン2.2は影響を受けないものとして記載されている。mySCADA Technologiesは、このリリースが両方の問題に対処しているとし、利用可能な最新バージョンへの更新を推奨している。

CVE-2026-73807はコマンドAPIに関するものであり、これはソフトウェアコンポーネントが管理リクエストを発行するためのインターフェースを指す。公式記録によれば、このAPIは特権機能に対する認証を適切に強制していない。

攻撃者に既存アカウントは必要ない。影響を受けるインターフェースへのネットワークアクセスを得れば、通常は認可された管理者に限定される機能の呼び出しを試みることができる。

CVE記録では、この欠陥に重大範囲に該当するCVSS 3.1スコア9.8が割り当てられている。そのベクターは、ネットワークから到達可能で、攻撃の複雑性が低く、必要な権限およびユーザー操作がなくても悪用可能な脆弱性を示している。

この記録ではCVSS 4.0スコア9.3も割り当てられている。いずれの評価も、脆弱なシステムにおける機密性、完全性、可用性への影響が大きい可能性を示す。

ただし、このスコアはすべての導入環境が同程度に露出していることを意味しない。CVSSは標準化された前提のもとで技術的な深刻度を測定するものであり、特定のコマンドAPIが複数のファイアウォールの背後にあるのか、信頼されていないネットワークから到達可能なのかは考慮しない。

CVE-2026-82567は、GSMモデムを介したSMS配信とmyPRO Managerを接続する通知ゲートウェイに影響する。脆弱なHTTPエンドポイントは電話番号とメッセージを受け取り、モデムにそのテキストの送信を指示する。

このエンドポイントは、最初に認証を要求しない。したがって、適切なネットワークアクセスを持つ攻撃者は、接続済みモデムを通じて任意の宛先およびメッセージを送信できる。

この2件目の脆弱性には、中程度に分類されるCVSS 3.1スコア6.3が付与されている。そのベクターでは、CVE-2026-73807に割り当てられたより広いネットワーク経路ではなく、隣接ネットワークからの攻撃経路が用いられている。

この違いは重要である。SMSの脆弱性では一般に、攻撃者が該当するローカルまたは隣接ネットワークに到達する必要がある。一方、重大なコマンドAPIの脆弱性は、より広いネットワーク攻撃分類に該当する。

ただし、両方の問題には同じ根本的な弱点がある。機微な操作が、リクエストした主体に実行権限があるかを確立する前に入力を受け入れていることだ。

CISAは、この発見をSECNORAの研究者Rajivarnan R.およびShirshakによるものとしている。脆弱性は外部から発見され、同機関の産業用制御システムの脆弱性開示プロセスを通じて調整された。

このアドバイザリーは、影響を受ける導入環境が重要製造業、エネルギー、食品・農業、輸送、水道・廃水の各分野にまたがるとしている。展開地域は世界規模と説明され、ベンダーの本社所在地はチェコと記載されている。

これらの分野ラベルは、影響を受けるすべてのインスタンスが物理プロセスを直接制御していることを示すものではない。それでも、この製品の認証不備が運用技術チームから厳重な注意を受けるべき理由を示している。

産業ネットワークで認証欠如がより重大となる理由

産業管理インターフェースに到達するリクエストは、それを受け取るソフトウェアプロセスをはるかに超える影響をもたらし得る。

認証は、基本的な問いに答える。誰がこのリクエストを行っているのか。認可はその次の問い、すなわち、そのIDに何が許可されているのかに答える。

CVE-2026-73807は、特権管理機能を巡るこの境界を破る。公式説明では露出したすべての機能が列挙されていないため、防御側は文書化されたアクセス範囲を超える特定の結果を想定すべきではない。

それでも、「特権管理機能」という表現は重大な信頼の失敗を示している。管理用に設計されたインターフェースが、管理者を他のシステムから分離すべき制御を強制せずにネットワークリクエストを受け入れていた。

CVSSベクターはこの懸念を反映している。権限不要、ユーザー操作不要、低い複雑性に加え、機密性、完全性、可用性のすべてに高い影響を与える可能性を前提としている。

企業Webサイトでは、アクセス制御の失敗によってデータやアプリケーション設定が露出することがある。運用技術環境では、管理ソフトウェアが設備を監視し、プロセスデータを収集し、アラームを配信し、運用者の意思決定を支援するシステムの近くに置かれている場合がある。

正確な影響は導入環境ごとに異なる。ネットワーク設計、接続機器、製品設定、露出している機能のすべてが実際のリスクを左右する。

この変動性により、資産の文脈が不可欠となる。切り離されたラボ環境は、共有された社内セグメントから到達できる本番管理システムと同じ露出を示さない。

インターネットに公開された導入環境は、さらに緊急性の高いケースとなる。アドバイザリーは公開システム数を示していないが、信頼されていないネットワークからの直接アクセスは重要な防御障壁を取り除く。

SMSの弱点は影響範囲がより狭いものの、同じ設計上の問題を示している。通知ゲートウェイは、多くの場合、利用者が信頼することを期待される運用アラートを伝える。

既知のモデムを介して任意のメッセージを送信する攻撃者は、混乱を引き起こし、通常の通知になりすまし、あるいはメッセージ送信能力を消費する可能性がある。公式記録は、攻撃者が既存メッセージを読んだりモデムを再設定したりできるとは主張していない。

防御側はこの区別を維持すべきだ。開示された能力は不正なSMS送信であり、すべての通知機能を制御できることが証明されたわけではない。

それでも、任意のメッセージはインシデント時に重要になり得る。運用者は、制御室を離れている場合や他の通信チャネルが機能しない場合にテキストアラートへ依存することがある。

不正なメッセージは、正当なシステムアラートと誤認される可能性がある。望ましくないメッセージが大量に送られれば、本物の通知を認識しにくくなる可能性もある。

これらのシナリオは合理的なリスク上の考慮事項であり、文書化された悪用報告ではない。アドバイザリーは不正送信経路を確立している一方、各組織は運用上の結果を評価しなければならない。

産業環境では、チームがパッチを適用できる速度も変わる。本番環境では、管理ソフトウェアを変更する前に、計画停止、互換性テスト、ベンダーとの調整、安全性レビューが必要になる場合がある。

これらの制御は偶発的な障害を減らすが、脆弱なコードが導入されたままとなる期間を長引かせる可能性がある。そのため、ネットワーク制限は更新プロセスの前、最中、後のいずれにおいても重要である。

利便性とアクセス制御の衝突

中心的な問題は高度なエクスプロイトチェーンではなく、有効なID確認ポイントなしに露出した機微な機能にある。

管理APIは、手作業による管理が拡張性を持たないために存在する。ソフトウェアコンポーネント、コンソール、サービスが定義されたリクエストを通じてコマンドを交換できるようにする。

通知ゲートウェイも同様の利便性を提供する。産業イベントと通信チャネルを接続し、ソフトウェアがGSMモデムを介してアラートを配信できるようにする。

どちらの設計も有用になり得る。その安全性は、リクエスト元が受け入れ可能なIDを証明し、明示的な許可を得るまで、すべての受信リクエストを信頼しないものとして扱うことに依存する。

公開された脆弱性は、この一連の流れが壊れた場合に何が起きるかを示している。コマンドAPIでは、リクエスト元が期待される認証の強制なしに特権機能へ到達できる。

通知ゲートウェイでは、HTTPエンドポイントが認可された利用者を検証する前に、宛先およびメッセージのデータを受け付ける。その後、要求されたメッセージを接続済みモデムへ渡す。

文書化されたどちらの経路でも、ソーシャルエンジニアリングは必要ない。管理者が悪意あるファイルを開いたり、プロンプトを承認したりする必要もない。

ただし、それは悪用が自動的に成立することを意味しない。攻撃者は依然として必要なネットワーク到達性を得て、インターフェースを特定し、サービスが受け入れるリクエストを送信する必要がある。

こうした前提条件は、ネットワークアーキテクチャが依然として重要である理由を説明する。厳格に管理された管理ゾーン内に隔離された脆弱なサービスは、広範な社内ネットワークに露出したサービスよりも攻撃経路が少ない。

ただし、セグメンテーションは代償的な制御であり、認証欠如の修正ではない。ネットワークは変化し、ファイアウォールルールは蓄積し、リモートアクセス経路は拡大し、侵害された内部デバイスは信頼された場所に関する前提を回避できる。

より安全な設計は複数の層を組み合わせる。アプリケーションはすべての機微なリクエストを認証し、認可は利用可能な操作を制限し、ネットワークはどのシステムがインターフェースに到達できるかを制限する。

さらに、ログは受け入れられたアクティビティと拒否されたアクティビティを記録すべきである。監視では、異常なコマンド、想定外の送信元アドレス、不規則なSMS宛先を特定すべきだ。

CVE-2026-73807およびCVE-2026-82567が重要なのは、このモデルのアプリケーション層を弱めるためである。バージョン2.2はベンダーがサポートするソフトウェア修正を復元し、ネットワーク制御はその周辺の露出を減らす。

この対比は、深刻度の違いも説明する。コマンドAPIの問題は、脆弱なシステムの3つの中核的なセキュリティ特性すべてに対して、潜在的に高い影響を与えるものとして評価されている。

SMSエンドポイントには、より低い影響評価と隣接ネットワーク分類が付与されている。文書化された結果は、接続されたモデムを通じた任意のメッセージ送信に限定される。

両方の発見を同一に扱えば、修正の優先順位が不明確になる。より低いスコアの問題を無視すれば、信頼された通知チャネルを通じた実用的な悪用経路を見落とすことになる。

したがって、チームは重大なコマンドAPIの露出を優先しつつ、同じアップグレードで両方の脆弱性に対処すべきである。導入作業が複雑なままであっても、単一のバージョン境界によってソフトウェア上の判断は単純化される。

ベンダーによれば、新バージョンが利用可能になると、接続済みデバイスはmySCADA Pro Manager内で利用者に通知する。オフライン環境では、運用者がmanager downloadページから別途更新を取得する必要がある。

オフライン環境は特に注意を払うべきです。隔離によって露出は減らせる一方、自動更新通知が届かず、中央集約型の資産管理ツールから古いソフトウェアが見えなくなる可能性もあります。

エアギャップは、バージョン把握の代替手段になるべきではありません。可搬型メディア、一時的な保守接続、ノートPC、設定ミスのあるルーティングによって、当初の設計時には存在しなかった経路が生じる可能性があります。

パッチは明確だが、展開リスクは残る

バージョン2.2は文書化されたソフトウェア上の欠陥を解消するものの、組織は影響を受けるすべてのインストール環境が修正版の状態に到達した証拠を依然として必要としています。

ベンダーの修正措置は明快です。mySCADA myPRO Managerをバージョン2.2以降へ更新します。影響を受ける範囲はバージョン2.1までです。

この明確さにより、よくある混乱の原因の一つが取り除かれます。この2件のCVEについて、チームが複数のパッチを異なるブランチと照合する必要はありません。

運用上の課題は資産の把握です。組織は製品の稼働場所、各インストール環境で使用されているバージョン、各ネットワークゾーンから到達可能なインターフェースを特定しなければなりません。

この作業では、新たなアドバイザリとは関係のない欠落が明らかになる可能性があります。産業用ソフトウェアは、エンジニアリングワークステーション、専用の管理システム、一時的な試運転用デバイス、または通常の企業プロセスの外で保守されるマシンに存在することがあります。

信頼できる資産台帳には、アプリケーションのバージョン、ホストの識別情報、ネットワーク上の位置、システム所有者、運用機能、許可された通信経路を含めるべきです。また、GSMモデムが接続されているかも記録する必要があります。

モデムの詳細によって、文書化されたSMS経路が特定の導入環境に存在するかどうかが決まります。そのコンポーネントがないインストール環境では、CVE-2026-82567の実際的なシナリオは同じではありません。

コマンドAPIには個別の分析が必要です。チームは到達を許可されているすべての接続元を特定し、ユーザーネットワーク、無線セグメント、ベンダーアクセスシステム、または公衆インターネットに由来する経路がないか確認すべきです。

ファイアウォールルールだけでは隔離の証明になりません。パケットフローテストと設定レビューは、意図した管理システムだけが接続できることを示す、より強い証拠となります。

アップグレード前に、運用担当者はバックアップおよび復旧手順を確認すべきです。また、更新後にマネージャーの動作が変化した場合に失敗しうる依存関係も理解する必要があります。

テストでは、通常の管理操作、アラーム配信、SMS通知、認証、管理対象システムとの接続性に重点を置くべきです。目的は、本番展開前に互換性の問題を見つけることです。

その後、チームは変更後のインストール済みバージョンを記録すべきです。更新通知やダウンロード済みインストーラーは、すべてのホストでアップグレードが正常に完了したことの証明にはなりません。

即時のパッチ適用が不可能な場合、露出の低減が急務となります。管理インターフェースへのアクセスは、ファイアウォールと分離されたネットワークゾーンを通じて、明示的に許可されたシステムに限定すべきです。

リモート管理では、アプリケーションを直接公開するのではなく、制御されたアクセス経路を使用すべきです。CISAの既存の産業向けガイダンスは、露出の最小化、制御ネットワークと業務ネットワークの分離、安全なリモートアクセス手法の使用を推奨しています。

同機関の多層防御ガイダンスでは、ネットワークアーキテクチャ、アクセス制御、監視、インシデント対応を相互補完的な保護策として扱っています。これらのいずれも、修正版ソフトウェアの恒久的な代替と見なすべきではありません。

一時的な対策には、責任者と期限を設定すべきです。そうしなければ、緊急時のファイアウォール制限が、脆弱なバージョンを残したまま静かに長期的な対応へと変わってしまう可能性があります。

監視にも導入環境固有のシグナルが必要です。チームは、コマンドAPIへの接続、アップグレード後に拒否された認証イベント、通知エンドポイントへの異常なリクエストを確認できます。

SMS対応システムでは、運用担当者はモデムの活動と想定されるアラートを照合すべきです。認識されない宛先番号、通常と異なるメッセージ内容、異常な送信頻度は調査に値します。

過去のログは、修正前に不審な活動が発生していたかを判断するのに役立ちます。ただし、脆弱なエンドポイントに十分なログ記録がなければ、ログエントリーがないことだけで試行がなかったとは断定できません。

インシデント対応者は、関連するネットワーク、ホスト、アプリケーション、モデムの記録を保存すべきです。活動が不審に見える場合は、確立済みのエスカレーションおよび報告手順に従う必要があります。

このアドバイザリは、公開された悪用の具体的な説明を提供していません。そのため、防御側が攻撃者の行動、ツール、確認済みの被害組織について結論づけられる範囲は限られます。

これは、認証を必要としない管理経路の技術的深刻度を下げるものではありません。露出度とミッションへの影響によって、各組織の対応速度を決めるべきです。

mySCADAでは以前にも高深刻度の問題が確認されている

今回の脆弱性は、管理機能が攻撃者によって直接試されうるセキュリティ境界となる、より広い傾向の一部です。

CISAは、mySCADA製品に関する過去のアドバイザリも公表しています。これらの以前の事例は共通の技術的原因を示すものではありませんが、防御側にとって有益な文脈を提供します。

2022年、CISAはmySCADA myPROバージョン8.26.0以前におけるコマンドインジェクション脆弱性について説明しました。認証済みユーザーはパラメーターを変更し、オペレーティングシステムのコマンドを実行できました。

この以前のmyPROの問題には、CVSS 3で9.9のスコアが付与されていました。ベンダーはバージョン8.27.0以降への更新を推奨しました。

2026年のコマンドAPIの脆弱性は、重要な点で異なります。公開された攻撃ベクトルでは権限を必要としませんが、2022年の問題では認証済みユーザーが必要でした。

記録上では製品とバージョン体系も異なるため、運用担当者はこれらのアドバイザリ間に直接的なアップグレードパスがあると推測すべきではありません。影響を受ける各インストール環境は、特定の製品およびバージョン情報と照合する必要があります。

別の2025年のアドバイザリでは、オペレーティングシステムのコマンドインジェクションを含む、複数のmyPRO Manager脆弱性が扱われました。この履歴は、管理コンポーネントを高価値資産として扱う必要性を強調しています。

教訓は、あるベンダーだけが特別に脆弱だということではありません。産業製品における管理インターフェースは、攻撃者が重視する機能を日常的に集約しています。

これらは設定、通信、認証情報、更新、または制御環境への接続を公開します。そのため、単一の制御不足が複数の下流の保護策を損なう可能性があります。

このため、脆弱性管理ではCVE件数だけでなく、製品を機能別に追跡すべきです。管理サーバーは、その役割によって侵害の影響を増幅しうるため、優先する価値があります。

同じ考え方は、リモートアクセスアプライアンス、エンジニアリングワークステーション、データヒストリアン、通知ゲートウェイにも当てはまります。運用への近接性により、一般的なソフトウェア上の弱点は、状況に応じてより大きな意味を持ちます。

組織は、見出しのスコアだけに完全に依存することも避けるべきです。CVE-2026-82567は中程度のスコアですが、その悪用はサイトの信頼されたアラートプロセスを妨害する可能性があります。

逆に、9.8というスコアは、隔離されたインスタンスがインターネットから攻撃可能であることを証明するものではありません。攻撃者が脆弱なサービスへ到達した場合の、深刻な技術的特性を示すものです。

効果的な優先順位付けでは、深刻度、露出度、悪用可能性、運用機能、復旧の難しさを組み合わせます。また、容易に利用可能な修正版が存在するかも考慮します。

ここでは、修正版が存在します。そのため、運用上の制約によって展開が妨げられていない限り、バージョン2.1以前を長期間使用し続けることの正当化はますます難しくなります。

そのような制約がある場合、管理部門は記録に残すべきです。記録には責任者、依存関係の説明、一時的な対策、次回レビュー日を記載する必要があります。

これにより、パッチ適用の遅延は管理されたリスク判断となります。このプロセスがなければ、遅延は見えない既定状態になります。

運用担当者が次に注視すべきこと

次に有用なシグナルは、検証済みのアップグレード適用範囲、悪用の証拠、そして機密性の高いインターフェースがもはや広範に到達可能ではないという確認です。

まず、組織はバージョン2.2以降の採用状況を測定すべきです。最も重要な内部指標はパッチがダウンロードされたかではなく、影響を受けるすべての資産が修正版のバージョンを報告しているかです。

この測定には、通常の企業ツールの対象外にあるシステムも含めるべきです。オフラインのインストール環境、請負業者が管理するデバイス、テスト環境には、本番環境の更新が完了した後も脆弱なバージョンが残る可能性があります。

完全な結果は、当面のソフトウェアリスクが封じ込められたという判断を強めます。未特定または到達不能な資産は、その結論を弱めます。

次に、防御側は悪用状況の変化について信頼できる情報源を監視すべきです。新たな概念実証コード、確認済みの攻撃、または政府の悪用カタログへの収載は、対応の緊急度を変えるでしょう。

公開時点で、利用可能なアドバイザリ資料は、活発な悪用キャンペーンを立証することなく脆弱性と修正を説明しています。読者は、この不在と、悪用が不可能であるという証拠を区別すべきです。

脅威情報は公開後に急速に変化する可能性があります。攻撃者は明確な製品名、影響を受けるバージョン範囲、弱点の分類、露出した機能の説明を得ます。

第三に、運用担当者は周辺アーキテクチャを検証すべきです。アプリケーションの更新で、管理インターフェースの露出に対するレビューを終えるべきではありません。

適切なネットワークゾーンからのスキャンにより、コマンドAPIと通知ゲートウェイが承認済みの接続元からのみ接続を受け入れるかを確認できます。ファイアウォールのレビューでも同じ結論が得られるべきです。

広範なセグメントが依然としてこれらのサービスに到達できる場合、その環境は将来の欠陥に対して不必要に露出したままです。パッチは既知の脆弱性を閉じる一方、セグメンテーションは次の未知の脆弱性による影響範囲を限定します。

チームは、更新後のアプリケーション動作も検証すべきです。機密性の高いコマンドには認証済みかつ権限を持つアクセスが必須であり、SMSエンドポイントは認証されていないリクエストを拒否しなければなりません。

これらのテストは、制御された環境で承認済みの手順に従って実施すべきです。調整なしに本番環境を検査すると、運用リスクが生じる可能性があります。

今回の確認事項は、アカウントおよびアクセス設計の見直しも必要とします。組織は、誰がマネージャーを管理するのか、どのサービスアカウントがそれと連携するのか、認証情報がどのように保護されているのかを特定すべきです。

認証が復旧した後も、最小権限は重要です。有効なアカウントには、その役割に必要な機能だけを与えるべきです。

ログ記録には最後の確認が必要です。セキュリティチームには、リクエストを送信元、ID、操作、結果、時刻と結び付けられる十分な詳細が必要です。

モデムを使用する通知では、記録は各メッセージを、それを開始したイベントまたはユーザーと結び付ける必要があります。これにより、正当な自動化と不正使用を区別しやすくなります。

したがって、mySCADA myPRO Managerへの実務的な対応は、単一リリースのインストールよりも広範です。まずパッチを適用し、その後、到達可能性、アクセス制御の実施、ログ記録、資産の網羅性を検証します。

組織でmyPRO Managerを運用している場合、すべてのインストール環境がバージョン2.2以降であることを証明できるでしょうか。また、信頼されていないシステムが特権インターフェースに到達できないことも示せるでしょうか。

この二つの答えが短期的な結果を決定します。確認済みの更新は文書化された脆弱性を解消します。制限されたネットワークアクセスとテスト済みの認証は、次に見落とされるインターフェースが運用インシデントとなる可能性を低減します。