加速器や研究設備の制御に使われるオープンソースの制御ソフトウェア「EPICS Base」で、7.0.10以前に影響する脆弱性4件が公表され、修正版の7.0.11が出ました。見つけたのは人ではなく、自律型のAIエージェントです。この記事では公表された事実を整理したうえで、EPICS Baseの脆弱性に何をすべきか、そして制御系にOSSを組み込んで納品する開発会社は何を見直すべきかを、システム開発会社の代表として考えます。
要点 (事実のみ)
- 米CISAは2026年10月27日、アドバイザリ「ICSA-26-300-01」でEPICS Base 7.0.10以前の脆弱性4件を公表した。修正は7.0.11で提供されている。いずれも認証やユーザー操作なしにネットワーク経由で悪用されうるとされる。
- 4件の内訳は、CVE-2026-114595 (CVSS v3.1 9.8、整数オーバーフローによるヒープ領域外への書き込み。リモートコード実行の可能性)、CVE-2026-114596 (8.2、メッセージ長の検証不備による領域外書き込みとプロセスのクラッシュ)、CVE-2026-114597 (7.5、境界チェック不足による領域外読み取り)、CVE-2026-114598 (7.5、型の混同によるサービス拒否と隣接メモリの露出の可能性)。
- 発見したのはCausal Security社の自律型AIエージェント「Cipher」。The Registerによると、4件の特定からエクスプロイトの検証までにかかった時間は3時間49分だった。
- EPICSはロスアラモス国立研究所とアルゴンヌ国立研究所が開発したツールキットで、アルゴンヌのAdvanced Photon SourceやITERの核融合炉の制御を含む、世界で約90の科学・大学・産業プロジェクトで使われている。
- 悪用にはEPICSのサービスにネットワークで到達できることが前提になる。公開時点でCISAに悪用の報告はなく、CVE-2026-114595のリモートコード実行も「可能性」としての記述にとどまっている。
徐 聖博の見解
「3時間49分」は、発見の速さより「更新の遅さ」を浮かび上がらせる数字だ
私は研究出身なので、こうした数字はまず条件から読みます。今回の対象はソースコードが公開されたOSSで、攻撃の前提はEPICSのサービスにネットワークで届くことです。リモートコード実行も、記事上は検証済みとまでは書かれていません。「AIが数時間で制御システムを乗っ取れる」と受け取るのは言い過ぎです。
それでも、この数字は軽く見ないほうがよいと考えています。広く使われてきたOSSの欠陥を、AIエージェントが4時間弱で見つけて検証まで進められる。見つける側のコストがここまで下がると、脆弱性が公表される頻度は上がります。一方で、直す側の時間は変わりません。制御系の更新は、設備を止める日を決め、周辺の機器やクライアントとの動作を確かめてからでないと入れられないからです。見つかる速さと直せる速さの差が開いていく、というのが私の読み方です。
7.0.11 にすぐ上げられない現場で、先にやること
制御系では「修正版が出たから今夜更新する」は通常できません。だから更新までの間の手当てを先に決めておく必要があります。今回の脆弱性はネットワークで届くことが前提なので、効くのは次の3つです。
- どの装置・どのベンダー製品にEPICS Baseが入っているかを洗い出し、バージョンを確認する。 自社で入れたものだけでなく、装置メーカーが組み込んで納めたものも対象です。
- EPICSのサービスに届く経路を絞る。 インターネットから届かないことはもちろん、社内ネットワークからも、制御に必要な端末以外が届かない状態にします。リモート保守の経路があれば、それも含めて確認します。
- 更新日と、更新の前に確かめる項目を決める。 止められる日が先にしか取れないなら、それまで経路を絞り続けることを決めておきます。
2と3は技術の話に見えますが、実際には「誰が設備を止めてよいと判断するか」で止まることが多いはずです。この点は、先日取り上げた 製造業のOTセキュリティで予算と責任が分断している問題 と同じ構造です。
開発会社の事業判断にどう効くか
EPICSを直接扱う開発会社は多くないと思います。ただ、この件は「制御系に限らず、納めたシステムに組み込んだOSSを誰が追いかけるのか」という問いを、開発会社に突きつけています。
まず、組み込んだOSSの一覧を納品物に含めるべきだと私は考えています。今回、最初にやるべきことは「どこにEPICSが入っているか」の確認でした。納品した側がその一覧を持っていなければ、顧客から「うちのシステムは大丈夫か」と聞かれたときに即答できません。依存の一覧と、それぞれのバージョンを答えられることは、保守を任される会社の基本的な価値になります。
次に、OSSの更新判断を保守契約の定常作業として見積もることです。AIで脆弱性が見つかる頻度が上がるなら、「重大な脆弱性が出たら都度相談」という契約では、毎回が臨時対応になります。公表を確認し、影響の有無を判断し、検証して更新するまでを、あらかじめ工数として持っておく。止められない設備を相手にするシステムほど、更新の段取りを先に組んでおくことが、結果的に安くつきます。
最後に、作る側としての話です。ネットワークから受け取るデータの長さや型を信用しない、という今回の4件に共通する教訓は、制御系だけのものではありません。AIエージェントで脆弱性を探す手段は、攻撃側だけでなく私たち作る側も使えます。出荷前に同じ手段で自分たちのコードを調べておくほうが、出荷後に他人に見つけられるより確実に安いと考えています。
まとめ
EPICS Baseの4件は、公開時点で悪用は報告されておらず、修正版も出ています。必要なのは、入っている場所の確認、ネットワーク経路の制限、そして更新の段取りです。そのうえで開発会社は、AIで脆弱性が見つかる速度が上がる前提に立ち、組み込んだOSSの一覧と更新作業を、納品と保守の中に最初から組み込んでおくべきだと私は考えています。
関連して読んでいただきたい記事:
- 製造業のOTセキュリティ、IT部門と工場の間で予算と責任が分断している問題
- 冷蔵設備へのサイバー攻撃｜更新が止まった接続機器を誰が管理するか
- ゼロデイの攻撃成立は9〜20時間、KEV登録は5日｜中小企業が今すぐ捨てるべきパッチ運用の前提
出典: EPICS Base Release 7.0.11 (EPICS / Argonne National Laboratory)
参考: CISA ICS Advisory ICSA-26-300-01: EPICS Base / AI 'hacker' finds 4 severe bugs in popular industrial control software in under 4 hours (The Register, 2026-10-27)
