この記事の要点
- 「ブラックオクトーバー」は、2026年10月に重大な脆弱性の公表やセキュリティ事件が短期間に重なったことを指す通称。中心はPHPの脆弱性「PHP2Shell」（10月21日公表）
- 同じ週に、GitLabの最高深刻度の脆弱性、AI開発で使われる「LiteLLM」の配布物への不正プログラム混入、認証局eMudhraの秘密鍵の問題などが相次いだ
- PHP2Shellは公表から5日で米CISAの「悪用が確認された脆弱性」の一覧に載り、PHPを組み込んだファイアウォールの管理画面でも攻撃が確認された
- 背景には、AIによって脆弱性が見つかるペースが上がっていることがある。10月は「異常な月」というより、これから続く状態の始まりと見たほうがよい
- 脆弱性はゼロにならない。企業に必要なのは、自社に何があるかを把握し、優先順位をつけて速く直し、直しきれない間も被害を抑える「仕組み」を持つこと
10月21日、ウェブサイトを動かすプログラム言語「PHP」に、認証なしで外部からプログラムを実行されるおそれのある脆弱性2件が公表されました。国内では自治体や企業がサイトの公開を相次いで止め、高市総理もXで迅速な更新を呼びかけました（既報）。
問題はPHPだけではありませんでした。同じ週に、ソースコード管理のGitLab、AIアプリの開発で広く使われる「LiteLLM」、HTTPSの信頼を支える認証局など、性質の異なる重大な問題が立て続けに明らかになりました。10月23日には英ガーディアンや米ワシントン・ポストが、この状況を「ブラック・オクトーバー（Black October）」と表現しています。
この記事では、10月に何が起きたのかを時系列で整理したうえで、なぜこれが一過性の出来事ではないのか、そして脆弱性と常に向き合い続けることが前提になった時代に、企業が何を整えておくべきかを考えます。
10月に何が起きたのか
主な出来事を時系列で並べます。日付は各社が公表した日（現地時間）です。
| 日付 | 出来事 | 何が問題だったか |
|---|---|---|
| 10月13日 | マイクロソフトの月例更新が過去最多の規模に | 修正された脆弱性は1,400件を超えたと報じられた（集計により1,407〜1,415件と幅がある）。うち2件は修正が不十分で、25日に.NETの定例外更新があらためて出た |
| 10月12〜13日 | GitLabが最高深刻度（CVSS 10.0）の脆弱性を修正 | 細工した正規表現で、認証なしにサーバー上でプログラムを実行される（既報） |
| 10月17日 | 認証局eMudhraの中間証明書8件で、秘密鍵の欠陥が報告される | 鍵が十分な乱数で作られておらず、第三者が復元できる状態だった。Google、Mozillaなどが即日〜数日で遮断し、eMudhraは22日にSSL/TLS証明書事業からの撤退を表明（既報） |
| 10月21日 | PHPが緊急の修正版（8.5.12／8.4.27／8.3.36／8.2.35）を公開 | 通称「PHP2Shell」。2件ともCVSS v4.0で9.2。PHPは「完全な回避策はなく、更新が唯一の安全な選択肢」とした。サポートが終わった8.1以前には修正版が出ない |
| 10月21日 | 米CISA、FBI、NSAが相次いで即時更新を呼びかけ | CISAは、すぐに更新できない場合はPHPで動くシステムをオフラインにするよう求めた（既報） |
| 10月21日 | LiteLLM 1.107.0に不正プログラムが混入 | 正規の配布経路（PyPI、Docker Hub）から約2〜3時間、認証情報を盗むプログラム入りの版が配られた。開発者の認証情報を奪われ、リリースの仕組みを乗っ取られたとされる（既報） |
| 10月21日 | GitLabが再び最高深刻度（CVSS 10.0）の脆弱性を修正 | 細工した「.org」ファイルを表示させるだけで、認証なしにプログラムを実行される。13日の更新を当てた環境も、あらためて更新が必要になった |
| 10月21日 | Node.jsなどが圧縮形式Brotliの脆弱性を修正 | 同じライブラリを使う.NET、Firefox、PHPのWindows版などにも影響が広がった |
| 10月21日〜 | パロアルトネットワークスのPAN-OSがPHP2Shellの影響を受けると公表 | ファイアウォールの管理画面を狙う攻撃を確認。修正版は29日までに出そろった（既報） |
| 10月26日 | PHP2Shellが米CISAの「悪用が確認された脆弱性」カタログ（KEV）に掲載 | 公表から5日。IPAは11月2日、PHPを組み込んだVPN機器やセキュリティ製品も影響を受けうると注意喚起を更新した |
一つひとつは別々の問題ですが、共通しているのは「土台」にあたるソフトウェアで起きたことです。PHPは世界中のウェブサイトの土台であり、GitLabは開発の土台、LiteLLMはAIアプリの土台、認証局はHTTPS通信の信頼の土台です。土台に穴が開くと、その上で動く無数のサービスが一斉に影響を受けます。
なぜ「異常な月」で終わらないのか
10月の出来事を「運の悪い月だった」と片づけることはできません。いくつかの変化が重なっており、同じような状況はこれからも繰り返されると考えるべきです。
1. AIが脆弱性を見つけるスピードが上がった
脆弱性を見つける作業に、AIが本格的に使われ始めています。米セキュリティ企業のAIエージェントは、粒子加速器などの制御に使われるソフトウェアの脆弱性4件を、約3時間49分で見つけました（既報）。Anthropicは、25のオープンソースプロジェクト、計500万行超のコードを分析し、493件の問題を見つけたと公表しています（既報）。
これは防御側にとって良い知らせでもあります。見つかった穴は直せるからです。ただし同じ道具は攻撃者も使えます。見つかる脆弱性の数が増え、公表から悪用までの時間が短くなることは避けられません。PHP2Shellが公表から5日で「悪用確認済み」に載ったのは、その表れです。
2. 「当てたら終わり」ではなくなった
10月は、修正版を当てても終わらない例が目立ちました。GitLabは13日と21日に、別々の最高深刻度の脆弱性を修正し、13日に更新した組織はもう一度更新する必要がありました。マイクロソフトも、13日の月例更新で修正が不十分だった2件を、25日にあらためて修正しています。PHPも、次の定例リリースで別の脆弱性（CVE-2026-115560）の詳細を公表するとしています。
脆弱性への対応は、年に数回の「イベント」ではなく、毎週のように回し続ける「業務」になったと言えます。
3. 自分で入れた覚えのないソフトにも穴がある
PHP2Shellで見落とされやすいのは、ファイアウォールやVPN機器のように、内部でPHPを使っている製品です。PAN-OSでは、利用者がPHPを意識していなくても、管理画面が攻撃の入口になりました。Brotliの脆弱性も、Node.js、.NET、ブラウザと、同じ部品を使う製品に次々と広がりました。
「うちはPHPを使っていない」と言い切れる組織は、実は多くありません。自社のサイト、委託先が運用するサイト、ネットワーク機器、業務で使うSaaSのどこに、何の部品が入っているのか。それを把握していないと、影響があるかどうかすら判断できません。
4. 配布の仕組みや信頼の仕組みそのものが狙われる
LiteLLMの件では、ソフトウェアの欠陥ではなく、正規の配布経路そのものが乗っ取られました。利用者が「いつもどおり最新版に更新した」ことが、被害につながった可能性があります。eMudhraの件は、HTTPSの安全性を保証する側の認証局に欠陥がありました。「最新版にすれば安全」「鍵マークがあれば安全」という前提そのものが揺らいだ月でもありました。
「脆弱性ゼロ」は目標にならない。目指すのは「速く、漏れなく」
脆弱性が途切れなく見つかる以上、「脆弱性のない状態」を保つことは現実的な目標ではありません。目指すべきは、新しい脆弱性が出たときに、影響する場所をすぐ特定し、優先順位をつけて速く直し、直しきれない間も被害を抑えられる状態です。そのために、次の仕組みを整えておくことをおすすめします。
自社に「何があるか」を一覧にする
次の緊急パッチが出たとき、最初に問われるのは「うちに影響はあるか」です。サーバー、ネットワーク機器、VPN、公開しているサイト、使っているソフトウェアとそのバージョン、担当者を一覧にしておけば、影響の有無を数時間で判断できます。一覧がなければ、調べるだけで数日かかり、その間は無防備になります。委託先が運用しているサイトや機器も、一覧に含めることが大切です。
優先順位の物差しを決めておく
すべての脆弱性を同時に直すことはできません。「インターネットから届くか」「実際に悪用されているか」「認証なしで攻撃できるか」の3点を優先順位の物差しにすると判断が速くなります。悪用されているかどうかは、米CISAのKEVカタログや、IPA、JPCERT/CCの注意喚起で確認できます。
更新を自動化し、「戻せる」ようにしておく
日本ハッカー協会の杉浦隆幸氏は、AIで攻撃が速くなった今は「パッチが来たらすぐ当て、動かなくなったら戻す」運用に変える必要があると指摘しています（既報）。検証に何週間もかけていた更新を、自動で当て、問題があれば元に戻せる体制に変えていくことが、これからの基本になります。
「止める」判断を事前に決めておく
PHP2Shellでは、更新が間に合わない組織が、予防のためにサービスを止めました。保育ICTのコドモンは、いち早く停止した理由を「被害が出てからでは取り消せない」と説明しています（既報）。誰が、どんな条件で「止める」を判断するのかを、事前に決めておくことが、いざというときの速さにつながります。
外から見える入口を減らす
ファイアウォールやVPN機器の管理画面を、インターネットに公開したままにしていないでしょうか。PAN-OSでは、管理画面へのアクセスを限られた経路に絞っている場合、深刻度が大きく下がるとされています。使っていない機能、公開しなくてよい画面を閉じることは、パッチが出る前からできる対策です。
サポート切れのソフトを残さない
PHP 8.1以前には、今回の修正版が提供されませんでした。PHP 8.2も2026年12月31日にサポートが終わります。サポートが終わったソフトは、次の脆弱性が見つかったときに「直す手段がない」状態になります。移行の計画は、緊急時ではなく平時に立てておく必要があります。
「もう侵入されているかもしれない」前提で監視する
修正版を当てても、当てる前に侵入されていれば被害は防げません。PHP2Shellのように公表直後から攻撃が始まる脆弱性では、更新とあわせて、侵入の痕跡がないかを確かめることが欠かせません。サーバーや端末の不審な動きを監視し、侵入に早く気づける体制があれば、パッチが間に合わなかった場合の被害を小さくできます。LiteLLMの件のように、配布物そのものが汚染されていた場合も、気づけるのは監視だけです。
次の「ブラックオクトーバー」に備えるチェックリスト
| 確認すること | 目安 |
|---|---|
| 公開しているサーバー、機器、サイトとそのソフトウェアの一覧がある | 緊急の注意喚起が出たら、数時間で影響の有無を答えられる |
| 委託先が運用するサイトや機器も、一覧に含まれている | 委託先に確認する連絡先と手順が決まっている |
| 優先順位の物差しが決まっている | 「外から届く」「悪用確認済み」「認証不要」の脆弱性を最優先にする |
| 更新を当てる手順と、元に戻す手順がある | 重大な脆弱性は、公表から数日以内に当てられる |
| 「止める」判断の担当者と条件が決まっている | 更新が間に合わない場合の一時停止を、その場で判断できる |
| 管理画面やリモート接続が、インターネットに不要に公開されていない | 管理用の画面は、決められた経路からしかアクセスできない |
| サポートが終わったOS、ソフト、機器が残っていない | 残っている場合は、移行の期限と代わりの対策が決まっている |
| サーバーや端末を監視し、侵入の兆候に気づける | 更新の前後で、侵害の有無を確認できる |
よくある質問
Q. 「ブラックオクトーバー」は、何かの攻撃の名前ですか？
いいえ。2026年10月に重大な脆弱性の公表やセキュリティ事件が相次いだことを指す通称です。特定の攻撃者や攻撃キャンペーンの名前ではありません。どの出来事を含めるかは情報源によって異なり、SNSでは件数を強調する投稿も出回りましたが、数え方はまちまちです。
Q. 自社はPHPを使っていないので、関係ありませんか？
自社で書いたプログラムにPHPを使っていなくても、ウェブサイトの管理システム（WordPressなど）、委託先が運用するサイト、ファイアウォールやVPN機器の管理画面などで、内部的にPHPが使われていることがあります。IPAも、PHPを組み込んだ製品・機器が影響を受けうると注意喚起しています。各製品の開発元が出す情報を確認してください。
Q. 中小企業でも、毎週のように更新を当てる必要がありますか？
すべてを毎週当てる必要はありませんが、インターネットから届き、実際に悪用されている脆弱性は、規模を問わず速く当てる必要があります。攻撃者は会社の規模ではなく、脆弱な機器やサイトを自動的に探して攻撃します。社内で手が回らない場合は、更新の自動化ツールや、監視・運用の外部サービスを使うことも検討してください。
Q. AIで脆弱性が見つかりやすくなるのは、悪いことなのですか？
一概に悪いとは言えません。見つかった脆弱性は直せるため、長い目で見ればソフトウェアは安全になっていきます。ただ、その過程では修正版の数が増え、公表から悪用までの時間も短くなります。この「移行期」をどう乗り切るかが、企業にとっての課題です。
まとめ：10月は「始まり」として受け止める
ブラックオクトーバーは、PHP、GitLab、LiteLLM、認証局と、インターネットの土台にあたる部分の問題が短期間に重なった月でした。そしてその背景には、AIによって脆弱性が見つかるペースが上がり、攻撃が速くなっているという、これからも続く変化があります。
脆弱性はこれからも途切れなく見つかります。大切なのは、次の緊急パッチが出たときに慌てないことです。自社に何があるかを知り、優先順位をつけて速く直し、直しきれない間も被害を抑える。その仕組みを平時のうちに整えておくことが、「脆弱性と向き合い続ける時代」の基本になります。
あわせて読みたい
次の「緊急パッチ」のとき、影響する機器をすぐに挙げられますか
サイバーセキュリティ総研では、外から見えるサーバーや機器の弱点を洗い出す脆弱性診断と、端末を24時間監視して侵入に早く気づくMDRを提供しています。「自社に何があるのか分からない」という段階からご相談いただけます。
参照：PHP「PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 Released」（2026年10月21日）／IPA「PHPの脆弱性対策について（CVE-2026-109618、CVE-2026-109619：PHP2shell）」／Google「Protecting Chrome and Android users from compromised eMudhra intermediate CA certificates」（2026年10月20日）／Mozilla Security Blog（2026年10月20日）／LiteLLM「Security incident: Oct 21, 2026」／GitLab「Patch Release: 19.5.1, 19.4.3, 19.3.6 …」（2026年10月21日）／Splashtop「Patch Tuesday October 2026」／The Guardian（2026年10月23日）／The Washington Post「AI Tech Brief: Black October」（2026年10月23日）／Reuters「Indian firm eMudhra exits global digital certificates business」（2026年10月22日）