コラム

修正から攻撃までの猶予がなくなった — AIが脆弱性を見つける時代の更新の備え

サーバー基盤のイメージ
脆弱性の修正が公開されてから、数日のうちに更新すれば間に合う。その前提が、2026年の秋に崩れました。

PHPで起きたこと ​

2026年10月21日、PHP本体の脆弱性2件（CVE-2026-109618、CVE-2026-109619）の修正版が公開されました。どちらも認証なしで外部からコードを実行されるおそれがあり、深刻度は CVSS v4.0 で9.2です。

本来、こうした脆弱性は開発者と関係者のあいだで情報を伏せたまま修正を準備し、決めた日時に修正版と一緒に公表します。このときは公表の前日から情報が漏れ始めました。脆弱性の番号が誤った公開時刻とともに出回り、報告者側が動く攻撃コードを含む動画を誤って公開し、コピーがすぐに広まりました。事前に修正を受け取っていた企業の一つは、予定より6時間以上早く修正入りのイメージを公開しています。

攻撃はもっと早く始まっていました。Amazon は公表の4日前の10月17日に、自社のハニーポットで悪用の試みを観測したとしています。Cloudflare の CEO は、公表後45分で数万件の攻撃の試行を観測したと投稿しました。米国の CISA は10月26日に、2件を悪用が確認された脆弱性の一覧（KEV）に加えています。国内でも同じ日に JPCERT/CC が注意喚起を出しました。

修正版が出たのは PHP 8.2〜8.5 の各系列です。8.1以前には公式の修正版はなく、最小限のソースの修正が提供されただけでした。古いバージョンのPHPで動いているシステムは、更新しようにも更新先がない状態に置かれたことになります。

AIが見つけ、AIが攻撃を組み立てる ​

PHPの件では、根本原因となる問題を、監査を行っていたセキュリティ企業と OpenAI が同じ日にそれぞれ独立して報告していました。

Linuxカーネルでも同じ流れが見えます。10月末に公表された CVE-2026-98432 は、TCP の接続処理にある競合状態のバグです。Anthropic は未公開の Claude のモデルを使ってこの脆弱性を見つけ、Multipath TCP（MPTCP）を受け付けているサーバーに対して、認証も操作も要らずに遠隔から root で任意のコマンドを実行する攻撃を組み立てました。最初のメモリ漏えいから root での実行まで、約53分だったとしています。深刻度は CVSS 9.8 で、影響はカーネル 4.4 以降の8つの系列に及びます。10月30日の時点で、Ubuntu と Red Hat Enterprise Linux には修正済みのカーネルがまだ提供されていませんでした。

カーネルでは今年、AIを使った調査で見つかった権限昇格の脆弱性が他にも相次いで公表されています。中には、15年近く気づかれずに残っていたものもありました。

数字で見る変化 ​

Google の脅威インテリジェンスチーム（GTIG）が10月1日に公開した分析によると、悪用されたゼロデイ脆弱性は、2025年の月平均8件から、2026年1〜8月には月平均11件に増えました。8月だけで22件です。公開される脆弱性の数そのものも、2026年1月の5,045件から7月には10,477件へと倍増しています。

GTIG は、悪用が増えている主な原因は、すでに公開された脆弱性（nデイ）を素早く攻撃に使えるようにする動きだとみています。修正前後のコードの差分や公開された情報を LLM で分析すれば、攻撃コードを作るまでの時間を大きく縮められる、というのがその見立てです。

何が変わったのか ​

これまでは、深刻な脆弱性が公表されても、攻撃コードが出回るまでに数日から数週間の猶予がありました。その間に検証環境で確かめ、メンテナンスの時間を取って更新する。多くの企業の運用は、この猶予を前提に組まれています。

今は、修正の公開と攻撃がほぼ同時に始まります。PHPの件のように、公表の前から攻撃が始まることもあります。情報を伏せたまま修正を準備する仕組みも、関係者が増えれば漏れることが分かりました。

備えておきたいこと ​

何が動いているかを、すぐに答えられるようにする ​

脆弱性が公表されたとき、最初に問われるのは「自社のどこで、そのバージョンが動いているか」です。PHP や Linux カーネル、Web サーバー、データベースといったミドルウェアのバージョンを、サーバーやコンテナごとに一覧できる状態にしておきます。依存しているライブラリまで含めるなら SBOM（ソフトウェア部品表）を作ります。外部に公開しているサーバーと、そうでないサーバーの区別も要ります。

当日に更新できる仕組みをつくる ​

更新が遅れる理由の多くは、確認に時間がかかることです。自動テストで主要な機能を確かめられ、サーバーを1台ずつ入れ替えながら更新できる構成にしておけば、検証から本番への反映を1日のうちに終えられます。

更新できない間の手を、先に用意しておく ​

修正版が出ていない、あるいはすぐには入れられないこともあります。PHPの件では、リクエストサイズの上限を下げる、特定の機能を設定で無効にするといった緩和策が公式に示されました。WAF でのブロック、機能の一時停止、外部公開の一時的な遮断など、自社のシステムで取れる手を事前に決めておくと、当日の判断が速くなります。

使っていないものを止めておく ​

MPTCP のように、使っていない機能やモジュールが攻撃の入口になることがあります。使っていない機能を止め、外部に公開するポートと機能を必要なものに絞っておけば、影響を受ける脆弱性そのものが減ります。

サポートの切れたバージョンから移る ​

PHP 8.1以前のように、公式の修正が出ないバージョンで動いているシステムは、深刻な脆弱性が見つかるたびに手詰まりになります。更新先があるうちに、サポートの続くバージョンへ移しておくことが、いちばん確実な備えです。

それでも、侵入を完全に防ぐことはできません。入られたあとの被害を小さくする設計については、侵害が続く背景と、被害が大きくなる理由と持っていないデータは漏れないで書いています。

関連するサービス ​

参考 ​

次の脆弱性が公表される前に。

動いているソフトウェアの棚卸しから、当日に更新できる構成、古いバージョンからの移行までご相談ください。

お問い合わせサービスを見る