脆弱性対応。あなたのチームは「止める手順」と「対応準備」できていますか？

Last updated at 2026-10-22Posted at 2026-10-22

はじめに

監視の強化も大事ですが、脆弱性への備えで見落とされがちなのが、「止める手順」と「上げる手順」を平時に書いておくことです。この記事では、その手順に何を書いておけばよいかをまとめます。

2026年10月21日、PHPに緊急レベルの脆弱性が2件あると予告されました。どちらもCVSS v4.0で9.2（Critical）です。PHPの開発元は、詳細・影響バージョン・修正版を同日23時のアップデート公開と同時に明かすとし、すぐ適用できるよう事前準備を呼び掛けました（ITmedia NEWS）。

これを受けて、保育園向けSaaS、ゲーム、ECサイト作成サービス、レンタルサーバなど、著名なサービスが相次いで緊急メンテナンスに入ったり、予告したりしています（具体的なサービス名はITmedia NEWSの記事を参照）。

状況を整理するとこうです。

脆弱性の中身は、まだ分からない
修正版は、今夜23時に出る
出たら、すぐ当ててほしい

このとき動けるかどうかは、監視ツールの有無では決まりません。「サービスをどう止めるか」「PHPをどう上げてデプロイするか」が、手順として用意されているかで決まります。

直前の10月中旬にも、Linuxカーネルに18年間眠っていたVMエスケープの脆弱性（通称PwnEscape）が公開されたばかりです（Qiita：tomy0610さんの解説）。言語・ライブラリ・OSのどこかで、次の脆弱性は必ず出ます。

脆弱性もインシデントも「たまに起きること」ではない

CVEの公開件数は毎年過去最多を更新しており、2026年は約7万件のペースです。国内のインシデントも同時に増えています。

CVE件数は加速している

期間	公開CVE件数	前年比
2023年（通年）	28,817件	—
2024年（通年）	39,962件	—
2025年（通年）	48,185件	+20.6%
2026年（上半期のみ）	35,364件	前年同期比 +49.5%

出典：2025 CVE Data Review、CVE Mid-Year 2026 Check-In（Jerry Gamblin）

2026年は上半期だけで、2024年以前のどの年の通年よりも多い件数です。約7.4分に1件のペースです。
通年では約7.1万〜7.2万件と見込まれています。
件数は集計方法で変わります（2025年を44,146件とする集計もあります）。ただ、どの数え方でも9年連続で増えています（Dark Reading）。

国内のインシデントも増えている

ランサムウェア：2026年上半期の国内被害報告は123件で、統計開始以降、半期として過去最多です。脆弱性探索などの不審なアクセスも前年同期比50.7%増でした（警察庁、@IT）。
Webシステム経由の情報漏えい：国内法人のWebシステムからの個人情報漏えい公表は、2024年62件、2025年84件に対し、2026年は10月6日時点で119件。うち約68%（81件）が7月以降に集中しています（マクニカセキュリティ研究センター）。
10月の急増：10月に入って国内組織のインシデントが急増し、10月7日には大手クラウドサービスの基盤そのものがランサムウェア被害に遭いました（MONOist）。

脆弱性の公開から実被害までは早い

OSSのBIツール「Metabase」のSQLインジェクション脆弱性（CVE-2026-72898、CVSS 10.0）は、2026年8月6日に修正版が公開され、8月14日にJPCERT/CCが注意喚起を出しました（ScanNetSecurity）。

その後、国内で被害公表が続きました。あるフィットネスサービスでは、Metabaseの脆弱性を悪用した不正アクセスで約44万件のアカウント情報が取得されました。最初の不正アクセスは修正版公開のわずか5日後、8月11日でした（ScanNetSecurity）。別の企業も9月18日、同じくMetabaseの脆弱性を悪用され約6万件の情報が取得されたと発表しています（ScanNetSecurity）。

修正版が出てから数日のうちに攻撃が始まり、更新が遅れた組織が被害に遭う。この流れが、いま実際に起きています。

全部をすぐ直すのは無理

2026年上半期のCVEのうち、悪用が確認されてCISAのKEV（悪用済み脆弱性カタログ）に載ったものは0.24%でした（Jerry Gamblin）。

年7万件をすべて即日対応するのは現実的ではありません。だからこそ、「どれを止めて、どれを急いで上げるか」を、その場で考えずに済む状態にしておく必要があります。

監視も大事。でも足りないのは「手順」

脆弱性を知る手段は、すでにたくさんあります。ニュース、ベンダーの告知、Dependabotなどのアラートで、重大なものはほぼ確実に耳に入ります。足りないのは、知ったあとに迷わず動くための手順です。

緊急時は、次の3つが同時に起きがちです。

判断する時間がない：今回のPHPのように「数時間後にパッチが出る」と言われると、手順を考えながら作業する余裕はありません。
夜間や休日に起きる：公開時刻は選べません。日本時間の深夜になることも多いです。
詳しい人がいるとは限らない：そのサービスを作った人が、休暇中だったり退職していたりします。

手順書があれば、この3つをまとめて軽くできます。考えるのは平時に済ませておき、当日は手順をなぞるだけにする、という発想です。

平時に用意しておく4つのこと

用意しておくのは「棚卸し」「止める手順」「上げる手順」「連絡体制」の4つです。どれも、緊急時にゼロから考えると時間がかかるものです。

1. 棚卸し：何が、どのバージョンで動いているか

「PHPに脆弱性」と聞いて、自分たちが影響を受けるかを数分で答えられるでしょうか。答えるには、次の一覧が必要です。

項目	例
サービス名	会員サイト、管理画面、バッチ
言語・ランタイムとバージョン	PHP 8.3、Node.js 22、Java 21
主要なフレームワーク・ライブラリ	Laravel、Spring Boot、Nuxt
動いている場所	EC2、コンテナ、Lambda、レンタルサーバ
OS・ベースイメージ	Ubuntu 24.04、Amazon Linux 2023
担当者・リポジトリ	誰が詳しいか、コードはどこか

ポイントは、インストールされているものではなく、実際に動いているもの を書くことです。パッケージを更新しても、再起動やデプロイをするまで古いものが動き続けるからです。

依存ライブラリまで一覧にするのが大変なら、lockファイル（package-lock.json、composer.lock など）の場所を書いておくだけでも十分役に立ちます。

2. 止める手順：サービスを安全に止められるか

修正版が出るまで待てない、修正版を当てるまで危ない、というときは止める判断も必要です。今回のPHPの件で各社が緊急メンテに入ったのも、この判断です。

手順書には次のことを書いておきます。

止め方：メンテナンス画面への切り替え方。ロードバランサーのルール変更、CDNでの切り替え、設定フラグなど、具体的な操作まで
止める範囲：全体を止めるのか、外部公開部分だけか、特定の機能だけか
誰が決めるか：止める判断をしてよい人（夜間に連絡がつかない場合の代わりの人も）
告知文のテンプレート：ユーザー向けのお知らせ、問い合わせ窓口向けの説明
止めたときの影響：止まると困る取引先や連携先、データの整合性
戻し方：メンテナンス画面を外す手順と、再開前の確認項目

「止める」は最後の手段に見えますが、手順がないと、止めるべき場面でも止められません。

3. 上げる手順：レイヤーごとに、戻し方まで

「アップデートする」と一言で言っても、対象によって手順はまったく違います。レイヤーごとに分けて書いておくと、当日迷いません。

レイヤー	例	手順に書くこと
言語・ランタイム	PHP、Node.js、Java	バージョンの指定箇所（Dockerfile、IaC、サーバ設定）、ビルドとデプロイの方法
依存ライブラリ	npm、Composer、Maven	更新コマンド、lockファイルの扱い、破壊的変更の確認方法
OS・カーネル	Ubuntu、Amazon Linux	パッケージ更新の方法、再起動が必要かと再起動の順番
コンテナイメージ	ベースイメージ	イメージの再ビルドと入れ替え方
マネージドサービス	Lambdaランタイム、RDS	事業者側の対応か、自分たちの作業かの切り分け

それぞれ、次の流れを1セットで書いておきます。

検証環境で上げる
動作を確認する（最低限のテスト項目を決めておく）
本番に反映する
本番で確認する
問題があれば戻す（ロールバック）

特に大事なのは5の戻し方です。急いで当てたパッチで別の不具合が出ることは珍しくありません。戻し方が決まっていれば、怖がらずに上げられます。

4. 連絡体制：夜でも、誰に連絡して誰が作業するか

手順書があっても、作業する人が決まっていなければ動けません。

脆弱性情報を最初に見た人が、誰に連絡するか
夜間・休日の連絡手段（チャット、電話）
作業担当と、判断担当（止める・上げるを決める人）
外部委託先やインフラ事業者の連絡先

組織の規模によっては、「連絡先が書いてある1枚の紙」だけでも効果があります。

チェックリスト

自分のチームで、はい・いいえで答えてみてください。いいえが付いたところが、次に手順を書く場所です。

棚卸し

担当するサービスごとに、言語・ランタイムのバージョンを答えられる
本番で実際に動いているバージョンを確認する方法を知っている
依存ライブラリの一覧（lockファイル）の場所が分かる

止める手順

メンテナンス画面に切り替える操作が、手順として書いてある
止める判断をしてよい人が決まっている（代わりの人も）
ユーザー向けの告知文のテンプレートがある
メンテナンスから戻す手順と確認項目がある

上げる手順

言語・ランタイムのバージョンをどこで指定しているか分かる
依存ライブラリを更新してデプロイする手順がある
OS・ベースイメージを更新する手順がある（再起動の要否も）
更新後に確認する最低限のテスト項目が決まっている
問題が出たときのロールバック手順がある

連絡体制

脆弱性情報を見た人が、最初に誰へ連絡するか決まっている
夜間・休日でも連絡がつく手段がある
外部委託先・インフラ事業者の連絡先がまとまっている

仕上げ

手順書を、実際に一度なぞってみた（訓練やリハーサル）

まとめ

次の脆弱性は、いつ来るかは分からなくても、来ることだけは確実です。そのときに効くのは、平時に書いておいた「止める手順」と「上げる手順」です。

何がどのバージョンで動いているかを、一覧にしておく
サービスの止め方と戻し方を、操作レベルで書いておく
言語・ライブラリ・OSの上げ方を、ロールバックまで含めて書いておく
夜でも、誰に連絡して誰が作業するかを決めておく

また、普段から依存ライブラリをこまめに更新しているチームほど、緊急時のアップデート作業も楽になります。何年も更新していないライブラリを一晩で安全に上げるのは難しいからです。RenovateやDependabotのようなツールは、こうした日頃の更新を続けるのに役立ちます。

まずはチェックリストで、いいえが付いた項目を1つだけ手順にしてみてください。次の緊急メンテの夜に、その1枚が効きます。

参考資料

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up