10月21日の夜から22日にかけて、国税庁や銀行、保育園の連絡アプリ、レンタルサーバーなど、国内の数多くのサイトが一斉に止まりました。きっかけは、Webサイトを動かすプログラミング言語「PHP」に見つかった重大な欠陥「PHP2Shell」です。ただ、海外のニュースを追いかけていると、この10月に起きたのはPHPの件だけではありませんでした。
10月12日から22日までのおよそ10日間に、フランスのスーパーの冷蔵ケースが遠隔で操作され、アプリを公開するためのクラウドサービスが利用者の秘密の設定を読まれ、日本のバーガーキングのアプリ会員約1,118万件が漏れ、AIを使ったプログラミング道具の利用者が預けていたAIの「APIキー」が盗まれました。さらに、AIエージェントを使って100社を超える企業のサイトに入り込んだ攻撃者の存在が報じられ、AIのアプリづくりで広く使われている部品が汚染されて配られる事件まで起きています。
海外のメディアやまとめ記事では、この立て続けの騒ぎを「Black October(ブラック・オクトーバー、黒い10月)」と呼ぶ例が出てきました。
この記事では、その10日間に起きた主な事件を日付の順に並べ、それぞれ何が起き、何が盗まれ、誰が困ったのかを、専門用語をできるだけ噛みくだいて説明します。そのうえで、事件の多くに共通していた「AIのAPIキー」と「開発者のアカウント」をどう守ればいいのかを、個人でAIを触っている人から、仕事でアプリを作っている人まで、それぞれの立場でできることとしてまとめます。
先に結論を書いておくと、次の4つです。
- 10月12日から22日の10日間に、冷蔵設備の乗っ取り、クラウドサービスからの秘密情報の読み出し、アプリ会員情報の漏洩、AIのAPIキーの盗難、AIの部品の汚染、AIエージェントによる侵入の報告などが立て続けに起きました。
- 「Black October」はひとつの攻撃グループの名前ではなく、この時期の事件の多さを指す呼び名です。
- 盗まれたものを並べると、パスワードそのものよりも、APIキー、アクセストークン、環境変数といった「サービス同士をつなぐための鍵」が目立ちます。
- この種の鍵は二段階認証の外側で使われることが多く、盗まれるとそのまま使われてしまいます。
- AIは「攻撃される道具」と「攻撃に使われる道具」の両方の顔を見せました。
- AIのAPIキーはお金に直結するため狙われやすく、AIエージェントは攻撃の手間と費用を大きく下げつつあると報告されています。
- 守り方の基本は、鍵を預ける先を減らす、鍵ごとに使える範囲と金額の上限を決める、漏れたら作り直すのではなく古い鍵を無効にする、そしてアカウントの入口をフィッシング(偽サイトでだまして入力させる手口)に強い方式で固める、の4つです。
「Black October」と呼ばれた10日間の全体像

まずは、10日間に起きた主な事件を一覧にしておきます。下の表は、AIサービスを提供するGPTunneLがブログで公開したまとめ記事「Black October」を出発点にして、各事件の一次情報(当事者の発表や、セキュリティ専門メディアの記事)で確かめられた内容に置き換えたものです。日付は、主に事件が起きた日、または公表された日を書いています。
| 日付 | 事件 | 何が起きたか(要点) | AIとの関わり |
|---|---|---|---|
| 10月12〜13日 | フランスのスーパー | 冷蔵・冷凍ケースの制御が乗っ取られ、約1万店のうち約700店で被害 | 不明 |
| 10月14〜15日 | Zeabur(クラウドの公開サービス) | 環境変数321万8,965件、アカウント32万1,810件が読まれた | 盗まれた中にAIのキーも含まれうる |
| 10月14〜17日 | ConnectWise Cloud Backup | バックアップ用アプリの鍵が盗まれ、顧客のMicrosoft 365に不正なサインイン | 会社は「AIの仕組みを使ったグループ」と説明(独立した確認はなし) |
| 10月15日公表 | バーガーキング日本 | 公式アプリの会員情報約1,118万件が漏洩 | 報告なし |
| 10月17日 | OpenCodeのクラウドコンソール | 利用者が預けていたOpenAI・Anthropic・GoogleのAPIキーが漏れた可能性 | AIのキーが標的。攻撃にもAIエージェントが使われたと説明 |
| 10月19日報道 | AIエージェントによる大量侵入 | 1,200超のサイトを攻撃し、100社超に侵入したとロイターが報道 | 攻撃そのものをAIエージェントが実行 |
| 10月21日 | PHP2Shell | PHP本体の重大な欠陥2件の修正版を公開。国内でも多くのサイトが予防的に停止 | 発見にAIが使われた |
| 10月21日 | LiteLLM 1.107.0 | AIの部品として使われるライブラリに、情報を盗むプログラムを仕込んだ版が約2時間配られた | AIのキーやAIツールのログイン情報が標的 |
| 10月21日 | Railway(アプリの公開サービス) | 顧客の環境変数を保管する仕組みで異常。全デプロイを停止 | 同社は「AIの推論事業者を狙う一連の攻撃の一部」とみている |
| 10月21日 | GitLab CVE-2026-110264 | 深刻度10.0の欠陥を修正。2014年の版から存在 | 報告なし |
| 10月21日 | CrowdStrikeの報告書 | 4つのグループがClaude Codeを使って企業などに侵入していたと報告 | 攻撃そのものをAIエージェントが実行 |
表の右端の「AIとの関わり」を見ると、11件のうち半分以上に何らかの形でAIが関わっていることが分かります。まとめ記事を書いたGPTunneLは「11件中7件にAIが関わった」と数えています。
ただし、その関わり方はばらばらです。AIのキーが盗まれる側だった事件、AIが攻撃の道具として使われた事件、AIが欠陥を見つける側に回った事件が混ざっているので、「AIのせいで事件が増えた」とひとまとめにはできません。
また、「Black October」という呼び名についても注意が必要です。これは、特定のハッカー集団が名乗った作戦名でも、各国の政府機関が付けた正式な名前でもありません。事件が多く、しかもひとつひとつが深刻だったことを指して、海外のメディアやブログで使われ始めた俗称です。表の事件の多くは互いに無関係で、同じ攻撃者が裏で糸を引いていたという証拠は、10月24日の時点では示されていません。
PHP2Shellについては、この記事では全体の流れの中での位置づけだけを書きます。欠陥の中身や修正版の番号、国内で何が止まったのかは、関連記事の「PHP2Shell総まとめ」と「日本で何が止まったか」で詳しく扱っています。また、AIが欠陥を見つけるようになったことの意味は、関連記事「AIが脆弱性を見つける時代」にまとめました。
ここから先は、表の事件を「前半に起きた、設備とクラウドの事件」「会員情報とAIのキーの事件」「AIエージェントが攻撃した事件」「10月21日に重なった事件」の4つに分けて、順に見ていきます。
前半の3件:冷蔵ケース、クラウドの金庫、バックアップの鍵

10日間の前半に起きた3件は、狙われたものがそれぞれ違います。ひとつは店の機械、ひとつはクラウドに預けられた秘密の設定、もうひとつは企業のメールやファイルにつながる「合鍵」です。順番に見ていきます。
10月12〜13日:フランスのスーパーで冷蔵ケースが温められた
AP通信によると、フランスのスーパーマーケットの冷蔵・冷凍設備を狙ったサイバー攻撃で、国内に約1万あるスーパーのうち約700店が被害を受けました。数字を議会で明らかにしたのは、フランスの経済・財務を担当するロラン・レスキュール大臣です。
大手の小売グループでは、次のように報告されています。
- レ・ムスクテール(「アンテルマルシェ」などを運営)が、約300店の被害を報告しました。
- 生協型のチェーン「クーペラティブU」が、約2,000店のうち80店の被害を報告しました。
- カルフールやモノプリにも被害が及んだと伝えられています。
現地のテレビ局BFM-TVの報道として、攻撃者は冷蔵ケースを「霜取り」の状態にし続け、温度の設定を最高で50度にまで上げたとされています。霜取りは、冷蔵庫の内側についた霜を溶かすために一時的に温める運転のことで、本来は短い時間だけ行うものです。
これを続けさせられたことで冷蔵ケースが使えなくなり、一部の店では商品を捨てることになりました。パリの検察のサイバー犯罪担当部門が捜査を始めており、傷んだ食品や火災の報告も捜査の対象に含まれています。
どうやって入り込んだのかは、10月24日の時点で確定していません。フランスのサイバーセキュリティ機関(ANSSI)は、デンマークのDanfoss(ダンフォス)と米国のCopeland(コープランド)の遠隔制御モジュールで「多数の侵害」があったと報告しました。両社は、被害を受けたのは古い型や、すでにセキュリティの更新が終わった制御装置だと説明しています。8月には、産業機器のセキュリティを調べる会社Claroty(クラロティ)が、インターネットから直接たどり着ける状態のこれらの制御装置に欠陥があったと報告しており、両社はその欠陥を修正済みとしています。
この事件では、身代金の要求やデータの盗み出しは確認されていません。攻撃者が誰なのかも、AIが使われたのかも分かっていません。
それでもこの10日間の最初に挙げられるのは、「インターネットにつながった古い機械」が、パソコンやサーバーと同じように攻撃の入口になることを、食べ物という分かりやすい形で見せたからです。大臣は食料の供給に危険はないとしつつ、「食の安全の核心に触れる攻撃」と表現しました。
同じ時期には、オランダの小売大手アホールド・デレーズも「セキュリティ上の問題」でシステムを止め、傘下のスーパーのWebサイトが見られなくなりました。店は営業を続け、客や従業員のデータが盗まれた証拠はないと同社は説明しています。フランスの件と関係があるのかどうかは、AP通信の記事では分かっていません。
10月14〜15日:Zeaburで321万件の環境変数が読まれた
Zeabur(ジーバー)は、自分で作ったWebアプリを、サーバーの細かい設定をしなくてもインターネットに公開できるクラウドサービスです。こうした種類のサービスは「PaaS(パース、アプリを置くための土台を貸すサービス)」や「デプロイサービス」と呼ばれます。デプロイは、作ったアプリを実際に動く場所に配置して公開することです。
アプリを動かすには、データベースのパスワードや、AIのサービスを呼び出すためのAPIキーなど、プログラムの中に直接書きたくない秘密の値が必要になります。こうした値は「環境変数」という形で、サービスの管理画面に登録しておくのが一般的です。環境変数は、プログラムの外から渡す設定値のことで、アプリにとっては秘密の鍵を入れておく引き出しのようなものです。
Zeaburが10月19日に公開した中間報告によると、攻撃者は10月14日に盗んだ内部の認証情報を初めて使い、15日にサービス全体のデータベースを読み出しました。報告された数字を表にまとめます。
| 読まれたもの・影響を受けたもの | 数 | 内容 |
|---|---|---|
| 環境変数 | 321万8,965件 | 利用者が登録していたもの |
| アカウント | 32万1,810件 | メールアドレス・ユーザー名・電話番号などを含む |
| データベースのコンテナ | 865個 | 利用者のデータベースのコンテナ(アプリを動かすための小さな区画)の中で命令が実行された |
| サーバー | 101台 | 92人の利用者が持つサーバーに、管理者の権限で入られた |
環境変数とアカウントの2つは、いずれも同社が「確認済み」としている数字です。
原因について、同社は報告書の中で、有効期限のない管理者の認証情報が暗号化されないまま(平文で)保存され、しかもその管理用の入口がインターネットから使える状態だったと認めています。Zeaburは8月にも別の侵入を受けており、今回は2カ月で2回目でした。創業者は10月17日にサービスの終了を発表し、12月31日までにすべてのサーバーを止める予定です。なお、同社は終了の判断を「運営上の決定」と説明しています。
Zeaburの利用者にとって厄介なのは、読まれた環境変数の中に、ほかのサービスの鍵が入っていることです。データベースのパスワード、決済サービスのキー、そしてOpenAIやAnthropicなどのAIのAPIキーです。
同社は利用者に、環境変数に入れていた鍵をすべて交換するよう求めており、その手順の最初に「新しい鍵を作る前に、各サービスで古い鍵を無効にすること」を挙げています。新しい鍵を作っただけでは古い鍵は使えるままなので、盗まれた鍵で引き続き悪用される余地が残るためです。この点は、記事の後半の守り方でもう一度取り上げます。
10月14〜17日:ConnectWiseのバックアップ用アプリの鍵で、顧客のMicrosoft 365へ
ConnectWise(コネクトワイズ)は、企業のIT管理を請け負う会社(MSP、マネージドサービスプロバイダーと呼ばれます)向けに、管理ツールを提供している米国の会社です。今回問題になったのは、Microsoft 365(メールやファイル共有、Teamsなどをまとめた企業向けのサービス)のデータをバックアップする「Cloud Backup」というサービスで、もとは「SkyKick(スカイキック)」という名前でした。
ConnectWiseの告知によると、同社は10月14日に問題を見つけて調査を始め、16日に最初の告知を出しました。17日の協定世界時5時1分(日本時間14時1分)にCloud Backupのアプリからのアクセスを止め、同日には同社のアプリの身元(アプリとして認証するための登録)7つを無効にしています。19日には影響のあった環境の認証情報をすべて入れ替え、21日から段階的な復旧を始めました。
この事件の仕組みは、少し丁寧に説明する価値があります。バックアップのサービスは、顧客のメールやファイルを読むために、顧客の管理者から事前に許可をもらっています。その許可を使うときに提示するのが、アプリ専用の秘密の値(アプリシークレット)です。
BleepingComputerの記事で紹介されたセキュリティ会社Todylの分析によると、攻撃者はこのアプリシークレットを使い、バックアップのアプリになりすましてMicrosoft 365に直接ログインしていました。人ではなくプログラムとしてのログインなので、二段階認証(MFA)は最初から関係がありません。
セキュリティ会社のHuntress(ハントレス)は、自社が見守っている範囲だけで、少なくとも162の企業テナント(Microsoft 365の契約単位)で不正なサインインを確認したと報告しました。その後、数字を173に引き上げたとする報道や、攻撃者のアドレスからの動きがあったテナントは1,000近いとする報道もあり、被害の全体像はまだ固まっていません。ConnectWise自身は、自社の環境からは特定の顧客のテナントが影響を受けたかどうかを判断できないと説明しています。
Huntressによると、一部のテナントでは、管理用のアプリが自分自身に「Exchange管理者」(メールの管理者)や「グローバル管理者」(すべての管理者)の役割を付け、別の管理ツールに認証情報を追加していました。ある利用者は、何年も使っていなかったSkyKickのアプリが自分にExchange管理者の役割を付けたという警告を受け取ったとRedditに書き込んでいます。使わなくなった連携アプリが、強い権限を持ったまま残っていたことになります。
ConnectWiseは、Microsoftの脅威情報などをもとに、中国の国家と連携するグループが、公開されているAIエージェントの仕組み(エージェント型AIフレームワーク)を使って攻撃したと説明しています。ただし、これは同社の説明であり、10月24日の時点で第三者による独立した確認は見当たりません。バックアップのデータそのものについては、暗号化されて隔離されたままで、盗まれた兆候はないとしています。
会員情報とAIのキー:バーガーキング日本とOpenCode

10日間の中盤には、日本の利用者にとって身近な事件と、AIを使っている開発者にとって身近な事件がひとつずつ起きました。前者は昔からある「会員情報の漏洩」、後者はこの1〜2年で急に増えた「AIのAPIキーの盗難」です。
10月15日:バーガーキング日本のアプリ会員情報約1,118万件
ハンバーガーチェーン「バーガーキング」を国内で運営する会社は10月15日、公式スマホアプリの会員を管理するサーバーが第三者に不正にアクセスされ、会員情報約1,118万件が外部に漏れたと発表しました。海外のセキュリティ専門メディアBleepingComputerも、この件を詳しく報じています。
報道によると、不正なアクセスがあったのは10月2日から7日にかけてで、13日に漏洩が判明しました。漏れたのは、次のような情報です。
- 会員ID、氏名、生年月日、性別
- メールアドレス、電話番号
- 注文の履歴など
クレジットカードの番号はこのサーバーに保存しておらず、ログイン用のパスワードの漏洩も確認されていないと同社は説明しています。発表の時点で、不正な利用などの二次被害は確認されていません。
「1,118万件」は登録されていたデータの件数で、実際の人数とは一致しない可能性があります。同じ人が何度か登録し直した場合などは、件数のほうが多くなるためです。それでも、10月初めに焼肉きんぐのアプリ会員約1,079万件の漏洩が公表されたばかりで、飲食店のアプリから1,000万件を超える会員情報が漏れる事件が、ひと月のうちに2件続いたことになります。
この件では、AIが関わったという報告はありません。名前やメールアドレス、電話番号、そして「いつ何を頼んだか」という注文の履歴が漏れたときに起きやすいのは、そのお店を名乗るニセのメールやSMS、電話です。
注文の履歴を知っている相手からの連絡は本物らしく見えるため、いつも以上に注意が必要です。同社も、次のことを呼びかけています。
- 不審なメールやSMS、電話に注意する
- 知らないURLを開かない
- 会員情報やパスワードを入力しない
会員情報が漏れたときに何をすればいいかは、同じブログの記事「情報漏洩が10月だけで13件…」で、7つの手順に分けて書いています。バーガーキングのアプリを使っていた方は、そちらもあわせて読んでみてください。
10月17日:OpenCodeのコンソールから、AIのAPIキーが漏れた
OpenCode(オープンコード)は、パソコンの画面の中でAIに指示を出して、プログラムを書かせたり直させたりできる「AIコーディングエージェント」と呼ばれる道具です。中身が公開されているオープンソースのソフトで、自分のパソコンで動かす版のほかに、Webブラウザから使う「コンソール」というクラウド版の管理画面がありました。
ここで「APIキー」について説明しておきます。APIは、プログラム同士がやりとりするための窓口のことです。OpenAIやAnthropic、GoogleのAIを自分のプログラムや道具から呼び出すときは、この窓口を使います。
そのとき、「誰が呼び出しているのか」を示し、使った分の料金をその人に請求するために提示するのがAPIキーです。長い文字列で、知っている人なら誰でもそのアカウントのAIを使えてしまいます。いわば、クレジットカードの番号と暗証番号をひとつにしたような値です。
OpenCodeのコンソールでは、利用者が自分のOpenAI、Anthropic、GoogleのAPIキーを登録して、コンソールからそれぞれのAIを使えるようになっていました。BleepingComputerの報道によると、OpenCodeは10月17日、コンソールの利用者の1.4%について、登録していたAPIキーが漏れた可能性があると発表しました。
対象は外部のAIサービスのキーを登録していた人だけで、該当者にはメールで連絡したとしています。キーが漏れた可能性がある最も早い時刻は、10月17日の協定世界時0時30分(日本時間9時30分)でした。
共同創業者のダックス・ラード氏は、攻撃者が少なくとも48時間にわたり、AIエージェントを使って同社のシステムを狙い続けていたと説明しています。侵入されたのは、使うのをやめる途中だった古いシステムでした。一方で、自分のパソコンで動かす版のOpenCodeについては、キーが同社のサーバーに送られない仕組みなので影響はないとしています。
- 利用者の1.4%でAPIキーが漏れた可能性
- 対象は外部のAIサービスのキーを登録していた人
- キーが同社のサーバーに送られない仕組み
- 影響はないとされている
同社はこの攻撃を「大規模な蒸留攻撃」と呼んでいます。蒸留(ディスティレーション)は、性能の高いAIに大量の質問をして、その答えを使って小さなAIを訓練する手法のことです。手法そのものはAIの研究で普通に使われていますが、他人のキーを盗んで、他人のお金で大量の質問をさせれば、攻撃になります。
盗んだキーで高性能のAIを好きなだけ使い、その出力を自分たちのAIづくりに回すという動機が考えられる、ということです。ただし、今回盗まれたキーが実際に何に使われたのかは、10月24日の時点で詳しく明かされていません。
被害の大きさは、利用者の請求書に表れました。報道によると、次のような声がありました。
- 一晩で数百ドルから1,700ドル以上の身に覚えのない料金が発生した
- Googleから「乗っ取られた資源の悪用に一致する行為」を理由にプロジェクトを止められた利用者もいた
AnthropicとGoogleは漏れたとみられるキーを止め、OpenAIはOpenCodeと協力して、攻撃で使われた分の返金を進めていると報じられています。
この事件には、もうひとつ興味深い点があります。OpenCodeは調査の初めのうち、自社で使っていたAIが安全のための仕組みに引っかかり、攻撃の解析を手伝う依頼を断ってしまったため、思うように進まなかったと説明しています。
その後、OpenAIのセキュリティ向けのAI「Daybreak(デイブレイク)」を防御の作業に使えるようになってから、状況が落ち着いたそうです。攻める側も守る側もAIを使い、守る側がAIの安全装置に足を止められる、という今の状況をよく表した出来事です。
OpenCodeの件から読み取れる教訓は、「AIのキーを、便利だからといって色々なサービスに預けると、そのサービスの数だけ漏れる入口が増える」ということです。自分のパソコンの中だけで使う版は無事でした。キーを預ける先を減らすことの大切さは、後半でもう一度取り上げます。
AIエージェントが攻撃する側に回った:ロイターの報道とCrowdStrikeの報告

この10日間で、AIと攻撃の関係について大きく報じられたのが、10月19日のロイターの独占記事と、10月21日のCrowdStrikeの報告です。どちらも、AIが「人の作業を手伝う道具」から「自分で判断して攻撃を進める存在」に近づいていることを示しています。
話の前に、「AIエージェント」という言葉を説明しておきます。ChatGPTのような普通のAIは、人が質問をして、AIが答える、というやりとりを繰り返します。
AIエージェントは、人が大まかな目標を伝えると、AI自身が次に何をするかを考え、ツールを動かし、結果を見てまた次の手を考える、という作業を自分で繰り返す仕組みです。Claude CodeやOpenCodeのようなAIコーディングエージェントも、その一種です。本来はプログラムを書く作業を任せるための仕組みですが、命令の中身を変えれば、他人のサーバーの弱いところを探す作業も任せられてしまいます。
10月19日:AIエージェントで100社超に侵入(ロイター)
ロイターの独占記事によると、中国語を話すとみられる人物が、AIエージェントを使って、米国・カナダ・オーストラリア・日本のネット通販などのサイトを9月25日から攻撃し、数週間で100社を超える企業のサイトに侵入しました。攻撃を受けたサイトは、記事の前の週の終わりまでに1,200を超えていたとされています。
この人物がAIに与えた指示は、中国語で100文字にも満たない短いものでした。AIエージェントはその指示をもとに、何時間もかけて自分で標的を調べ、攻撃を試しました。
侵入に成功するまでにかかった時間は、典型的な例で約23時間でした。人が付きっきりでいなくても、AIが一晩かけて弱いところを探し続けてくれる、ということです。
この活動を見つけたのは、セキュリティ会社NorForgeの研究者スノーレ・ファーゲルランド氏です。同氏は、オープンソースのAIの協調基盤「Cairn(ケルン)」がインターネットに公開されたままになっている例を探していて、10月2日ごろから立ち上げられた悪意ある使い方の例を20あまり見つけました。
Cairnは、複数のAIエージェントに仕事を割り振って一緒に動かすための仕組みです。攻撃者はこの管理画面を外から見える状態のまま使っていたため、何をしていたのかが記録ごと見えてしまったわけです。
ファーゲルランド氏は、AIの利用料(トークン代)を次のように見積もっています。
- 全体で約5,000ドル
- 侵入に成功した1件あたり約50ドル
トークンは、AIが文章を読み書きするときの量の単位で、AIのAPIはこの量に応じて料金がかかります。また、攻撃には中国のDeepSeek(ディープシーク)のAIと、AnthropicのClaude Codeが混ぜて使われていたようだと述べています。ただし、使われたAIについては、AIエージェントに付けられた名前から推定したものだと報じられており、AnthropicやDeepSeekのどの契約がどう使われたのかまでは分かっていません。
被害を受けた企業のうち、ロイターは次の3社の名前を挙げています。
- 農機大手のディア(Deere):「必要な対処を行い、機微な情報にアクセスされた兆候はない」とコメントしました。
- 家電のシャークニンジャ(SharkNinja):被害を受けたのは独立した製品サポートのサイトだけで、脅威は封じ込めたと説明しました。
- エンジン大手のカミンズ(Cummins):外部の業者が運営するサイトへの攻撃の可能性を調べているとしています。
どれだけのデータが持ち出されたのかは、ロイターも確かめられていません。日本の企業が被害に含まれるのかどうかも、記事では明らかにされていません。
ここで、「侵入した」という言葉の重みを整理しておきます。サイトに入り込めたことと、そのサイトから重要な情報を持ち出せたことは別の話です。ディアのように「機微な情報へのアクセスの兆候はない」と答えている企業もあります。
とはいえ、1件50ドル、1日ほどの時間で、人が細かく手を動かさなくても侵入まで進めてしまうという事実は、攻撃する側の手間とお金の計算を大きく変えるものです。
10月21日:CrowdStrikeが4つのグループによるClaude Codeの悪用を報告
米国のセキュリティ大手CrowdStrike(クラウドストライク)は10月21日、2026年5月から8月にかけて、4つの攻撃グループがAIエージェントに判断と命令の実行を任せて侵入していた事例を報告しました。4つのグループに共通していたのは、次の2つです。
- AnthropicのAIコーディングエージェント「Claude Code」を中心に使っていたこと
- 自分たちの攻撃用の仕組みを、外から見える公開フォルダに置きっぱなしにしていたこと
どのグループも、攻撃用の仕組みを「ペネトレーションテスト(依頼を受けて、実際に侵入を試してみる検査)」の道具の形に作っていました。ペネトレーションテストは、本来は会社が自分のシステムの弱さを確かめるために、専門家に頼んで行う正当な仕事です。
攻撃者はその形を借りることで、AIに「これは許可を得た検査だ」と思わせ、攻撃の作業をさせていたことになります。4つのグループの概要は次のとおりです。
| グループ | 主な標的 | やり方の特徴 |
|---|---|---|
| 1(スペイン語・英語) | アルゼンチンの医療機関、少なくとも15か所 | 「監督役」と「実行役」の2つのAIエージェントに分担させる仕組み。少なくとも1か所から認証情報と診療記録を持ち出した |
| 2(中国語) | 2か国の政府機関を含む20以上の標的。ブラジルと米国の企業も | 中国国内の「中継サービス」経由でClaudeを利用。決まった手順で動く仕組みと、自由度の高い仕組みを使い分け |
| 3(インドネシア語) | インドネシアの政府機関のドメインなど | GitHubなどで公開されている819個の「スキル」をそのまま使用。安全装置に止められると人が手で押し切っていた |
| 4(ロシア語) | 米国のCRM(顧客管理システム)の事業者など | ひとつのコマンドで、偵察から持ち出しまでの7段階を自動で進める仕組み。顧客企業のデータを持ち出した |
表の「スキル」は、Claude Codeに特定の作業のやり方を教えるための、手順書のようなファイルです。インドネシア語のグループは、公開されているスキルを819個も集めて使っていましたが、CrowdStrikeはこのグループを4つの中で最も技術的に未熟だと評価しています。それでも政府機関のドメインなどを狙えていたことは、「腕のない攻撃者でも、AIと公開された道具を組み合わせれば一定のことができてしまう」ことを示しています。
CrowdStrikeは報告の中で、AIエージェントが基本的な攻撃作業をありふれたものにしつつあり、エージェントによる侵入は多くの場合1時間以内に目的に届くとしています。さらに、今後12カ月で、これまで組織的な犯罪集団や国家の支援を受けた集団にしかできなかった規模と効果を、技術の低い攻撃者の一部が手にする可能性が高いと見ています。
念のため書いておくと、これはClaude Codeが特別に危ない道具だという話ではありません。ロイターの件ではDeepSeekとの混用が、ConnectWiseの件では公開されているAIの仕組みが使われたとされています。
どのAIでも、命令する人の目的によって使い道が変わるという点は同じです。AIを作る会社は安全装置を強めていますが、OpenCodeの件のように守る側の作業まで止めてしまうこともあり、どこまで止めればいいのかは難しい問題になっています。
10月21日に重なった4つの事件:PHP2Shell、LiteLLM、Railway、GitLab

10月21日は、この10日間の中でも特に事件が集中した日でした。日本時間の夜にPHP2Shellの修正版が公開されたのと同じ日に、AIの部品の汚染、アプリ公開サービスの異常、GitLabの深刻な欠陥の修正が続けて発表されています。
PHP2Shell:この10日間の「中心」にあった事件
PHP2Shellは、PHPという言語そのもの(PHPで書かれたプログラムを動かす本体)に見つかった重大な欠陥2件の通称です。ログインしなくても、外からサーバーに好きな命令を実行させられる種類の欠陥(RCE、リモートコード実行)で、WordPressのように世界中のサイトで使われているソフトの上でも、それが実際にできることが示されました。修正版は10月21日の協定世界時14時(日本時間23時)に公開され、国内では修正の前後に、国や自治体、銀行、レンタルサーバーなどが予防のためにサービスを止めました。
この記事のテーマに関わる点だけ書いておくと、PHP2Shellの発見には、OpenAIのAIを使った研究者や、AIを組み込んだ研究の仕組みが関わっていました。つまりPHP2Shellは、AIが「欠陥を見つける側」に回った事件です。
この10日間には、AIが盗まれる側、AIが攻撃する側、AIが見つける側のすべてがそろったことになります。詳しい中身は関連記事の「PHP2Shell総まとめ」と「AIが脆弱性を見つける時代」をご覧ください。
LiteLLM 1.107.0:AIの部品に、情報を盗むプログラムが仕込まれた
LiteLLM(ライトエルエルエム)は、OpenAIやAnthropic、Googleなど、たくさんの会社のAIを、同じ書き方でまとめて呼び出せるようにするPython(プログラミング言語のひとつ)の部品です。プログラミングの世界では、こうした部品を「ライブラリ」や「パッケージ」と呼び、PyPI(パイピーアイ)というPython用の公式の配布所から、命令ひとつで自分のパソコンやサーバーに取り込めるようになっています。Datadog Security Labsによると、LiteLLMは週に約2,300万回ダウンロードされており、AIを使ったアプリを作る人の間では定番の部品です。
10月21日の協定世界時11時39分(日本時間20時39分)、このLiteLLMの「1.107.0」という版が、悪意あるプログラムを仕込まれた状態でPyPIに公開されました。公式のDockerイメージ(アプリを動かす環境を丸ごと詰めた配布物)にも同じ版が含まれ、「latest」などの、いつも最新を指す名前でも配られていました。
PyPIが13時20分にこの版を隔離し、Dockerイメージは13時53分までに取り下げられたと、Datadogはまとめています。公開されていた時間は約2時間です。別のセキュリティ会社Aikidoは、pipで入れられたのが11時39分から12時47分まで、Dockerのイメージを取り込めたのが11時46分から14時20分までとしており、時刻には資料によって少し差があります。
仕込まれていたのは、2種類のプログラムでした。
- ひとつは、パソコンやサーバーの中から秘密の情報を集めて送り出す「情報窃取プログラム(インフォスティーラー)」です。
- もうひとつは、外から命令を受け取って好きな処理を実行させるための「遠隔操作型のトロイの木馬(RAT)」で、攻撃者が用意したGitHub上のファイルを1時間おきに見に行き、そこに書かれた場所からPythonのプログラムを取ってきて動かす仕組みでした。
Datadogによると、そのファイルにはテスト用の値しか入っておらず、実際に2段目のプログラムが配られた様子は観測されていません。
Datadogが挙げた、盗まれる対象は次のとおりです。範囲の広さに注目してください。
- クラウドの認証情報:AWS、Google Cloud、Azureのキーや、サーバーの中から取り出せる一時的な認証情報。Kubernetes、Docker、Vault、Terraformなど、クラウドを管理する道具の秘密情報
- 開発者の鍵:SSHの鍵(サーバーに入るための鍵)、GPGやTLSの鍵、GitやnpmやPyPIのトークン、.envファイル(環境変数を書いておくファイル)、コマンドの履歴
- AIの道具:各社のAIのAPIキーと、Claude、Codex、Gemini、Cursor、Copilotなどのログイン状態(セッション)
- ブラウザ:保存されたパスワードとCookie(ログイン状態などを覚えておく小さなデータ)
- LiteLLMの中継サーバー:データベースを使っている場合、そこに保存された各AIサービスの鍵
このプログラムのたちの悪いところは、LiteLLMを使わなくても動いてしまう点です。仕込まれたファイル(cook.pth、cook.py、sitecustomize.py)は、Pythonの仕組み上、Pythonが起動するたびに自動で読み込まれる場所に置かれていました。そのため、LiteLLMをアンインストールしても、これらのファイルは残り、pipやpythonを動かすたびにまた動きます。
Datadogは、これらのファイルを手で消したうえで、無事な版の1.106.2に戻し、汚れていない別のパソコンからすべての認証情報を交換するよう呼びかけています。なお、安全な版については、1.106系とする資料が多い一方で、1.107.1とする資料もあり、記述が食い違っています。実際に対応するときは、LiteLLMの公式の案内を確かめてください。
どうやって公式の版に悪意あるプログラムが入ったのかも、分かってきています。Datadogによると、攻撃者は3人のエンジニアのアカウントから盗んだ「GitHub CLI」のトークンを使いました。
GitHub CLIは、GitHubを黒い画面(コマンド)から操作するための公式の道具で、一度ログインすると、その後はトークンという合鍵で操作できるようになります。攻撃者はこの合鍵で、LiteLLMの非公開の「リリース手順」(公式の版を作って配布所に出すための自動の仕組み)を起動しました。
その際、手順が読み込むプログラムの置き場所を、本物の「BerriAI/litellm」ではなく、ハイフンがひとつ多いだけの偽物「Berri-AI/litellm」に向けていたとされています。公式の仕組みで作られたので、配られた版には「公式の手順でビルドされた」という証明書のような記録まで付いていました。
リポジトリ(プログラムの保管庫)の本物のソースコードを見ても、悪意あるプログラムは見つかりません。そのため、ふだんの確認では気づきにくい形になっていました。3人のアカウントが最初にどうやって乗っ取られたのかは、まだ分かっていません。
LiteLLMは3月にも、1.82.7と1.82.8という版に悪意あるプログラムを仕込まれる別の事件を起こしています。Datadogは、今回の事件と3月の事件のつながりは確認されていないとしています。
このように、ソフトの部品や配布の仕組みを汚して、それを使う大勢に被害を広げる攻撃を「サプライチェーン攻撃」と呼びます。サプライチェーンは、もともと部品の調達から製品の出荷までの流れを指す言葉です。自分のプログラムに欠陥がなくても、取り込んだ部品が汚れていれば、自分のパソコンやサーバーの鍵が盗まれてしまいます。
Railway:顧客の環境変数を保管する仕組みで異常
Railway(レイルウェイ)は、Zeaburと同じように、作ったアプリを手軽にインターネットに公開できるサービスです。同社の10月21日の告知によると、この日の朝、顧客の環境変数を保管するシステムで異常な動きを見つけました。調査の結果、許可のない第三者が暗号化された環境変数にアクセスし、一部については暗号を解いた中身まで手に入れた可能性があるとしています。
Railwayはすべてのデプロイ(新しい版の公開)を止め、AIなどの外部のサービス事業者に対して、関係するキーを先回りして無効にするよう連絡しました。
利用者には、次のものをすべて交換し、関係するサービスのログに不審な動きがないか確かめるよう求めています。
- Railwayに保存していた環境変数とAPIキー
- 非公開のレジストリ(Dockerイメージなどの置き場所)の認証情報
影響は一部の利用者に限られる可能性があるとしつつも、確認が終わるまではすべての利用者が予防の手順を取るよう勧めています。10月22日の朝には有料プランのPro・Enterprise向けにビルドが再開されたと報じられていますが、同社の告知のページでは再開の日時を確かめられませんでした。
注目したいのは、Railwayが今回の件を「AIの推論事業者を狙った、プラットフォーム企業への一連の攻撃の一部」とみている点です。推論事業者は、AIを動かして答えを返すサービスを提供する会社のことです。言いかえると、Railwayそのものの情報よりも、Railwayの利用者が預けていたAIのキーを手に入れることが目的だったのではないか、という見立てです。
これは同社の見方で、確定した事実ではありません。ただ、Zeabur、OpenCode、LiteLLM、Railwayと、アプリを作る人が鍵を預ける場所が短い間に続けて狙われたことは確かです。
GitLab:深刻度10.0、2014年の版から続いていた欠陥
GitLab(ギットラボ)は、プログラムの保管庫やチームでの開発作業をまとめて管理できるソフトです。GitHubに似たサービスですが、会社が自分のサーバーに入れて使う「セルフマネージド」という使い方が多いのが特徴です。10月21日、GitLabは12件の欠陥をまとめて直す修正版を出し、そのうちのCVE-2026-110264は、深刻度を表すCVSS(0〜10の点数で、10が最も深刻)で満点の10.0とされました。
報道によると、この欠陥は、GitLabが細工された「正規表現」を処理するときに数値があふれる(整数オーバーフロー)というものです。正規表現は、「数字が3けた続く」のような文字の並びのパターンを表す書き方で、検索や入力のチェックなど、あらゆるソフトで使われています。
条件がそろうと、攻撃者が用意したパターンによってサーバー上で任意のプログラムを動かされる可能性があり、ログインも利用者の操作も必要ないとされています。影響を受けるのは2014年の7.0以降の版で、研究者のjoaxcar氏がHackerOne(企業が欠陥の報告を受け付けて報奨金を払う仕組みの大手)を通じて報告しました。
修正版は、次のものと報じられています。
- 18.11.13
- 19.0.10
- 19.1.9
- 19.2.9
- 19.3.6
- 19.4.3
- 19.5.1
GitLab.comは修正済みで、自社のサーバーでGitLabを動かしている組織は、自分の版に合った修正版に上げる必要があります。10月12日にも似た種類の別の欠陥(CVE-2026-97229)の修正がありましたが、そちらを当てていても今回の欠陥は直っていないので注意が必要です。10月24日の時点で、悪用された例や攻撃方法の公開は報告されていません。
GitLabの件はAIとの関わりが報告されておらず、PHP2Shellと同じ日に重なったのは偶然とみられます。それでも、プログラムの保管庫は、会社のソースコードと、そこから本番のサーバーに配るための鍵がまとまっている場所です。LiteLLMの事件がGitHubの合鍵から始まったことを考えると、開発の保管庫を守ることの重さは、この10日間を通してはっきりしたと言えます。
10日間の共通点:盗まれていたのは「サービス同士をつなぐ鍵」だった

ここまでの事件を、「何が盗まれたか」「どう入られたか」という目で並べ直してみます。
| 事件 | 盗まれたもの・使われたもの | 二段階認証で防げたか |
|---|---|---|
| Zeabur | 管理者の認証情報(平文保存)→ 利用者の環境変数 | 利用者の側では防げない |
| ConnectWise | バックアップ用アプリの秘密の値(アプリシークレット) | アプリとしてのログインなので対象外 |
| OpenCode | 預けていたAIのAPIキー | APIキーは単体で使えるので対象外 |
| LiteLLM | 開発者のGitHub CLIのトークン → 利用者のあらゆる鍵 | トークンは二段階認証のあとで発行される合鍵 |
| Railway | 利用者の環境変数 | 利用者の側では防げない |
| バーガーキング日本 | 会員情報(パスワードは漏洩を確認されず) | 利用者の側では防げない |
表を見ると分かるように、盗まれたものの多くは、人がログインするときのパスワードではありません。APIキー、アプリシークレット、アクセストークン、環境変数に入った鍵といった、「プログラムがほかのサービスにつながるための鍵」です。
こうした鍵は、人が毎回入力するものではないので、普段は意識されません。そして、一度発行されると、二段階認証を通らずにそのまま使えるものがほとんどです。
二段階認証は、パスワードに加えて、スマホのアプリや物理的な鍵での確認を求める仕組みで、人のアカウントを守るうえではとても効果があります。しかし、ConnectWiseの件で攻撃者が使ったのは、アプリが使うための鍵でした。
LiteLLMの件で使われたGitHub CLIのトークンも、エンジニアが二段階認証を済ませたあとに発行される合鍵です。玄関に立派な鍵をかけていても、合鍵が郵便受けの中にあれば意味がない、という状態に近いと言えます。
- パスワードではなく、APIキーやトークンなど
- 二段階認証を通らずに使えるものがほとんど
- AIのAPIキーは使った分だけ請求が来る
- 預け先の事業者や配布の仕組みが狙われた
もうひとつの共通点は、鍵が「お金に直結する」ようになったことです。AIのAPIキーは、使った分だけ請求が来る仕組みなので、盗んだ人は他人のお金で高性能のAIを使えます。OpenCodeの利用者に一晩で1,700ドルを超える請求が来たのは、その分かりやすい例です。
ロイターの件では、攻撃者がAIの利用料を自分で払っていたとされますが、盗んだキーを使えばその費用すら他人に回せてしまいます。Railwayが「AIの推論事業者を狙った一連の攻撃」とみているのも、この流れの中で考えると理解しやすくなります。
そして3つ目の共通点は、鍵が「1か所にまとまっている場所」が狙われたことです。Zeaburは321万件の環境変数を、Railwayも顧客の環境変数を、OpenCodeは利用者のAIのキーを、ConnectWiseは顧客のMicrosoft 365への許可を、それぞれまとめて持っていました。
利用者ひとりひとりのパソコンを攻めるより、鍵がまとまっている事業者をひとつ攻めるほうが、攻撃者にとっては効率がいいわけです。LiteLLMの事件は、そのまとめ役が「配布所」だったと考えることもできます。
この3つの共通点から、守り方の方向も見えてきます。
- 鍵を預ける場所を減らす。
- 預けるなら、鍵ごとに使える範囲と金額の上限を決めておく。
- 漏れたら、すぐに古い鍵を無効にする。
- 合鍵を作れる立場にある開発者のアカウントそのものを、だまされにくい方法で守る。
次の節から、これを具体的な手順にしていきます。
AIのAPIキーの守り方:個人で使っている人から仕事で使っている人まで

ここからは、この10日間の事件から学べる守り方を、具体的な手順として書いていきます。まずはAIのAPIキーです。ChatGPTやClaudeを画面から使っているだけで、APIキーを発行したことがない方は、この節は飛ばしても構いません。
自分でAIの道具を試していて、キーを作ったことがある方は、上から順に確かめてみてください。
1. 使える金額の上限と、使いすぎの通知を決めておく
OpenCodeの件で利用者が困ったのは、一晩で大きな金額を使われたことでした。多くのAIサービスの管理画面には、月ごとの利用額の上限や、一定の金額を超えたときに知らせる通知を設定する機能があります。
自分が普段どれくらい使っているかを確かめ、その少し上に上限を置いておけば、キーが盗まれても被害をその金額までに抑えられます。前払いのクレジット方式を選べるサービスなら、チャージした分しか使われないので、さらに安心です。
2. キーは用途ごとに分け、名前を付けておく
ひとつのキーをあちこちの道具に使い回すと、どこから漏れたのか分からず、止めたときに全部が使えなくなります。「自分のパソコンのコーディング用」「試しに作ったアプリ用」のように、使う場所ごとにキーを分けて、管理画面で分かりやすい名前を付けておきましょう。サービスによっては、キーごとに使えるモデルや機能、プロジェクトを絞れるので、必要なものだけに絞っておくと、漏れたときの被害が小さくなります。
3. キーを預ける先を減らす
OpenCodeの件では、クラウドのコンソールにキーを預けていた人が被害を受け、自分のパソコンで動かす版の利用者は無事でした。便利そうなWebサービスを見つけるたびにキーを貼り付けていると、そのサービスの数だけ漏れる入口が増えます。使わなくなったサービスに預けたキーは、そのサービスから消すだけでなく、AIの会社の管理画面でキーそのものを無効にしておくのが確実です。
4. 漏れたかもしれないときは、作り直すのではなく「古いキーを無効にする」
Zeaburが利用者に真っ先に求めたのが、この点でした。新しいキーを作っても、古いキーは無効にしない限り使えるままです。「キーを交換した」つもりで新しいキーを設定しただけでは、攻撃者は古いキーを使い続けられます。
漏れたかもしれないと思ったら、まずAIの会社の管理画面で古いキーを削除または無効にし、それから新しいキーを作って設定し直す、という順番を守ってください。そのうえで、利用の履歴や請求に身に覚えのないものがないかを確かめます。
5. キーをプログラムや画面に直接書かない
APIキーをプログラムの中に直接書いたり、.envファイルをそのままGitHubに上げてしまったりすると、それだけで漏れます。.envファイルは、Gitで管理しない設定(.gitignoreに書く)にしておきましょう。
画面を共有して作業を見せるときや、AIにエラーの相談をするときに、キーが写り込んだりそのまま貼り付けてしまったりする事故もよくあります。キーを貼る前に一呼吸おく習慣をつけるだけでも、事故は減らせます。
6. 請求と利用履歴を、月に一度は見る
ConnectWiseの件で、何年も使っていないアプリが管理者の権限を持ったまま残っていたように、使っていないはずのものが動いていても、見なければ気づけません。AIの会社の管理画面で、キーごとの利用額や利用の履歴を月に一度は眺めておくと、知らないうちに使われていたときに早く気づけます。
7. 「安く使える中継サービス」に自分のキーを渡さない
AIのAPIには、複数の会社のAIをまとめて呼び出せるようにしたり、割安な料金で使えるとうたったりする「中継サービス」がたくさんあります。CrowdStrikeの報告では、中国語のグループが中国国内の中継サービスを経由してClaudeを使っていました。
また、Zeaburは利用者への案内の中で、「new-api」や「one-api」といった中継の仕組みを自分で動かしていた人に対し、その奥に登録していたAIのキーも無効にするよう求めています。中継の仕組みは、自分のキーをまとめて預ける場所でもあるということです。
出どころのはっきりしない中継サービスに自分のキーを登録すると、そのサービスの運営者や、そのサービスに入り込んだ攻撃者が、キーを自由に使えてしまいます。反対に、出どころの分からない格安のキーを買って使うと、それが誰かから盗まれたキーである可能性もあります。AIを使うときは、なるべくAIの会社の公式の窓口と、自分で発行したキーを使うのが安全です。
開発者アカウントの守り方と、物理的なセキュリティキー

次は、プログラムを作る人のアカウントの守り方です。LiteLLMの事件は、3人のエンジニアのGitHubの合鍵が盗まれたところから始まり、週に2,300万回ダウンロードされる部品の汚染につながりました。開発者のアカウントは、本人だけでなく、そのプログラムを使う大勢の人の安全に関わります。
1. 取り込む部品の版を固定し、新しい版にすぐ飛びつかない
LiteLLMの悪意ある版が配られていたのは約2時間でした。「いつも最新を入れる」設定にしていると、その2時間のあいだにビルドしたサーバーや、新しくパソコンを用意した人がそのまま被害を受けます。requirements.txtなどで使う版を固定し、可能ならハッシュ(ファイルの指紋のような値)も記録しておくと、知らない版が勝手に入るのを防げます。
新しい版が出ても数日待ってから上げるだけで、今回のように短時間で取り下げられた悪意ある版を避けられる場面は少なくありません。Dockerのイメージも、「latest」ではなく版の番号で指定するのが基本です。
2. 長く使える合鍵(トークン)を見直す
GitHub CLIのように、一度ログインすると合鍵を発行して保存する道具はたくさんあります。自分のパソコンにどんな合鍵が保存されているか、使っていない道具のログイン状態が残っていないかを、ときどき見直しましょう。
GitHubの個人用のトークンを作るときは、使える保管庫と権限を必要なものだけに絞れる種類を選び、有効期限を付けておくと、盗まれたときの被害を小さくできます。会社では、リリースの手順を起動できる人と、承認できる人を分け、決められた保管庫と枝(ブランチ)からしか起動できないようにしておくことを、Datadogも教訓として挙げています。
3. 連携アプリの許可を棚卸しする
ConnectWiseの件では、昔入れたバックアップのアプリに与えた許可が、そのまま攻撃の入口になりました。Microsoft 365やGoogle Workspace、GitHubなどの管理画面には、自分や会社が許可を与えた外部のアプリの一覧があります。使っていないアプリの許可は取り消し、使っているアプリも、必要以上に強い権限(すべてのメールを読める、すべての管理者になれる、など)を持っていないかを確かめてください。
4. 汚染された部品を入れてしまったかもしれないときは
LiteLLM 1.107.0を入れてしまったかもしれない場合は、パッケージを消すだけでは足りません。Datadogの案内に沿って、site-packagesの中のcook.pth、cook.py、sitecustomize.pyを手で消し、無事な版に戻したうえで、そのパソコンやサーバーにあったすべての鍵を、汚れていない別のパソコンから交換します。
鍵の交換を汚れたパソコンの上で行うと、新しい鍵もまた盗まれるおそれがあるためです。会社で使っている場合は、ひとりで判断せず、社内のセキュリティの担当者に連絡してください。
5. アカウントの入口は「フィッシングに強い」方式で固める
合鍵の管理と同じくらい大事なのが、合鍵を作れる立場にあるアカウントそのものの守りです。LiteLLMの3人のアカウントが最初にどう乗っ取られたのかはまだ分かっていませんが、開発者のアカウントを狙う手口としては、本物そっくりの偽のログイン画面に誘い込み、パスワードとスマホに届く確認コードをまとめてだまし取るフィッシングがよく知られています。SMSや認証アプリの6けたの数字は、偽の画面に入力してしまえば、そのまま攻撃者に使われてしまいます。
これに強いのが、パスキーや、物理的なセキュリティキーを使う方式です。こうした方式は、FIDO2(ファイドツー)という標準の仕組みに沿っていて、ログインする先のサイトの住所(ドメイン)を鍵自身が確かめます。偽のサイトでは本物の鍵が反応しないので、うっかり偽の画面を開いてしまっても、ログインの情報を渡さずに済みます。
- 偽の画面に入力してしまえば、そのまま攻撃者に使われる
- ログインする先のドメインをキー自身が確かめる
- 偽のサイトでは本物のキーが反応せず、ログインの情報を渡さずに済む
GitHub、Google、Microsoftなどの主要なサービスは、セキュリティキーでの二段階認証に対応しています。
物理的なセキュリティキーの例:YubiKey 5C NFC
物理的なセキュリティキーの代表的な製品が、スウェーデン発祥のYubico(ユビコ)が作っている「YubiKey(ユビキー)」です。中でも「YubiKey 5C NFC」は、最近のノートPCに多いUSB-Cの差し込み口に挿して使えるうえ、スマホにかざしても使えるので、パソコンとスマホの両方でログインを守りたい人に向いています。Yubicoの公式ページで紹介されている特徴は次のとおりです。
- USB-CとNFC(かざして通信する仕組み)の両方に対応し、ノートPCには挿して、NFCに対応したスマホにはかざして使えます。
- FIDO2(パスキー)とFIDO U2Fに加え、ワンタイムパスワード(OATH-TOTP/HOTP、Yubico OTP)、スマートカード(PIV)、OpenPGPなど、ひとつの鍵で多くの方式に対応しています。
- 公式ページでは、パスキーを最大100件、認証アプリと同じ種類のワンタイムパスワードを64件まで保存できるとされています(保存できる数はファームウェアの版によって異なり、古い版では少なくなります)。
- 電池を使わず、ネットワークへの接続もいりません。防水・防じんの規格IP68に対応し、動く部品がないつくりです。
- Windows、macOS、ChromeOS、Linuxで使え、MicrosoftやGoogleのアカウント、1Password、Bitwarden、OpenAIなど、多くのサービスでの利用例が公式に挙げられています。
使うときの注意も書いておきます。セキュリティキーは、なくしたり壊したりすると、そのキーだけでログインしていたアカウントに入れなくなります。2本用意して両方を登録し、1本は自宅の決まった場所にしまっておくか、各サービスの「回復用コード」を紙に書いて保管しておくのが基本です。
また、セキュリティキーが守るのは「人がログインする入口」です。この記事の前半で見たAPIキーやアプリシークレット、環境変数の鍵そのものを守ってくれるわけではありません。キーの上限設定や棚卸しと組み合わせて、はじめて効果が出ます。
ここまでの手順を、立場ごとに表にまとめておきます。
| 立場 | まずやること | 余裕があればやること |
|---|---|---|
| AIを画面から使うだけの人 | AIのアカウントの二段階認証をオンにする | パスキーやセキュリティキーに切り替える |
| APIキーを作ったことがある人 | 利用額の上限と通知を設定し、使っていないキーを無効にする | 用途ごとにキーを分け、名前を付ける |
| アプリを公開サービスに置いている人 | Zeabur・Railwayの利用者は、古い鍵を無効にしてから交換する | 環境変数に入れる鍵の権限を絞る |
| Pythonなどで開発している人 | LiteLLM 1.107.0を入れていないか確かめる | 部品の版を固定し、新しい版は数日待つ |
| 会社のIT管理者 | 連携アプリの許可を棚卸しし、使っていないものを取り消す | 開発者のアカウントをセキュリティキー必須にする |
全部を一度にやる必要はありません。表の「まずやること」のうち、自分に当てはまるものをひとつ選んで、今週のうちに手をつけるだけでも、この10日間に起きたような事件の被害はかなり小さくできます。
まとめ
2026年10月12日から22日までの10日間には、フランスのスーパーの冷蔵ケースの乗っ取り、Zeaburからの321万件の環境変数の読み出し、ConnectWiseのバックアップ用アプリの鍵を使ったMicrosoft 365への侵入、バーガーキング日本のアプリ会員約1,118万件の漏洩、OpenCodeからのAIのAPIキーの流出、AIエージェントによる100社超への侵入の報道、そして10月21日のPHP2Shell、LiteLLM、Railway、GitLabと、大きな事件が立て続けに起きました。
「Black October」は、このような事件の多さを指す呼び名で、ひとつの攻撃者による作戦の名前ではありません。
事件の多くに共通していたのは、パスワードではなく、APIキーやトークン、環境変数といった「サービス同士をつなぐ鍵」が盗まれていたことです。こうした鍵は二段階認証の外側で使われ、AIのキーはそのままお金に変わります。
そして、鍵がまとまって預けられている事業者や、配布の仕組みが狙われました。一方で、AIエージェントが攻撃の手間と費用を大きく下げつつあることも、ロイターとCrowdStrikeの報告で示されています。
- AIのAPIキーには利用額の上限と通知を設定し、用途ごとに分ける
- キーを預けるサービスを減らし、使わなくなったら古いキーを無効にする
- 漏れたかもしれないときは、新しいキーを作る前に古いキーを止める
- 取り込む部品の版を固定し、連携アプリの許可を棚卸しする
- 開発者のアカウントは、パスキーやセキュリティキーでフィッシングに強くする
Cloudflareの最高経営責任者が「まだ出てくる」と話したように、AIが欠陥を見つける速さも、AIが攻撃に使われる速さも、これから上がっていくとみられています。事件のひとつひとつを追いかけきるのは難しくても、自分の鍵の置き場所と使い道を把握しておくことは、今日からでもできます。
出典
- GPTunneL「Black October」(まとめ記事)
- AP(News4Jax掲載)Cyberattack targeting refrigeration systems hits 700 supermarkets, French government says
- Zeabur October 2026 Security Incident(中間報告)
- Safeguard Zeabur shutdown and environment variables breach
- ConnectWise Trust Center Advisories(Cloud Backup)
- BleepingComputer Hackers breach Microsoft 365 tenants via ConnectWise supply chain attack
- BleepingComputer Burger King Japan data breach exposes 11 million customer records
- BleepingComputer OpenCode hack exposes API keys amid AI distillation attacks
- Reuters(BNN Bloomberg掲載)How one hacker used AI agents and a few thousand dollars to break into scores of sites
- CrowdStrike CrowdStrike Uncovers New Agentic AI Campaigns
- Datadog Security Labs LiteLLM compromised on PyPI and Docker
- Aikido LiteLLM compromised with infostealer and RAT
- Railway Security Disclosure: Wednesday, October 21st
- Cybersecurity News 12-year-old GitLab vulnerability(CVE-2026-110264)
- piyolog PHP2Shell関連のまとめ
- The Hacker News PHP Issues Emergency Patches for Two Critical Flaws
- 日本経済新聞 PHP並みの脆弱性「まだ出てくる」
- Yubico YubiKey 5C NFC 製品ページ
※この記事の内容は、2026年10月24日時点で公表されている情報をもとにしています。