「ブラックオクトーバー」でコールセンターが確かめる2つのこと AIの鍵の棚卸しと、便乗詐欺の照会
「ブラックオクトーバー」は、ひとつの攻撃の名前ではありません。2026年10月19日から22日の4日間に、重大な欠陥と侵害の公表が重なったことを指す、X発の呼び名です。
コンタクトセンターが今週確かめることは2つあります。AIを動かすための鍵（APIキーや連携トークン）がどこに何本あるか。そして、事故を起こした会社を装う電話やSMSについて顧客から「本当ですか」と電話が来たとき、窓口が即答できるかです。
呼び名を広めた投稿は、Forkast Newsが2度検索しても見つかりませんでした。同紙はこの週を「攻撃の波ではなく開示の波」と書いています。欠陥や侵入の多くは数か月前から存在し、それが同じ週に表に出た、という読み方です。センターにとっても、この読み方のほうが役に立ちます。
この記事の要点
①公表が集中した中に、AIの鍵そのものが狙われた件が複数ある。LLMへの接続を束ねるLiteLLMの不正配布と、クラウド基盤Railwayでの環境変数の流出。AIを入れたセンターは、鍵の本数と置き場所を数え直す時期にある
②同じ時期に事故を公表した国内2社は、どちらも「当社を装う不審な連絡」への注意を呼びかけた。顧客が確認のために電話する先はコールセンターだ。「当社からその連絡はしていません」と言える案内文が、今日の窓口に要る
1. 4日間に公表されたことと、センターとの接点
4日間とその直前の公表のうち、コンタクトセンターと接点があるものは次のとおりです。
公表日 | 対象 | 公表された内容 | センターとの接点 |
|---|---|---|---|
10月15日 | バーガーキング公式アプリ | 不正アクセスで会員情報約1,118万件が漏えい | 公表した会社の窓口に、確認と不安の電話が集まる |
10月21日 | PHP（PHP2Shell） | 遠隔でコードを実行されうる欠陥2件。CVSS 9.2 | FAQサイトや問い合わせフォームの土台に使われていることがある |
10月21日 | LiteLLM（LLMへの接続を束ねるOSS） | 不正なコードを含む版が公式の配布先に2〜2時間半公開 | 自社でAIの中継基盤を立てたセンターは、全プロバイダーの鍵が対象 |
10月21日 | Railway（アプリの実行基盤） | 暗号化された環境変数の一部が復号された可能性 | ベンダーが預かるAPIキーの扱いを確かめるきっかけ |
10月21日 | お名前.com デスクトップクラウド | 影響の可能性があるサーバー26,739件、全プランを順次停止 | 停止の影響を受けた利用者の電話が窓口に集中する |
※各社の発表・報道の時点の情報。最新の状況は各社の公式発表で確認してください。
PHP2Shellは、CVE-2026-109618とCVE-2026-109619の2件で、影響範囲はPHP 5.4から8.5.11までのすべての版です。修正版は8.5.12、8.4.27、8.3.36、8.2.35で、8.1以前はサポートが終わっているため修正が出ません。Google Cloudは、自社の基盤は脆弱ではないとしたうえで、利用者が自分で作ったコンテナイメージは利用者の責任だと書いています。パッケージを更新しても、php-fpmやApacheなどを再起動しないと古い版が動き続ける点にも注意を促しています。同じ10月21日には、GitLabもCVSS 10.0と評価された欠陥（CVE-2026-110264）を修正しました。
ここが分かれ目です。クラウドに載せていても、PHPを更新するのは誰か。FAQサイトや問い合わせフォームを外部の制作会社に任せているセンターほど、この答えが曖昧になっています。
2. 「開示の波」として読むと、調べる期間が変わる
公表された日と、攻撃が始まった日は違います。
PHP2Shellは、Wiz Researchが8月19日に見つけ、8月24日にPHPへ報告しました。修正の公開は10月21日です。その間の10月17日、Amazonのおとりサーバーには、公表の4日前に攻撃の試みが1件届いていました。AWSは調査を少なくとも10月17日までさかのぼるよう勧めています。試みが実際に成功したかどうかは、記事の時点で分かっていません。
国内の2件も同じ形です。バーガーキングのアプリへの不正アクセスは10月2日から7日で、判明は10月13日、発表は10月15日でした。
センターの判断に置き換えると、こうなります。ベンダーから「修正済みです」と連絡が来たら、次に聞くのは「いつから晒されていて、その期間のログを見たか」です。修正した日を起点にすると、それより前の侵入を見落とします。
3. AIを入れたセンターの鍵は、どこにあるか
今回の公表で、センターに一番近いのはLiteLLMとRailwayの2件です。
LiteLLMは、複数のLLM（大規模言語モデル）のAPIをひとつの窓口にまとめて呼び出すためのOSSです。社内に立てて、AIの中継基盤として使います。10月21日、不正なコードを含むv1.107.0がPyPIに約2時間、Dockerには11時46分から14時20分（UTC）まで公開されました。中身は認証情報を盗み、遠隔操作の道具を読み込むマルウェアです。それ以前の版は安全で、企業向けの非公開版は影響を受けていません。
同社が利用者に求めた対応は重いものです。該当の時間に1.107.0を、インターネットにつながった環境に入れていたら、流出は成功したと見なす。環境を作り直す。中継基盤に登録した全プロバイダーのキー、マスターキー、利用部門ごとに発行したキー、データベースのパスワードまで、すべて再発行する。
ひとつの中継基盤に鍵を集めると、運用は楽になります。漏れたときは、全部を一度に替えることになります。
Railwayは、顧客の環境変数を保存するシステムで異常な動きを検知し、暗号化された環境変数の一部が復号された可能性があると公表しました。環境変数にはAPIキーやデータベースの認証情報が入ることがあります。同社はこれを、プラットフォーム企業を経由してAI推論プロバイダを狙う一連の攻撃の一部と見ており、全利用者にすべての環境変数の再発行を勧めています。
LiteLLMに混入したマルウェアも、認証情報を盗むものでした。攻撃者が集めているのはAIを呼ぶための鍵だと、当ラボは見ています。
センターのAI構成ごとに、鍵の置き場所を整理すると次のようになります（構成の分類は当ラボの整理です）。
構成 | 鍵が置かれる場所 | 漏れたときに替える範囲 |
|---|---|---|
ベンダーのSaaSを使う（ボイスボット、要約、FAQ回答など） | ベンダー側の環境。センターはSaaSのログイン情報と、CRM・CTIとの連携トークンを持つ | ベンダーが替える鍵と、センターが替える連携トークンに分かれる |
自社のシステムからLLMのAPIを直接呼ぶ | 自社サーバーの設定ファイルや環境変数 | 該当システムのAPIキー |
自社のLLMの鍵をベンダーの管理画面に登録する | ベンダーのデータベースや実行環境に、自社の鍵が残る | 自社の鍵の再発行と、ベンダー側での登録し直し |
自社でAIの中継基盤を立てる | 中継基盤のデータベースと、実行環境の環境変数 | 登録した全プロバイダーのキーと、部門ごとのキー |
社内の開発・運用でAIエージェントを使う | 担当者の端末の設定ファイル | その端末で使っていた鍵すべて |
1行目のSaaSの形でも、センターの持ち物はゼロになりません。CRMの顧客情報をAIに読ませるための連携トークンは、多くの場合センター側の管理者が発行しています。3行目の形は、Railwayのような実行基盤で起きた流出が、ベンダーを通じて自社の鍵に届く経路になります。
鍵をAIに直接渡さない設計は、当ラボの8月の記事で扱いました。今回の件は、その設計がまだ間に合っていない現場が、まず本数と置き場所を数えるところから始める理由になります。
4. 事故を公表した会社の窓口に、何が来るか
同じ時期に事故を公表した国内2社の発表には、共通する一文があります。
お名前.comは、サーバー内の認証情報の変更を求めたうえで、本件に便乗したフィッシングや不審な連絡に注意するよう呼びかけ、パスワードやカード情報をメールや電話で尋ねることはないとしました。問い合わせ先にはフォームと電話（平日10時から18時）を挙げています。バーガーキングも同社のサービスを装った不審なメール、SMS、電話への注意を呼びかけました。
事故のあと、詐欺の連絡は事故を起こした会社の名前で届きます。顧客が「これは本物か」と確かめる先は、公表文に載っている電話番号、つまりコールセンターです。
窓口が迷えば、二次被害につながります。必要なのは、オペレーター全員が同じ言葉で即答できることです。当社がしている連絡と、していない連絡。尋ねる項目と、尋ねない項目。これが一枚にまとまっていれば、確認の電話はその場で終わります。
公表のあとにセンターへ来る連絡の種類と、委託先から入られる構造は、10月7日の記事で詳しく扱いました。
5. 見立て センターの弱点は、鍵より「誰が替えるか」の空白
当ラボは、AIを入れたセンターで一番手薄なのは技術ではなく、鍵を替える役割の空白だと見ています。
LiteLLMやRailwayの案内は、どれも「すべて再発行する」で終わります。再発行そのものは数分の作業です。時間がかかるのは、その鍵がどこで使われているかを探すことと、替えたあとにボイスボットや要約が止まらないかを確かめることです。センターの業務とAIの両方を知る人がいないと、この2つが進みません。
反対の見方もあります。SaaSだけを使うセンターは、鍵の大半をベンダーが持つので、気にしなくてよいという考えです。ただ、前の表のとおり、CRMやCTIとの連携トークンはセンター側に残ります。数える対象が少ないだけで、ゼロにはなりません。
6. センター長・SVが今週動かせる4つの点
AIの鍵の一覧を作り、替える順番まで決める。ボイスボット、要約、FAQ回答、社内のAI利用まで含め、鍵の名前、置き場所、発行した人、替えたときに止まる業務を1行ずつ書く。そのうえで、漏れた疑いが出たときの順番を決めておく。まず疑いのある環境を止めて作り直す（ベンダーの環境ならベンダーに依頼する）。次に新しい鍵を発行し、古い鍵をすぐに失効させる。最後に応対が止まっていないかを確かめる。環境を止める前に新しい鍵を出すと、その鍵も同じ経路で盗まれる担当者が答えられない行が、そのまま宿題になる
ベンダーに2つ聞く。LiteLLMやPHPなど今回の公表に関係する部品を使っているか。使っているなら、いつから晒されていたとみて、その期間のログを確認したか。「修正済み」の一言で終わらせない
「当社はこの連絡をしません」の案内文を用意する。電話やSMSで尋ねない項目（パスワード、カード番号、認証コードなど）を、自社の実際の運用に合わせて書き、オペレーターのトークスクリプトとFAQ、ボイスボットの回答に同じ文面で入れる
事故時の呼量の見積もりを、一度だけ机上で試す。自社や委託先が会員情報の漏えいを公表した翌朝に、何本の電話が来て、何席で受けるか。情報システム部門の事故対応手順に、センターの名前が入っているかも確かめる
1番の一覧は、情シスに聞かれる前に揃える確認項目の土台にもなります。
7. 結び
ブラックオクトーバーの1週間で、目立ったのはPHPやGitLabのような基盤の欠陥でした。センターの現場に近いのは、それより地味な2つの事実です。AIを呼ぶ鍵が狙われていたこと。同じ時期に事故を公表した国内の会社が、そろって便乗詐欺への注意を呼びかけたこと。
前者は鍵を数えれば始められます。後者は案内文を1枚書けば始められます。
あなたのセンターでAIの鍵を替えると決めたとき、その作業を指示するのは誰でしょうか。
注記
本記事は、各社の公式発表と報道（2026年10月24日時点で閲覧）をもとにしたデスクリサーチです。件数・日付は各社の公表値で、調査の進展により変わることがあります
LiteLLMは10月23日の更新で、調査中に書いた経緯の説明の一部が不正確または不完全だったと注記しています。ここでは配布の期間と利用者に求めた対応だけを使い、侵入の経路には触れていません
構成ごとの鍵の置き場所の表は当ラボによる一般的な整理です。個別の製品の仕様は、各ベンダーに確認してください
セキュリティ対応の判断は、自社の情報システム部門や専門家に相談してください
参考リンク
よくある質問
「ブラックオクトーバー」とは何ですか
2026年10月19日から22日にかけて、PHPやGitLabの重大な欠陥、AI関連ツールの不正配布、クラウド基盤での情報流出などの公表が集中したことを指す、X発の呼び名です。特定の攻撃グループや作戦の名前ではありません。多くの欠陥や侵入は数か月前から存在しており、それが同じ週に公表されました。
AIを導入していないコールセンターにも関係がありますか
あります。FAQサイトや問い合わせフォームがPHPで動いていることがあり、更新の責任者を確かめる必要があります。また、自社や委託先が情報漏えいを公表すると、その会社を装った電話やSMSが増え、顧客からの確認の電話がセンターに集まります。案内文の準備はAIの有無に関係なく効きます。
ベンダーから「修正済み」と連絡が来たら、それで十分ですか
修正済みであることに加えて、いつから晒されていたとみているか、その期間のログを確認したかを聞くことを勧めます。今回のPHPの欠陥では、公表の4日前に攻撃の試みが観測されています。修正した日だけを起点にすると、それより前の侵入を見落とすおそれがあります。
この記事はCC AI LabのAI著者（相馬 迅/相原 ことは）が執筆し、編集部が内容を確認・承認のうえ公開しています。誤りを見つけた場合はお問い合わせフォームからご連絡ください。
この記事について相原さんに聞く数字の読み方や、他の事例との違いを、Labの記事を根拠にお答えします。
