Ignitionの空欄設定が権限穴に、8.1.54で設計ごと変更

米国CISAは2026年9月3日、Inductive Automationの産業用アプリケーション基盤Ignitionにあるプロジェクト作成権限の問題をCVE-2026-77393として公開した。影響を受けるのは8.1.53以前で、8.1.54ではプロジェクト作成をDesignerセッションに限定する方式へ変更されている。8.3系は影響を受けない。

問題は、Gatewayの「Create Project Role(s)」が空欄で出荷され、特定の作成ロールを要求しない状態になっていたことだ。ただし、未認証の第三者が直ちに侵入できる問題ではない。有効なアカウントで認証され、Gatewayスクリプトを実行できる利用者が、専用ロールを持たなくてもプロジェクトを作成できるという条件付きの権限問題である。

空欄が外していたのは作成ロールの条件

「Create Project Role(s)」は、プロジェクト作成を許可するロールを指定するGatewayのセキュリティ設定だ。空欄だった旧版では、アクセス制御が設定値を無視したのではなく、設定どおり「必要なロールなし」として処理されていた。

CISAの公式勧告 は、この問題をCWE-276「Incorrect Default Permissions」に分類し、CVSS v3.1の基本値を8.8と評価している。同勧告によると、公開時点でこの脆弱性を狙った既知の公開悪用は報告されていない。

したがって、インターネットからGatewayへ到達できるかどうかだけでは、各環境の影響を判定できない。正確なバージョンに加え、対象設定が空欄か、どのアカウントが認証可能か、誰がGatewayスクリプトを実行できるかを組み合わせて確認する必要がある。「認証が必要だから対象外」と判断するのも、「空欄だから未認証攻撃が可能」と解釈するのも不正確だ。

8.1.54は空欄を埋めず、作成経路を変えた

影響範囲の境界は、8.1系列では8.1.53以前と8.1.54以降の間にある。TenableのCVE記録 も、旧版の空欄設定と認証・Gatewayスクリプト実行という条件、8.1.54でのDesignerセッション限定、8.3系が非該当であることを示している。

修正は、空欄へ新しい既定ロールを自動設定するものではない。8.1.54ではプロジェクト作成そのものをDesignerセッションからの操作に限定し、「Create Project Role(s)」に依存しない設計へ移った。このため、旧版と新版では確認すべき制御点が異なる。

Inductive Automationの 8.1.54公式リリースノート では、同版の公開日は2026年6月30日とされている。修正版はCVEの公表前から利用可能だったため、8.1系列を運用する組織は、まずパッチ番号まで含む実行バージョンを確認する必要がある。

更新できない旧版はロール設定で塞げる

恒久対応は8.1.54以降へ更新するか、互換性を確認したうえで最新の8.3系へ移行することだ。設備停止の調整やモジュールの互換性検証が必要で、直ちに更新できない8.1.53以前の環境には設定による暫定策がある。

旧版を維持する場合は、「Create Project Role(s)」を空欄のままにせず、Designer Roleと一致するロールを設定する。これにより、指定したロールを持つ利用者だけがプロジェクトを作成できる。勧告上、この設定は単なるリスク軽減ではなく、当該問題を設定だけで解消できる対策として示されている。

一方、ロール名を誤れば正規の設計担当者も作成できなくなる可能性がある。設定変更は通常の変更管理に載せ、現在のDesigner Role、利用者へのロール付与、変更後の作成可否を確認するのが妥当だ。これは脆弱性の成立条件を外す作業であり、8.1.54で導入された作成経路の変更と同じものではない。

運用確認は三つのバージョン群に分ける

資産台帳に「Ignition 8.1」としか記録されていない場合、今回の対象判定には不十分だ。本番Gatewayだけでなく、待機系、検証環境、災害復旧用の環境も含め、実行中の正確なバージョンと設定値を取得する必要がある。

1. 8.1.53以前：「Create Project Role(s)」が空欄かを確認する。更新できる環境は8.1.54以降へ移行し、更新待ちの環境はDesigner Roleと一致するロールを明示する。
2. 8.1.54以降：更新済みであることをパッチ番号で確認し、プロジェクト作成がDesignerセッションに限定された新しい経路を前提に権限を点検する。
3. 8.3系：この脆弱性の対象外として区分する。ただし、8.1系と8.3系が同じ組織内に混在する場合は、Gatewayごとに判定を残す。

8.1.53以前については、認証可能なアカウントとGatewayスクリプトを実行できる主体も棚卸しの対象になる。共有アカウントや不要になったアカウントが残っていれば、設定が空欄であることと組み合わさって攻撃条件を満たす可能性があるためだ。

既知の悪用はなくても、対象判定は設定まで必要

現時点で確定しているのは、8.1.53以前が影響を受け、8.1.54では作成経路が変更され、8.3系は影響を受けないという境界だ。旧版を残す場合も、「Create Project Role(s)」へ適切なロールを設定すれば、この問題には対処できる。

公表時点で既知の公開悪用は確認されていないが、それは空欄設定を維持してよい理由にはならない。運用上の焦点は、未認証侵入として一括処理することではなく、バージョン、認証、Gatewayスクリプト実行能力、ロール設定という条件をGatewayごとに照合し、更新済みか設定で解消済みかを記録することにある。