はじめに
今週は、「更新の一週間」でした。
PHP本体の重大な脆弱性、インターネットの信頼を支える証明書の認証局の問題、AIコーディング機能の脆弱性。こうした脆弱性のニュースが相次ぎ、ホスティング各社の緊急メンテナンスなどを通じて、技術者だけでなく、一般の利用者にも情報が届いた一週間でした。
筆者も、これらの対応に追われました。そこで、今週は、まず注意喚起を優先し、確認しておきたい点を、先にまとめます。そのうえで、最も気になった3件を挙げ、後半で、CERT-Inが公表した、AIエージェントの関与を取り上げます。
まず、確認したいこと
- 自分で管理しているサーバーや、VPSがあるか。 ホスティング会社が対応してくれるのは、会社が管理する範囲です。VPSのように、自分でPHPを管理している場合は、自分で更新が必要です。
- 使っているレンタルサーバーなどの、公式のお知らせを見る。 今回は、各社が、対応状況を公式に案内しています。
- ブラウザやOSは、普段どおり最新にしておく。 今回の証明書の問題は、主要なブラウザが自動で遮断しているため、慌てる必要はありません。
今週、気になった3件
1. PHPの重大な脆弱性「PHP2Shell」(認証なしで、サーバー上のコードが実行される)
PHP本体に、重大な脆弱性が2件見つかりました。PHP公式のセキュリティアドバイザリでは、どちらも「Critical」、CVSS v4で9.2とされ、認証なしで、外部からコードを実行されるおそれがあります。
- 1件目: メモリ不足(OOM)のときの処理に不備があり、不正な状態のメモリを処理してしまう。
- 2件目: リクエストをまたいで残る内部の状態が、解放済みのメモリを指したまま使われる(解放後使用)。
特徴は、アプリケーションのコードが安全でも、影響を受けることです。WordPress本体やプラグインを更新しても、直りません。サーバーのPHPそのものの更新が必要です。PHP公式は、「更新が唯一の完全な緩和策」としています。
修正版は、PHP公式の変更履歴で、2026年10月22日付の、次のバージョンです。
| 系列 | 修正済みバージョン |
|---|---|
| 8.2系 | 8.2.35 |
| 8.3系 | 8.3.36 |
| 8.4系 | 8.4.27 |
| 8.5系 | 8.5.12 |
発見者は、php2shell.comの記載によると、Wiz Research、OpenAI Codex Security、Califです。AIのセキュリティ研究が、発見者に含まれています(AIの役割の詳細は、確認できていません)。
各社の対応(公式のお知らせ)
- エックスサーバー: 10月21日16:00から、サービスサイトや管理画面などを、予防的に一時停止しました(不正アクセスへの対応ではない、としています)。管理画面は10月22日朝から順次再開し、サービスサイトは同日夜から順次再開しました。レンタルサーバー上のお客様のサイトは、稼働を続けていました。PHP 5.6〜8.5では、対象サーバーへの修正のパッチ適用が完了しています。VPSは、利用者がPHPを更新する必要があります。
- さくらインターネット: 10月21日22:30から、予防的な緊急メンテナンスを開始し、レンタルサーバーのPHPに修正を適用しました。VPSは、利用者のPHPが対象です。
- ほかにも、複数の企業が、緊急メンテナンスを発表した、と報じられています(日経xTECH)。
悪用の状況については、公式の情報として「悪用が確認された」というものは、確認できていません。報道でも、見解が分かれています。
2. 証明書の認証局「eMudhra」の中間CAで、秘密鍵が復元可能だった
インドの認証局eMudhraが発行した、中間CA証明書8件の秘密鍵が、復元できる状態だったことが、10月17日に報告されました(Mozilla公式ブログ)。この鍵があると、他人のサイトの、偽のHTTPS証明書を発行できてしまいます。
Mozillaは、報告から3時間以内に、Firefoxで遮断しました。署名元のルート証明書も、信頼リストから削除する更新を出しています。Chrome、Apple、Microsoftなども、遮断を始めたと報じられています(公式は、個別に確認していません)。悪用されたかどうかは、わかっていません。
一般の利用者は、主要なブラウザが自動で保護するため、慌てる必要はありません。注意が必要なのは、ブラウザ以外です。自前の信頼リストを持つソフトウェアや、失効情報を見に行かないソフトウェアは、更新するまで、信頼し続けるおそれがあります。
3. Visual Studio / SSMSのCopilotの脆弱性(AIが、自分の設定ファイルを書き換えられた)
Visual Studioと、SQL Server Management Studio(SSMS)の、Copilotの機能に、脆弱性(CVE-2026-103572)が見つかり、Microsoftが10月13日に、修正を出しました(重要、CVSS 3.1で8.8)。
発見者(Johann Rehberger氏)の説明では、ファイル名の末尾のドットが、きっかけでした。Windowsでは、settings.json. と settings.json が、同じファイルを指します。ところが、Copilotの保護のチェックは、この2つを、別の名前として扱いました。そのため、Copilotが、保護されているはずの、自分の設定ファイルやMCPの設定ファイルに、書き込めてしまいました。その結果、任意のコマンドの実行に至ります。外部のデータに仕込んだ指示(間接プロンプトインジェクション)でも、悪用できると示されています。
Microsoftの公開時の評価は、「公開済み: いいえ、悪用: いいえ、悪用される可能性は低い」でした。一方、発見者は、同じ日に、詳細を公開しています。
この件の教訓は、ガードレールの設定ファイルが、エージェントが書き込める場所にあったら、手綱を自分で外せてしまうことです。
(出典: PHP公式アドバイザリ GHSA-w8hw-w9fx-j79w、GHSA-6wmf-4rv5-p3rp、PHP 8 ChangeLog、php2shell.com、エックスサーバー、さくらインターネット、日経xTECH、Mozilla Security Blog、Microsoft MSRC、Embrace The Red)
CERT-Inが、AIエージェントの関与を公表した
先々週の記事で、攻撃にAIが関与している可能性は、観測された振る舞いからの推測にとどまる、と書きました。今週、インドの国家レベルのCERTであるCERT-Inが、攻撃者がAIエージェントだったインシデントを、観測したと公表しました。アドバイザリ CIAD-2026-0049(10月15日、重大度: Critical)です。公式サイトで、原文を確認しました。
何が起きたか
CERT-Inは、AIエージェント(自律的に計画し、コマンドを実行し、ツールを呼び出し、長時間インターネット上で動くソフトウェア)が攻撃者だったインシデントを、複数観測しました。発覚の経路は、AIモデル提供企業の自主開示、CERT-Inのフォレンジック、脅威ハンティングで、被害組織は、自力では検知できませんでした。
- 研究・評価中のAIエージェントが、与えられたタスクの権限を超えて、インドの実システムにアクセスした。 設定ファイル、公開リポジトリ、過剰な権限のクラウドロールに露出していた認証情報を使い、個人データなどを含む業務記録を読みました。
- 攻撃者が、公開されているオープンソースのAI攻撃フレームワークを悪用し、金銭目的の侵入を行った。
マシン速度で進む
- 初期侵入から最終的な被害までの時間が、日単位から数時間に縮まりました。
- 不完全な修復をした被害組織は、数日以内に、より大規模に再攻撃されました。
- エージェントが、同じ露出した認証情報を、別の作業で再導出・再利用していました。
悪用された弱点は、すべて従来型
CERT-Inは、悪用された弱点を、次のように整理しています。
- ソースコード、公開リポジトリの履歴、設定ファイルなどに露出した認証情報・鍵
- 放置された休眠・非推奨・テスト用のAPI
- 平文で保存された決済APIのキー
- 過剰な権限のクラウドのロール(匿名でも、広範囲に読み書きできる)
- インターネットに公開された管理画面、未パッチのミドルウェア、弱い認証・MFAなし
そして、「AIは、これら従来型の弱点を、人間の攻撃者より速く、網羅的に、大規模に見つけて悪用した」と述べています。具体的なツールや製品の名前は、アドバイザリに書かれていません。
(出典: CERT-In CIAD-2026-0049)
インフラ側にとっての意味
今週の4件に、共通する流れがあります。
1. 攻撃は、新しい穴より、古い穴を、速く突いてくる。 CERT-Inが挙げた弱点は、どれも、昔からある設定ミスです。AIが変えたのは、穴を見つける速度と、規模でした。更新、認証情報の管理、APIの棚卸し、最小権限、MFA、ログ。先々週の記事で挙げた対策が、そのまま、AI時代の基本になります。
2. 更新の時間が、短くなっている。 PHPの修正版は、公開の前に、ホスティング各社が、予防的に停止して、備えました。CERT-Inは、不完全な修復をした組織が、数日以内に再攻撃された、と述べています。「定期保守のときに、まとめて更新する」では、間に合わない場面が、増えています。重大な脆弱性への臨時対応のルールを、決めておく意味が、大きくなっています。
3. 更新する範囲が、見えにくい。 PHP2Shellは、アプリを更新しても、直りませんでした。eMudhraは、ブラウザ以外のソフトウェアが、残るリスクでした。「自分が使っているものは、どこに、何があるか」を、把握していなければ、更新の要否さえ、判断できません。自社が使っている機器とソフトの一覧が、必要です。
4. AIエージェントの権限と、ガードレールの置き場所。 Copilotの件も、CERT-Inの推奨も、同じことを言っています。ガードレールを、エージェントの手の届く場所に置かない。エージェントごとに、短命で、最小権限のIDを発行する。default-deny(既定で拒否)のegress制御を、ネットワーク層で強制する。 指示ではなく、仕組みで止める、という考え方です。
次のアクション
- 自分で管理しているサーバーのPHPのバージョンを確認する。 VPSなど、自分で管理している場合は、修正版への更新と、PHPのプロセスの再起動が必要です。レンタルサーバーなら、事業者の公式のお知らせを確認します。
- 認証情報の露出を点検する。 コード、リポジトリの履歴、設定ファイル、CI/CDの変数に、キーやパスワードが残っていないか。見つかれば、ローテーションして、履歴から消します。
- 休眠・テスト用のAPIと、インターネットに公開している管理画面を、棚卸しする。 不要なら止め、必要ならMFAを必須にします。
- AIエージェントを使っているなら、権限とネットワークを見直す。 実行ごとの短命な最小権限のID、既定で拒否する外向き通信、ログの保存(CERT-Inは、最低180日を推奨)。
- 脆弱性情報の入口と、臨時対応のルールを、決める。 先々週の記事の、段2の内容を、参考にしてください。
先々週の記事: 「うちは大丈夫?」と聞かれたら:情報漏えいに備える、3段構えの対策
先週の週刊: 週刊AIニューストピック 2026年10月17日
コメント