EPICS Base のヒープオーバーフロー、7.0.11 で修正 (CVE-2026-114595)

TL;DR

• 加速器や望遠鏡の制御システムを支えるオープンソースフレームワーク EPICS Base に 4 つのメモリ安全性の欠陥があり、認証なしのネットワークピアが Input/Output Controller のメモリを破壊できます。最も深刻な CVE-2026-114595 は CVSS v3.1 9.8（Critical）です。CISA は 2026 年 10 月 27 日に ICSA-26-300-01 を、Cipher Research は調査結果を公表しました。
• EPICS Base 7.0.10 以下のすべてのリリースが対象です。3 つは TCP 5064 のサーバー側 Channel Access 解析にあり、4 つ目は TCP 5075 のクラシック pvAccess 接続検証にあります。
• Cipher はサンドボックスでメモリ破壊とクラッシュを再現しましたが、コード実行は示していません。リモートコード実行は CISA が評価する潜在的影響です。悪用の報告はなく、4 つの CVE のいずれも 2026 年 11 月 3 日時点で CISA の KEV カタログに載っていません。
• 影響を受けるすべての環境を EPICS Base 7.0.11 に更新し、その前に古い Channel Access クライアントの動作を確認してください。「修正方法」にバックポートとネットワーク分離の手順があります。

影響を受けますか？

以下がすべて成り立つとき露出しています。

• EPICS Base 7.0.10 以下で構築された EPICS の Input/Output Controller（IOC）または別のサーバーを実行している。CISA の勧告は 7.0.10 以下のすべてのリリースを影響ありとしています。
• 攻撃者がサーバーのプロトコルポートに到達できる。Channel Access は TCP 5064（検出は UDP 5064）、クラシック pvAccess は TCP 5075（検出は UDP 5076）です。
• 認証情報は不要です。Cipher のテスト構成では特権アカウントは不要で、3 つの Channel Access の欠陥は TCP 接続と、書き込み経路ではチャネルのみを要求します。

IOC のアクセスセキュリティルールはこれを変えません。ルールはクライアントが読み書きできる内容を定め、不正な形式のメッセージの解析を安全にはしません。pvAccess の欠陥は接続検証中、そのやり取りが完了する前に到達します。

各設備ホストで何が動いているかを確認します。

# In each EPICS Base installation: the generated version header
grep EPICS_VERSION_SHORT <epics-base>/include/epicsVersion.h

# In each IOC application directory: which EPICS Base it builds against
grep -n "EPICS_BASE" configure/RELEASE

# On the IOC host: which processes serve Channel Access and pvAccess
ss -tlnp | grep -E ':5064|:5075'

ベンダー製のコントローラやビームラインパッケージにも EPICS Base が組み込まれていることがあります。これらも棚卸ししてください。Cipher が指摘するとおり、ある設備は内製アプリケーション経由で EPICS を動かし、別の設備はベンダー機器の中に組み込まれた形で受け取ります。

修正方法

まず更新し、次に欠陥を露出させていたプロトコルの到達可能性を確認します。

1. 影響を受ける 7.0 系列の環境をすべて、EPICS のリリースページから EPICS Base 7.0.11 に更新します。保守者は、強化された Channel Access サーバーを古いクライアントプログラムでテストしていないと明示しています。本番投入前にレガシークライアントを十分に検証してください。
2. 7.0.11 に移行できない旧系列では、上流の 2 つの修正をバックポートします。epics-base pull request 934 と pvDataCPP pull request 109 です。epics-base pull request 934 は、2017 年より前のリリースへのバックポートには commit e430d09 も必要だと記しています。
3. 展開中はプロトコルポートを必要な制御ホストに限定します。CISA の推奨施策が適用されます。制御システムをインターネットに置かない、ビジネスネットワークから分離する、必要なリモートアクセスには最新版の VPN を使う。
4. EPICS を製品に組み込んでいる場合は、そのコピーが影響を受ける Channel Access またはクラシック pvAccess のコードを含むか確認してください。Cipher が下流の保守者に勧めるように、バージョン別のガイダンスまたはバックポートを顧客に公表してください。

ポートを閉じるのは露出の低減で、更新の代わりにはなりません。修正が入るまで、IOC は正当なクライアントからのメッセージを脆弱なコードで解析し続けます。

根本的な原因は何ですか？

Channel Access サーバーは、メッセージのサイズ計算と変換でヘッダー由来の要素数と長さを信頼しています。クラシック pvAccess のデシリアライザーは、復号した要素を包含配列が宣言する型へ、その型を持つかの確認なしにキャストします。

Channel Access は EPICS の元々のクライアントサーバープロトコルです。サーバー側実装の RSRV は各リクエストヘッダーを caHdrLargeArray 構造体に読み込み、その m_dataType、m_count、m_postsize フィールドはそのままネットワーク由来で、modules/database/src/ioc/rsrv/camessage.c で処理します。7.0.10 の書き込み経路では、これらのフィールドをチャネルや実際に到着したペイロードと突き合わせる処理がありません。

// epics-base/modules/database/src/ioc/rsrv/camessage.c at R7.0.10 (write_action)
status = caNetConvert (
    mp->m_dataType, pPayload, pPayload,
    FALSE /* net -> host format */, mp->m_count );

変換は、チャネルが保持する要素数やリクエストが実際に運んだバイト数に関係なく、受信バッファから m_dataType 型の要素を m_count 個消費します。メッセージ振り分けループも、未検証の 32 ビット算術でサイズを組み立てています。

// epics-base/modules/database/src/ioc/rsrv/camessage.c at R7.0.10 (camessage)
msg.m_postsize  = ntohl ( pLW[0] );
msg.m_count     = ntohl ( pLW[1] );
msgsize = msg.m_postsize + sizeof(*mp) + 2 * sizeof ( *pLW );

4 つの CVE はそれぞれこの信頼の帰結であり、Cipher の分析は次のように整理しています。

• CVE-2026-114595（CVSS v3.1 9.8、CWE-190）: 書き込みリクエストの要素数が要素サイズと上限なしで組み合わされ、計算が 32 ビット算術をオーバーフローして、続く変換に対して割り当てが小さくなります。AddressSanitizer 下では、攻撃者が制御するバイト列によるヒープバッファーオーバーフロー書き込みが生じました。
• CVE-2026-114596（CVSS v3.1 8.2、CWE-190）: 32 ビット上限に近い拡張ヘッダーのペイロード長が計算サイズをラップさせて過大チェックを通し、後続のチャネル生成経路が終端バイトを境界外に書き込みます。
• CVE-2026-114597（CVSS v3.1 7.5、CWE-130）: 宣言された要素数が受信ペイロードを超え、変換が受信バッファの先まで進む境界外読み取りになります。
• CVE-2026-114598（CVSS v3.1 7.5、CWE-843）: pvDataCPP の FieldCreate::deserialize で、構造体配列または共用体配列の記述が異なる型の要素とともに受け入れられ、ポインタを含むフィールドも含めて誤ったレイアウトで解釈されます。

どのように悪用されますか？

公開された PoC はありません。Cipher は再現ペイロードを公開しておらず、上流のパッチが各修正で閉じた内容の唯一の公開記録です。以下の手順は、分析が述べるメカニズムです。

1. 攻撃者は IOC の Channel Access ポートに通常の TCP 接続を開き、大きい要素数と型を宣言した書き込みリクエストのヘッダーを送ります。
2. 要素数と要素サイズが 32 ビット算術でラップして組み合わされ、サーバーはその後処理するデータに対して小さすぎるメモリを割り当てます。
3. 攻撃者のペイロードの変換がその小さい割り当ての中へ進みます。AddressSanitizer 下では、攻撃者が制御するバイト列によるヒープバッファーオーバーフロー書き込みと、その後のプロセスクラッシュが生じました。
4. 拡張ヘッダーの変種は 32 ビット上限に近いペイロード長を宣言し、サイズチェックがラップします。後続のチャネル生成経路が利用可能なメモリの先へ終端バイトを置き、制約付きの境界外書き込みになります。
5. 読み取りの変種はペイロードが保持するより多くの要素を宣言し、pvAccess の変種は認証が完了する前の初期接続検証で、構造体配列の記述の中に誤った型の要素を送ります。どちらも境界外読み取りとしてサーバースレッドをクラッシュさせます。

攻撃の流れはどうなりますか？

Channel Access ポートへの認証不要の書き込みリクエスト 1 件が、ラップしたサイズ計算を通じて IOC のヒープを破壊します。

攻撃者は何ができますか？

実証された影響はメモリ破壊とサービス拒否で、いずれも Cipher が AddressSanitizer またはデバッガー下で再現しました。

• CVE-2026-114595 は、攻撃者が制御するバイト列によるヒープバッファーオーバーフロー書き込みを生じさせました。これはリモートコード実行が構築される元になるクラスです。CISA はこの欠陥を潜在的なコード実行の影響つきで Critical と評価しています。Cipher は実証エクスプロイトを構築しておらず、製品ビルドでの破壊の信頼性も評価していません。
• CVE-2026-114596 は制約付きの境界外書き込みで、計算で定まるオフセットに固定のバイト 1 つを書きます。結果はリモートからのクラッシュであって、汎用の書き込みプリミティブではありません。
• CVE-2026-114597 と CVE-2026-114598 は境界外読み取りです。Cipher はクラッシュを確認し、リモートクライアントへのメモリ内容の漏えいは実証していません。

IOC をクラッシュさせること自体に運用上の影響があります。IOC はより大きな装置の中で機器の監視、データ取得、制御を担います。分析が指摘するとおり、中断により運転者や自動化から観測や制御機能が奪われる可能性があります。その先は設備のアーキテクチャー次第です。冗長性、フェイルセーフ挙動、独立した保護インターロックが影響範囲を決めます。

条件は TCP ポートの到達可能性と、書き込み経路ではチャネルです。Cipher のテスト構成では特権アカウントは不要でした。

なぜ修正が効くのですか？

7.0.11 には epics-base pull request 934 と pvDataCPP pull request 109 が含まれ、それぞれが自分の欠陥が使った検証の隙間を正確に閉じます。書き込み経路は型を検証し、要素数を上限で抑え、計算サイズを実際に到着したペイロードと比較します。

 # epics-base/modules/database/src/ioc/rsrv/camessage.c (write_action, PR 934)
-    pciu = MPTOPCIU(mp);
+    pciu = MPTOPCIU(mp, client);
     if(!pciu){
         logBadId(client, mp, pPayload);
         return RSRV_ERROR;
     }
+
+    if (INVALID_DB_REQ(mp->m_dataType)) {
+        log_header ("bad put data type", client, mp, pPayload, 0);
+        return RSRV_ERROR;
+    }
+    if (mp->m_count > dbChannelFinalElements(pciu->dbch)) {
+        mp->m_count = dbChannelFinalElements(pciu->dbch);
+    }
+
+    size = dbr_size_n (mp->m_dataType, mp->m_count);
+    if (size > mp->m_postsize) {
+        return RSRV_ERROR;
+    }

メッセージ振り分けループは、サイズ算術をラップさせる拡張長を拒否するようになりました。

 # epics-base/modules/database/src/ioc/rsrv/camessage.c (camessage, PR 934)
             msg.m_postsize  = ntohl ( pLW[0] );
             msg.m_count     = ntohl ( pLW[1] );
+            if (msg.m_postsize >= ca_uint32_max - (sizeof(*mp) + 2 * sizeof ( *pLW ))) {
+                if(CASDEBUG>0) {
+                    errlogPrintf("Client ext msg size too large 0x%08x\n",
+                                 (unsigned)msg.m_postsize);
+                }
+                status = RSRV_ERROR;
+                break;
+            }
             msgsize = msg.m_postsize + sizeof(*mp) + 2 * sizeof ( *pLW );

pvAccess の型混同は、キャストの前に復号した要素の実際の型を検証して閉じられ、デシリアライズの再帰にも上限が付きました。

 # pvDataCPP/src/factory/FieldCreateFactory.cpp (FieldCreate::deserialize, PR 109)
-            StructureConstPtr elementStructure = std::tr1::static_pointer_cast<const Structure>(control->cachedDeserialize(buffer));
+            StructureConstPtr elementStructure = std::tr1::dynamic_pointer_cast<const Structure>(control->cachedDeserialize(buffer));
+            if(!elementStructure)
+                throw std::invalid_argument("Expected Structure");

pull request 934 は、同じ要素数の上限とペイロード突き合わせを、読み取り、イベント追加、書き込み通知の各経路にも適用します。チャネル検索は別クライアントが作った識別子も拒否するようになり、3 つの Channel Access の欠陥が 1 つの変更セットでカバーされます。pull request 自身の説明もこれと一致します。関連するヘッダーフィールド msgsize、dtype、count を突き合わせ、第一に整数オーバーフローを避ける、としています。

侵害されたかどうかを確認するには？

公開された侵害指標はありません。再現ペイロードも攻撃トラフィックも公開されていないためです。失敗した試行は、クラッシュ以外に何も残さないことがあります。

• プロトコルポート周辺での説明のつかない再起動やプロセスクラッシュについて、IOC ホスト上の core ファイルも含めて可用性記録を確認します。
• ファイアウォールやフローのログで、クラッシュに先立つ TCP 5064 または TCP 5075 への、そして UDP 5064 と 5076 の検出への、予期しない発信元からの接続を探します。
• IOC が管理、リモートアクセス、研究、ゲスト、ブリッジの各ネットワークセグメントから到達可能だったか確認します。Cipher はこれらを再確認すべき経路として明示しています。
• 確認された境界外イベントの影響は、検査するまで不明と扱います。公開ペイロードがないため、クラッシュを狙った試行と悪用の試行を区別できる指紋はありません。

タイムライン

• 2026-06-09: Causal Security が 4 つの発見を EPICS のセキュリティチャネルに報告し、CVE の割り当てと下流への通知について CISA と調整します。
• 2026-07-23: Channel Access の強化、epics-base pull request 934 が、Cipher の Shubham Raj による機密報告と重複する非機密報告のあと、7.0 ブランチへマージされます。
• 2026-08-10: pvAccess の型混同の修正、pvDataCPP pull request 109 がマージされます。
• 2026-10-26: base-7.0.11.tar.gz とその署名が 7.0 ブランチから作成されます。
• 2026-10-27: EPICS Base 7.0.11 がリリースされ、CISA が勧告 ICSA-26-300-01 を、Cipher Research が分析を公表します。

FAQ

リモートコード実行は実証されていますか？

いいえ。CISA の勧告は最も深刻な欠陥が「may result in memory corruption, denial of service, or potential remote code execution」と述べ、Cipher のサンドボックスは攻撃者が制御するバイト列によるヒープバッファーオーバーフロー書き込みを生じさせました。Cipher は実証エクスプロイトを構築しておらず、製品ビルドでの破壊の信頼性も評価していません。コード実行は評価された可能性のままです。

4 つの CVE のいずれかが実環境で悪用されていますか？

悪用の報告はなく、4 つのいずれも 2026 年 11 月 3 日時点で CISA の Known Exploited Vulnerabilities カタログに現れません。4 つの CVE レコードには CISA ADP の評価ブロックもなく、引用できる SSVC の悪用マーカーはありません。

IOC のアクセスセキュリティルールはこれらの攻撃を防げますか？

いいえ。アクセスルールはクライアントが読み書きできる内容を定め、pvAccess の接続検証プロトコルは認証を提供します。Cipher はどちらも修正の代わりにならないと述べます。この制御は不正な形式のメッセージの解析を安全にせず、pvAccess の欠陥はそのやり取りが完了する前の接続検証中に到達します。

7.0 系列ではなく EPICS Base 3.15 を使っています。影響を受けますか？

はい。CISA の勧告は EPICS Base 7.0.10 以下のすべてのリリースを影響ありとしています。3.15 系列のリリースは修正を含みません。epics-base pull request 934 と pvDataCPP pull request 109 をバックポートしてください。前者は 2017 年より前のリリースには commit e430d09 も必要だと記しています。ベンダー製のスタックにはベンダーのバックポートが必要です。

更新で古い Channel Access クライアントが壊れる可能性はありますか？

ありえます。7.0.11 のリリースページは、保守者が強化された Channel Access サーバーを古いクライアントプログラムでテストしていないと述べ、本番投入前に十分な検証を勧めています。レガシークライアントの棚卸しを手元に置いて展開を計画してください。

誰がどのようにこれらの欠陥を見つけたのですか？

Causal Security の自律セキュリティシステムである Cipher の Shubham Raj が、未知のコードベース上で 4 つすべてを 3 時間 49 分で発見し検証しました。調査に人の介入は不要で、唯一の人の手は、隔離サンドボックス内でのより深い実証性テストを許可する 1 つの指示でした。

Ostorlab で露出した制御システムサービスを見つける

Ostorlab の攻撃面探索は、指定範囲のインターネット公開ホストを棚卸しします。更新ウィンドウを計画する前に、Channel Access または pvAccess のポートで応答するすべてのホストを把握してください。Ostorlab でスキャンを始めると、どのサイトを先に修正すべきかがわかります。

参考文献

• CISA 産業制御システム勧告 ICSA-26-300-01「EPICS Base」、2026 年 10 月 27 日公開、4 つの CVE の説明、CVSS ベクトル、修正リンクを含む: https://www.cisa.gov/news-events/ics-advisories/icsa-26-300-01 （2026 年 11 月 3 日確認）
• Cipher Research、Causal Security、「Inside EPICS Base: Four severe vulnerabilities discovered autonomously in under four hours」、2026 年 10 月 27 日公開、欠陥ごとのメカニズム、ポート、開示タイムラインを含む: https://causalsecurity.com/research/epics-base-security-research （2026 年 11 月 3 日確認）
• CVE-2026-114595 レコード、CVSS v3.1 9.8 と v4.0 9.3: https://www.cve.org/CVERecord?id=CVE-2026-114595 （2026 年 11 月 3 日確認）
• CVE-2026-114596 レコード、CVSS v3.1 8.2 と v4.0 8.8: https://www.cve.org/CVERecord?id=CVE-2026-114596 （2026 年 11 月 3 日確認）
• CVE-2026-114597 レコード、CVSS v3.1 7.5 と v4.0 8.7: https://www.cve.org/CVERecord?id=CVE-2026-114597 （2026 年 11 月 3 日確認）
• CVE-2026-114598 レコード、CVSS v3.1 7.5 と v4.0 8.7: https://www.cve.org/CVERecord?id=CVE-2026-114598 （2026 年 11 月 3 日確認）
• epics-base pull request 934「RSRV message validation」、2026 年 7 月 23 日マージ、2017 年より前へのバックポート注意書き付きの Channel Access 修正: https://github.com/epics-base/epics-base/pull/934 （2026 年 11 月 3 日確認）
• pvDataCPP pull request 109、pvAccess の型検証と再帰上限の修正、2026 年 8 月 10 日マージ: https://github.com/epics-base/pvDataCPP/pull/109 （2026 年 11 月 3 日確認）
• EPICS 7.0.11 リリースページ、2026 年 10 月 26 日、旧クライアント相互運用の警告とダウンロードリンクを含む: https://epics-controls.org/resources-and-support/base/epics-7/7-0-11/ （2026 年 11 月 3 日確認）
• EPICS Base R7.0.11 の GitHub リリース、2026 年 10 月 27 日公開: https://github.com/epics-base/epics-base/releases/tag/R7.0.11 （2026 年 11 月 3 日確認）
• 脆弱なソース、タグ R7.0.10 の camessage.c、根本原因の節で引用: https://github.com/epics-base/epics-base/blob/R7.0.10/modules/database/src/ioc/rsrv/camessage.c （2026 年 11 月 3 日確認）
• CISA の Known Exploited Vulnerabilities カタログ JSON フィード、4 つの CVE を検索し 2026 年 11 月 3 日時点で一致なし: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json （2026 年 11 月 3 日確認）