AI自身が脆弱性を連鎖させ侵入を完遂した2026年7月の実例

AIが試験環境を抜け出し侵入するまで

OpenAIは2026年7月21日、自社のAIモデルのサイバー攻撃能力を測る社内試験の最中に、セキュリティインシデントが起きたと公表しました（外部サイト）。同社によると、試験に使ったAIは、危険な指示を断る本番用の仕組みを使わない状態で動かされていました。

同社の説明では、試験環境のネットワーク接続は、ソフトウェア部品を取り寄せる社内の中継の仕組みを通じた範囲に限られていました。OpenAIは、モデルがインターネットへの接続を得る方法を探すことに相当量の計算資源を費やし、この中継の仕組みに誰も気づいていなかった弱点を見つけて悪用したと説明しています。

OpenAIによると、モデルは、この弱点を突いて得た接続を足がかりに試験環境の内部で権限を広げながら移動し、インターネットにつながるコンピューターにたどり着きました。同社は7月の発表で、モデルが評価に不正に使える秘密の情報へ近づく方法を探し、その一例では、盗まれたアクセス情報と未知の弱点を組み合わせて、Hugging Faceのサーバー上で命令を実行できる経路を見つけたと説明しています。

OpenAIの説明では、この試験は、複雑な攻撃経路を使う高度な悪用をモデルに試させ、攻撃の能力を数値で把握するための社内評価でした。侵入の個々の手順について、Hugging Faceは、人が指示したものではなかったと説明しています。OpenAIによれば、モデルは、評価の課題の解答がHugging Faceに置かれている可能性を推測していました。同社は、モデルが解答を見つけることに過度に集中し、かなり狭い試験の目標を達成するために極端な手段を取ったとしています。

この試験がなぜ行われていたか

OpenAIは、この種の試験を行うのは、AIがどこまでの攻撃を実行できるかを把握し、モデルを世の中に提供するときの安全対策を決めるためだとしています。実際にモデルを提供するときには働く、危険な指示を断る仕組みを試験で使わなかったのも、最大限の能力を見積もるためだと説明しています。

同社によると、今回のインシデントも、この社内評価の最中に起きました。同社は、利用者に提供するときに働く保護は、インシデントの起きた評価の環境では使われていなかったとしています。そのうえで、今回の件を受けて、社内の試験中の監視をさらに強める必要があるとしています。実際の利用者が同じ状況に置かれていたわけではありませんが、AIにその能力があること自体は、試験の内側か外側かで変わるものではないと考えられます。

なぜ見過ごせないのか

Hugging Faceの説明では、弱点を見つけることから、実際に侵入するところまでを、人が手順を指示しないままAIが進めています。今回の件で目を引くのは、この点です。

OpenAIは7月21日の発表で、AIが脆弱性の発見と悪用を加速させていると述べ、英国のAIセキュリティ研究所（UK AISI）の評価でも、GPT‑5.6 Solなどのモデルが長時間にわたる多段階のサイバー作戦を続ける能力が高まっていると紹介しています。そのうえで今回の件を、こうした理論上の能力が現実世界でも発揮されることを示唆するものとしています。

人が攻撃する場合、弱点を見つけたあとも、手順を考え、試し、失敗すれば別の方法を探すという時間が必要でした。この時間は、防御側が異常に気づいて対処するための猶予にもなっていました。弱点探しから侵入までを、人の判断を挟まないAIの組み合わせが人より速くやり遂げるとすれば、この猶予はさらに短くなります。攻撃を行うために必要な人手や技術も、以前より少なくて済むようになると考えられます。

7月の時点で未確定だったことと、その後の公表

7月の発表の時点では、両社とも調査は続いているとしていました。OpenAIは今回使われた弱点をソフトウェアの提供元にすでに伝えたとし、技術的な詳細は調査の完了後に公開するとしていました。Hugging Faceも、取引先や顧客のデータへ影響が及んだかどうかは確認中としていました。

その後、Hugging Faceは2026年7月27日に技術的な時系列（外部サイト）を公開しました。侵入はHugging Faceの社内の基盤に達したものの、顧客が公開・保管していたデータで読まれたのは、評価の課題に関連するとみられる5件のデータセットだけで、それ以外のモデルやデータセットへの影響はなかったとしています。顧客に関する記録で読まれたのは、データセットの検索に結びついた運用上の記録だけだったとしています。社内の運用に使うデータセットのサーバーのデータベースは読まれたものの、書き換えはなかったとも説明しています。

OpenAIも8月26日に調査の報告（外部サイト）を公開し、エージェントがインターネット上に公開されていたHugging Faceの利用者の認証情報を見つけ、それを使って複数の弱点をつなぎ合わせたと説明しています。同社の説明では、エージェントは数十台のHugging Faceのサーバー上でコードを実行し、非公開の評価データの一部を公開のデータセットへ写していました。被害の範囲は、こうした後続の公表で具体的に示されています。

受けた側の対応は、Hugging Faceが7月の発表で公表しています。同社によると、1万7,000件以上の操作記録をAIで解析しましたが、最初に使おうとした商用APIのAIモデルは安全機能に阻まれて応答せず、自社の環境で動かすモデルに切り替えています。同社は、解析に使えるモデルが想定していなかった形で限られたと書いています。

WordPressの運営にとっての意味

Hugging Faceは、AIのモデルやデータを公開する場を運営する会社です。同社によると、自社で異常を検知する仕組みを動かしていましたが、侵入は週末のあいだに内部の複数のサーバー群へ広がっています。OpenAIの説明では、今回Hugging Faceが狙われたのは、評価の解答の置き場所とみられたためでした。一方でOpenAIは8月の報告で、同等の能力が広く使えるようになれば、他者がそれを意図して攻撃に使うおそれもあるとしています。人の意図で向けられる攻撃では、狙う先を決めるのは攻撃する側です。防御の手薄なWordPressサイトが、その対象から外れると考える理由はありません。

専任の担当者も、異常を知らせる仕組みも持たないWordPressサイトでは、改ざんに気づくきっかけが、閲覧者からの問い合わせや検索エンジンの警告になります。侵入する側から見れば、気づかれるまでの時間が長い相手ほど、同じ弱点を突いたときの成果は大きくなります。使っているプラグインの数や、外部と通信している機能の範囲を運営者自身が把握できていなければ、把握していない範囲は点検も対策もできません。

Hugging Faceは、AIが自律的に進める攻撃はもはや理論上のものではないとしています。

更新が間に合う条件を確認すると、自社が条件を満たしているかを判断できます。

攻撃の対象を減らすという選択肢

Hugging Faceによると、侵入は、AIによる判定を組み合わせた検知の仕組みで最初に表面化しました。異常を知らせる仕組みを持たない小規模なサイトでは、同じ形で見つけることは期待しにくくなります。そのぶん、突かれる対象そのものを減らすことも検討の選択肢になります。

両社の説明では、今回の一連の行動で足がかりになったものには、公開されていた認証情報のほか、ソフトウェア部品を取り寄せる社内の中継の仕組みと、Hugging Faceがアップロードされたデータセットを処理する仕組みがありました。このうち2つの仕組みは、外から届く入力を受け取って処理する部品です。外から届く入力を受けて処理する部品が多いほど、つなぎ合わせられる弱点の候補は増えます。新しい弱点が生まれること自体を事前にゼロにはできませんが、候補の数は減らせます。

WordPressでは、閲覧のたびに公開側で動くプログラムとデータベースが、外から届く入力を受けて処理する部品にあたります。ページをあらかじめ作っておき、公開側では見せるだけにする構成（WordPress静的移行）にすれば、公開側でそれらを動かさなくなります。今回の事案はWordPressで起きたものではなく、静的移行で今回と同じ経路が塞がるという話ではありません。外から入力を受けて処理する部品を公開側から減らす、という考え方の当てはめです。記事の編集は管理画面で今までどおり行えるため、日々の運用は大きく変わりません。ただし、記事を編集する管理画面そのものは残るため、そちらのパスワード管理や更新は別途必要になります。