2026年10月21日にPHPの重大な脆弱性2件を修正するセキュリティリリースが予告されました。詳細はリリース時に公開すると予告され、リリース時刻は同日の日本時間午後11時でした。予告通りそのタイミングで脆弱性の内容と各サポートバージョンの修正版が公開されました。
本記事では、このような緊急時の脆弱性報告に対し、運用面で何をしたか、どのように向き合ったかを記載します。
脆弱性が公表されてからできることは限られていて、差は平時の備えで決まります。起きてから計画・実施するのと、起きた内容に応じて普段のプロセスを微調整するのとでは、雲泥の差があります。実際に何をしていったかを紹介することで、誰かの役に立てれば幸いです。
公表からの数時間で当社が対応したこと
詳細が伏せられた予告を見て、すぐに緊急と判断した
当日のお昼頃、ニュースアプリでアップデートのアナウンスを知りました。
普段は脆弱性の内容とパッチバージョンが合わせて配布されることが多いです。今回は内容を伏せたまま公開予告のアナウンスだけでした。ゼロデイ攻撃（修正版が出る前に脆弱性を突く攻撃）を警戒しつつ、広範囲に影響を与える脆弱性であると私は受け止めました。
このようなアナウンスは珍しかったので、ニュースを読んですぐに緊急対応が必要と判断しました。何をするべきかは後ほど調べるとして、まずはクライアントへ連絡しました。
調べる前に、クライアントへ可能性を伝えた
クライアントへは、まず次のように伝えました。「緊急対応の恐れがあるため、急遽メンテナンスをするかもしれません。何をすべきかは、ある程度分かったタイミングでお伝えします」。やる可能性を先に伝えてから調査に入りました。調べてから報告したのでは準備が間に合わない恐れがあるので、まずは意識の切り替えをお願いしました。
対処すべき内容を大枠で予測できたのが午後5時です。この時点で「今夜、何らかの対応をします」と、やること自体を確定させました。
深夜はパッチを見送り、翌朝に更新した
直前まで確定情報はありませんでした。また、若干情報が錯綜していたため、予想の延長での予防措置を取らず、当日深夜の公開時刻を待ちました。そして内容を確認し、深夜でのパッチバージョンの更新は見送り、暫定対応としてPHPの設定を調整するにとどめました。
暫定策は一部の攻撃経路を防ぎますが、完全な対策ではありません。完全な対策はPHPのパッチバージョンの更新だけです。そのため、パッチバージョンの更新の計画に取り掛かりました。
日々のPHPなどのバージョンアップ運用フローが確立していたので、緊急時にどのプロセスを省いて問題ないか考えるのが容易でした。すぐに今回の計画は完了しました。
翌日の朝9時ごろから、パッチバージョンの更新に入りました。使用しているAmazon Linuxに修正版のパッケージが届いたのが朝9時過ぎだったので、結果的によい判断だったと思います。
日々きちんと運用しているから、プロセスのスキップを計画しやすく、またクライアントの確認作業開始〜確認完了までがスムーズでした。これが今回のよい点だったと考えています。24時間以内にすべて完了できたことは、自信につながりました。
緊急時の対応の速さは、日々の運用の延長線にある
「パッチバージョンを上げる」とはどういうことか
PHPはセマンティックバージョニングと呼ばれるバージョン管理をしており、下記のようなルールがあります。
- メジャーバージョン：PHP 7、PHP 8といった最初の数字
- マイナーバージョン：PHP 8.4、PHP 8.5といったPHP 8.xの2番目の数字
- パッチバージョン：PHP 8.4.21、PHP 8.4.27といったPHP 8.4.xの3番目の数字
この3つのバージョンの種類は明確に定義されており、
- メジャーバージョン：バージョン間で互換性がない場合
- マイナーバージョン：後方互換性があり機能性を追加した場合
- パッチバージョン：後方互換性を伴うバグ修正をした場合
となっております。そのため、一言にバージョンアップと言っても、互換性のないバージョンアップなのか互換性のあるバグ修正のバージョンアップなのかで意味が大きく異なります。そのため、今回のような緊急性の高いパッチバージョンのアップデートであれば、念入りな確認作業がスキップできると判断して、日々の運用フローからいくつかプロセスを省きました。
日々の通常更新フロー
当社では、本番サーバーのミドルウェア更新を、当社からのアナウンスで進めています。流れは次のとおりです。
- 約2週間前に、本番の更新日（平日の日中）をクライアントと決め、関係者に伝える
- 本番サーバーのスナップショットと、データベース（DB）のダンプから確認環境（本番と同等のクローン環境）を作る
- 確認環境でミドルウェア（PHPなど）をアップデートし、関係者に確認してもらう（約1週間）
- 本番アップデート日の2営業日前から、サイトの更新をロックする（ロック期間中に本番環境で記事等を更新した場合は、トラブル発生時に元に戻すときの対象外）
- 本番アップデート前に、本番サーバーとDBのスナップショットを取り直す
- 本番をアップデートして再起動し、作業完了をクライアント・関係者に報告する
- アップデート後のミドルウェア（PHPなど）の一覧をクライアントに渡し、最終更新日を管理シート（台帳）に記録する
クライアントから見ると、再現性の高いフローであること、きちんと自分たちで管理できていること、いつもトラブルなくメンテナンスが完了する安心感があるようです。
上記は最初から完成したものではなく、アップデート作業を繰り返すことで最適な運用マニュアルが確立されました。教科書的なものではなく、現場に最適化された管理ができていると感じています。
この更新フローがあったから、緊急時にどの工程を省くかを決めやすかったです。
戻せる準備があると、判断が速くなる
スナップショットから確認環境を作るので、本番のクローンがたやすく作れます。そのようなインフラ選定をしておくことで、簡単に本番環境と同等のもので実験が可能となります。
確認環境がないと、サイトを運用する側のプレッシャーは大きくなります。壊しても問題のない環境で検証しないと、事前調査の時間が膨大になるか、不確かなまま目をつむって進めることになるのでお勧めしません。
実際にやってどうなるかを検証した方が、調査と計画を続けるより早くて確実です。どこまで詰めてもケースバイケースなので、論理で固めるより実証で詰めた方が早いと考えています。
また、バックアップを取得＆本番クローンの作成に慣れておけば、いざというときに元に戻せる安心感が技術者の緊張をほぐします。
例えばWordPressは、データベースと密に結びついたシステムです。誰が何をしたかは伏せますが、作業ミスが起きたときに、バックアップから復旧した経験があります。バックアップの取得時からミスまでに投入したデータは、復旧できないものとして諦めました。全部を諦めるよりはマシです。
日々の運用ができないケース
古いバージョンを使い続けている
日々パッチバージョンのアップデートを続けていても、マイナーバージョンにはサポートの期限があります（EOL：End of Life、サポート終了）。PHPはサポート期間が決まっており、きちんと長期スケジュールが公表されています。
PHP 8.1のサポートは、2025年12月31日に終わっているため、PHP 8.1以前には、PHPの開発チームからパッチバージョンが配布されていません。ただし、深刻さを考慮して、7.4、8.0、8.1向けに最小限の修正のソースが例外的に公開されました。
PHPのセキュリティアドバイザリ（How to update の節）
更新版（リリース）ではないため、自分で組み込んで当てる必要があります。一部のOSや長期サポートの提供元は修正を独自に提供しています。なお、次の期限も近づいています。PHP 8.2のセキュリティサポートは2026年12月31日までです。
「元に戻してほしい」と相談を受けて、何もできなかったこと
サポート期限内であっても、相談を受けて何もできないことがあります。以下、実際にあった一例です。
WordPressで運用しているサイトがハッキングされたので、元の状態に戻してほしい、という相談を受けました。
ヒアリングしていくと、元の問題のない状態のバックアップがありませんでした。そのため、いつの状態に戻せばよいのか基準が作れませんでした。
また、悪い部分だけを取り除いてほしいとも言われました。しかし、何が原因で侵入されたのかも不明でした。サーバーのメンテナンスの不備なのかWordPressというシステムの不備なのか明確な答えが見つけられませんでした。作った当時から担当者が変わっていった影響もあり、プラグインがきちんと運用管理されておらず、そもそも必要か不要かの判断もできません。実際に一つずつ検証していくと費用が膨大になってしまうため、現実的ではありませんでした。
担当者の切羽詰まった様子は、痛いほど分かります。その一方で、この状態から相談されても何もできず悲しかったです。こうなる前にあるべき運用を実施したいのですが、こうならないと適切な運用の大切さがなかなか理解してもらえません。このギャップをどう埋めればよいのか、いまだに答えが見つかっていません。
システム面であれば私は理解できますが、システム外の話は私も同じように適切な話が理解できていないと思います。そのため専門職の人がアドバイスしてくれた際は、なるべく耳を傾けるよう心がけています。
規模に合った仕組みを平時に決めておく
WordPressを運用する場合
サイトの運用には大きく3つの役割があります。
- インフラの運用：サーバー、OS、PHPなどのミドルウェア
- WordPressの運用：アプリケーション本体、プラグイン、DB
- ホームページやブログの運用：記事の更新や問い合わせ対応など
クライアントから見れば、何か問題があった時にインフラが対処すべきことなのか、アプリケーションが対処すべきことなのかは分からないと思います。そのような状況で「インフラしか分かりません」「アプリケーションの範囲外です」と言い合うのは不毛です。
特にWordPressは、DBも含めて一体型のシステムです。プラグインを使用するためにインフラを調整することもあります。そのため、当社ではある程度全部対応できる状態をスタートラインにしております。そこから必要に応じて関係者といくつかの事例に対処しながら、担当の領域を都度決めていくのが一番建設的だと思います。
繰り返しになりますが、日々の運用をきちんとやることで、不毛なやり取りを避けられるようになると考えています。
緊急時に、決裁者と実務者が話せる関係を
意外に忘れがちですが、平時から決裁者と実務者が会話できる関係（もしくは決裁者にリレーできる関係）を準備することをお勧めします。緊急時は決裁者の判断を仰ぐことになります。また、細かく何度も電話で判断を仰ぐ場面もあります。
その際に初めて会話する相手だと、伝え方や内容の解釈の違いが起きかねず、今回の問題を解消しようとして、なぜか別のトラブルが発生する可能性があります。
普段からコミュニケーションをとっていれば、伝え方に工夫ができ、認識の齟齬が生まれにくくなります。
今回、具体的な内容を調べる前に可能性を伝え、午後5時に「今夜、何らかの対応をします」と確定させることができました。日々の運用から担当者との信頼があるので、一つ一つの細かい判断に、都度の説明や調整が要りませんでした。すぐに準備できたのは、この関係があったからだと考えています。
24時間365日でなくても、運用は成り立つ
過去に、アクセス数があまり多くないサイトで、24時間365日の運用の依頼を受けたことがあります。見積もりは当然高額になり、予算を超えました。ただ、会社の基準として24時間365日相当の運用が条件になっており、話は平行線のまま運用の話は立ち消えになりました。
例えば中小企業のコーポレートサイトであれば、理想の24時間365日の運用はやらず、営業時間内を基準とした運用を提案しています。今回のような営業時間外の対応も、スポットであれば通常の運用の範囲に含められます。そのため、この形を提案しています。
常に人を張り付かせる運用は費用が非常にかかります。理想を目指しつつも、現実的な着地点を見つけることをお勧めします。
また、当社はインフラを選ぶ段階で運用を見越した技術選定を行っております。これをやるだけでリリース後の運用に大きな差が生まれます。例えばサーバーの前にWAF（Web Application Firewall、Webアプリへの不正な通信を手前で止める仕組み）を設定することで、ある程度の不正なリクエストをサーバーに到達させないようにし、運用コストを下げます。
そして普段のサーバー運用では監視ツールを導入しています。障害の2段階手前でアラートが鳴る設計をしており、黄色アラート、赤色アラート、そして障害の3段階です。黄色アラートでいつも対処しているので、本格的な障害を未然に防いでいます。
まとめ
天災と似ていますが、避けられないトラブルが発生するときは必ずあります。それがいつ発生するのかは分かりません。ただ、常日頃から最低限の準備をしていないと、発生時に大きな差が生じます。
今回、24時間以内にすべてを終えられたのは、緊急時に特別なことをしたからではありません。平時の手順をただ短縮しただけでした。そしてその仕組みは万人受けする理想の体制でなくてよいと私は考えています。サービスと会社の規模に合ったもので足りると思います。
まずは、日々の運用の点検から始めてください。
サイトの運用を見直したい方へ
本記事で整理した日々の運用フローと担当領域は会社ごとに異なります。もしも興味を持たれた方は、下記お問い合わせよりご連絡ください。状況を伺いながら論点を整理できればと思います。この記事を書いた本人が対応し、その場で契約や即答をお願いすることはございません。