PHP脆弱性に学ぶ
「更新が怖くないWebサイト」の作り方

2026年10月、PHP本体に、最高ランクの「緊急（Critical）」に当たる深刻度（CVSS 9.2）の脆弱性が見つかり、世界中のWebサイトが一斉に緊急アップデートを迫られました。これは「たまたま起きた事故」ではなく、Webサイトの作り方そのものが問われる出来事です。本記事では、何が起きたのかを平易に整理したうえで、これからのサイトが目指すべき「更新が怖くない」状態について考えます。

今回、PHPに何が起きたのか

2026年10月21日、PHPの開発チームが2件の重大な脆弱性（CVE-2026-109618／CVE-2026-109619、通称「php2shell」）を修正する緊急アップデートを公開しました。深刻度はCVSS v4.0で9.2、評価は最高ランクの「Critical（緊急）」です。修正版は PHP 8.5.12、8.4.27、8.3.36、8.2.35 です。

怖いのは、攻撃にログインが要らないことです。インターネット越しにサーバーへ細工したリクエストを送るだけで、サーバー上で攻撃者の好きなプログラムが動いてしまう（リモートコード実行）おそれがあります。PHP公式の発表によれば、Apache の mod_php 構成ではアプリのコードが動き出す前に攻撃が成立する例が示されており、この構成が最もリスクが高いとされています。

出典: PHP「Security advisory: Critical remote code execution vulnerabilities, update now」（2026年10月21日）

PHPはWebサイトを動かす土台として世界中で広く使われています。WordPressをはじめ、多くのサイトがPHPの上で動いているため、影響範囲は非常に広くなります。PHP公式は、Webのリクエストを処理しているPHPはすべて危険にさらされているとし、回避策は「露出を減らすだけで、安全にはならない」「完全な解決は更新だけ」と明言しています。

出典: PC Watch「深刻度9.2のPHP脆弱性『PHP2Shell』、OpenAIが影響確認ツール公開」（2026年10月22日）

「うちのサイトは狙われない」は通用しない

「有名でもないし、個人情報も扱っていないから大丈夫」——これが今回いちばん危険な誤解です。

理由は3つあります。まず、攻撃者はインターネット上のサーバーを総当たりで調べ、脆弱なサイトを自動で見つけて攻撃します。知名度は関係なく、「見つかった順」に狙われます。

次に、今回の攻撃の狙いは「データ」ではなく「サーバーを動かす権限」そのものです。盗むものがなくても、乗っ取ったサーバーは攻撃者にとって価値があります。

そして、乗っ取られたサーバーは、迷惑メールの送信元、他のサイトへの攻撃の踏み台、偽の詐欺サイトの設置場所に使われます。つまり、被害者でありながら、知らないうちに加害の片棒を担がされることになります。

実際、修正版の公開前から攻撃とみられる通信が検知されたとの報告があり、国内でもレンタルサーバー各社や複数のWebサービスが、緊急メンテナンスやサービスの一時停止に踏み切りました。

出典: セキュリティ対策Lab「PHPの重大な脆弱性『php2shell』、修正版と国内サービスの対応状況」（2026年10月21日）

表示するだけのサイトでも、守るべきは「個人情報」だけではなく、「サーバーという土台そのもの」なのです。

本当の難所は「古くて直せない」状態

今回の修正は、サポート中のPHPを使っていれば、更新を当てるだけで済みます。問題は、「古すぎて更新できない」サイトです。PHP 8.1 以前はすでにPHPプロジェクトのサポートが終わっており、一部の古い版向けに個別の修正が提供されているものの、さらに古い版や、誰も面倒を見ていないサーバーには修正が届きません。

PHPは大きなバージョンアップで、古い書き方を意図的に廃止します。これは「後方互換性（新しいものが古いものを受け入れる性質）」がある程度で切れる、ということです。その結果、古いPHP向けに書かれたサイトを新しいPHPに載せ替えると、アプリがエラーで動かなくなります。

そして古いアプリには「前方互換性（古いものが将来の変化を受け入れる性質）」がありません。両方向に橋が架からず、「新しいPHPは古いコードを拒む」「古いコードは新しいPHPに適応できない」という行き止まりになります。

作った業者はもういない、仕様書もない、触ると全部壊れる——だから誰も直せず、サポートが終了（EOL）した古いPHPに居座り続ける。こうなるとセキュリティ修正も届かず、「直したいのに直せない」状態に閉じ込められます。

これからの理想——「更新が怖くない」構造

理想は「頑張って更新する文化」ではなく、「更新してもほぼ何も起きない構造」を最初から作ることです。更新の手間（＝コスト）が下がらない限り、企業は後回しにします。そこで、次の5つを設計の時点で仕込んでおくのが効きます。

• 小さく常に更新する。3年放置して一気に上げるから高くつきます。こまめに当てれば、毎回の差分が小さく、壊れても原因がすぐ分かります。
• 壊れたことを自動で検知する。主要な画面や申込フローが通るかを自動でチェックすれば、更新の手間の大半（手作業の動作確認）が消えます。
• 持ち物を減らす。サーバーやPHPを自前で持たなければ、パッチ当ては自分の仕事ではなくなります（サーバーレス、マネージドサービス、静的サイト化）。
• いじり過ぎない。独自改造が多いほど、更新時の互換性の問題が増えます。標準構成を保てば、載せ替えも安く済みます。
• 維持費として予算化する。更新を「臨時の出費」ではなく、電気代や家賃と同じ「継続的な維持費」として扱います。

全部は難しい企業でも、せめて「自動更新をオンにする」「マネージドサービスやSaaSに寄せる」「EOLの半年前に載せ替えると決めておく」の3点だけでも効果は大きいです。

JumpStackがお手伝いできること

今回のような騒ぎのたびに困るのは、「自社や取引先のサイトが、何で動いていて、どれが危ないのか把握できていない」状態です。最初の一歩は、いつも「棚卸し」です。

JumpStackでは、次のような形で伴走します。

• お持ちのサイトが何で動いているか、どのバージョンが古いかの棚卸しと優先度付け
• 緊急時の更新・暫定的な緩和策の手順化と、実際の対応
• 中長期では、「更新が安くなる構造」（サーバーレス化、自動検知、標準構成への整理）への作り替え

「何から手をつければ…」という段階からで構いません。まずは自社サイトのPHPのバージョンを確認するところから、お気軽にご相談ください。

あわせて読む: ＠IT「PHPの重大脆弱性『php2shell』、パッチ公開まで待てない　GMOが示した暫定策と注意点」（2026年10月21日）