PHPで作ったアプリケーションに保守はなぜ必要か｜2026年10月のPHPの脆弱性から考える

「PHPで作ったサイトは、問題なく動いているなら手を入れなくてもいいのでは」。保守のご相談で、ときどき耳にする言葉です。

2026年10月21日、その考え方では守りきれない出来事がありました。PHPそのものに見つかった、深刻な脆弱性2件の修正版が公開されたのです。

何が起きたのか。修正版が出るまでの間に、どう対応したのか。そこから見えてきた、日ごろの保守で備えておきたいことを書いておきます。

2026年10月のPHPの脆弱性で何が起きたか

2026年10月21日、PHPの開発元は、PHP 8.5.12、8.4.27、8.3.36、8.2.35の修正版を公開しました。修正されたのは、2件の脆弱性（CVE-2026-109618、CVE-2026-109619）です。

どちらも、認証なしで外部から攻撃でき、悪用されるとサーバー上で任意のコードを実行される可能性があるものでした。いわゆるリモートコード実行の脆弱性で、CVSSのスコアは9.2（10点満点）とされています。

影響を受けるのは、Webのリクエストを処理しているPHPのすべてです。PHP-FPM、ApacheのPHPモジュール（mod_php）、LiteSpeedなど、実行方式は問いません。

公開までの流れは、慌ただしいものでした。日本時間に直すと、次のとおりです。

1. 10月21日 0時ごろ脆弱性のCVE番号が、ネット上の掲示板やSNSで出回り始める。あわせて、10.0という誤ったCVSSスコアも広まった
2. 10月21日 4時30分PHPのセキュリティチームが、修正版の公開予告を前倒しで出す
3. 10月21日 23時修正版を公開。当初の予定だった22日23時から、1日早めた

CVE番号が出回ってから修正版が出るまで、およそ1日。脆弱性の存在は知られているのに、修正する手段がまだない時間が続いたことになります。

PHPの開発を支援するPHP Foundationによると、公開の時点では、実際に機能する攻撃コードは確認されていませんでした。ただ、ApacheにPHPを組み込んで動かす構成（mod_php）では、初期設定のままでリモートコード実行が実証されています。PHP-FPMでも、アプリケーション側の処理の流れによっては同じことが起きると確認されました。

そしてPHPの開発元は、今回の発表にこう書いています。

There are no complete mitigations, updating is the only safe choice.

PHP公式サイト「PHP 8.3.36 Released!」ほか、各バージョンの発表（英語）

完全な緩和策はなく、アップデートだけが安全な選択肢だ、という意味です。特定の攻撃経路を防ぐ緩和策も示されてはいますが、それで安全になるわけではない、と書き添えられています。

なお、PHP 8.1以前のバージョンには、開発元から修正版は提供されていません。PHP 8.2も、2026年12月31日でサポートが終了します。

JPCERT/CCも10月22日に注意喚起を出し、修正版への早めのアップデートとあわせて、すでに侵害されていないかの調査を呼びかけています。PHPを組み込んだ製品や、Linuxディストリビューションが提供するPHPも影響を受ける可能性があるため、それぞれの提供元の情報を確かめる必要があります。

修正版が出るまでの間に当社がしたこと

修正版が出るまでの間、PHPの設定で脆弱性をふさぐ方法はありませんでした。

そこでgrandworkでは、修正版が出るまでPHPを完全に実行できない状態にしました。脆弱性のある処理を、そもそも動かさないという対応です。

「それではサイトが止まってしまうのでは」と思われるかもしれません。そのとおりで、PHPで動くページやお問い合わせフォームは、その間は使えなくなります。それでも、サーバーを乗っ取られるおそれを残したまま動かし続けるより、止めるほうを選びました。

修正版が公開されたあとは、PHPを修正済みのバージョンに入れ替えてから、元の状態に戻しています。

サイトを止めるのは、簡単に決められることではありません。ただ、乗っ取られてから気づいた場合は、改ざんされたファイルの特定と復旧、情報漏えいの調査から始めることになります。止めていた時間よりも、はるかに長い時間がかかるのかもしれません。

こうした判断をすぐに下せるかどうかは、どのサーバーで、どのバージョンのPHPが動いているかを、日ごろから把握しているかどうかで決まる部分が大きいと思います。

PHPのアップデートは誰がするのか

では、PHPを修正版にアップデートするのは誰の仕事なのでしょうか。答えは、サーバーの契約の種類によって変わります。

マネージドサーバーの場合

サーバーの管理までサーバー会社が引き受ける契約（マネージドサーバー）なら、PHP本体に修正版を適用するのはサーバー会社です。利用者は、サーバー会社からのお知らせを確認し、必要に応じてPHPのバージョンを切り替えます。

ただし、どこまでをサーバー会社が担うかは契約によって異なります。PHPのバージョンを選ぶのはどちらか、緊急時にPHPを止めるのは誰か。サーバー会社の案内で、一度確かめておく必要があります。

VPS・Google Cloud・AWSなどの場合

VPSやクラウドの仮想サーバーは、OSから上の管理を利用者が行う契約です。

AWSは、責任共有モデルの説明の中で、仮想サーバー（Amazon EC2）のOSの管理は、アップデートやセキュリティパッチの適用も含めて利用者の責任だとしています。利用者がインストールしたアプリケーションも同じです。Google Cloudも、Compute EngineのようなIaaSでは、セキュリティ上の責任の大部分は利用者にあると説明しています。

つまり、PHPを修正版にアップデートするのも、修正版が出るまで止めるかどうかを判断するのも、利用者です。サーバー会社が代わりに対応してくれるわけではありません。

表のとおり、アプリケーションのアップデートは、どちらの契約でも利用者に残ります。マネージドサーバーだからといって、すべてを任せられるわけではありません。

PHPを上げても終わりではない

今回はPHP本体の脆弱性でした。ただ、PHPで動くサイトやアプリケーションには、その上にもアップデートが欠かせないものが載っています。

WordPressで公式にサポートされているのは、最新のバージョンだけです。古いバージョンにも重大なセキュリティ修正が提供されることはありますが、あくまでセキュリティチームの厚意によるものです。プラグインやテーマの脆弱性は、それぞれの開発者が修正するため、本体とは別にアップデートを追う必要があります。

Laravelは、バージョンごとにサポート期間が決まっています。バグ修正は18か月、セキュリティ修正は2年です。たとえばLaravel 11は、2026年3月12日でセキュリティ修正も終了しました。Laravel 12はバグ修正が2026年8月13日で終わり、セキュリティ修正は2027年2月24日までです。

Composerで導入しているライブラリも同じです。アプリケーションが使っているライブラリの一つひとつについて、アップデートが出ていないかを確認していくことになります。

もう一つ、PHPのバージョンを上げると、古い書き方のアプリケーションやプラグインが動かなくなることがあります。PHPのバージョンアップの前後に確認しておきたいことは、PHP 8.2のサポート終了に備える記事に書いています。

日ごろから備えておきたいこと

今回のようなことは、いつ起きるか分かりません。いざというときにすぐ動けるよう、日ごろから備えておきたいことを挙げておきます。

• セキュリティ情報を受け取れるようにしておくPHPの公式サイト、WordPress、Laravel、使っているプラグインのリリース情報を、誰が確認するかを決めておきます。今回は、公開予告から修正版の公開まで1日もありませんでした。
• どこで何のバージョンが動いているかを一覧にしておくサーバーごとに、PHP、WordPressやLaravel、プラグインやライブラリのバージョンを書き出しておきます。セキュリティ情報を見たときに、自分たちが対象かどうかをすぐに判断できます。
• 復元できるバックアップを取っておくバックアップは取るだけで終わらせず、実際に復元できるかを試しておきます。復元の考え方は、WordPressの復旧の記事に書いています。
• アップデートを試せる検証環境を用意しておく本番と同じ構成の検証環境があれば、修正版を適用しても問題なく動くかを先に確かめられます。進め方は、メジャーアップデートと検証環境の記事に書いています。
• 緊急時の停止手順と連絡体制を決めておく誰が止める判断をするか、どうやって止めるか、社内やお客様の誰に連絡するか。決めておけば、深夜に情報が出ても迷わずに動けます。

当社の保守でお引き受けしていること

当社のWordPress保守では、WordPress本体、プラグイン、テーマのアップデートと、毎日のバックアップをお引き受けしています。サーバーを当社で用意するプランもあり、VPSやクラウドで運用する場合は、構成をうかがってお見積もりします。

WordPress以外のPHPで作られたアプリケーションや、1回だけの対応は、内容をうかがったうえで、お引き受けできるかをお伝えします。

問題なく動いているサイトほど、手を入れる理由は見えにくいものです。けれど、備えが要るのは、何も起きていない今のうちなのかもしれません。