PHP本体の緊急脆弱性（2026年10月）──PHP 8.1以前には修正が出ない。経営者がまず確かめること

最終更新日：2026年10月23日

2026年10月21日、Webシステムを動かすプログラム言語PHPの本体に、ログインしていない第三者が、外からサーバー上のプログラムを動かせる重大な脆弱性が2件公表されました。WordPressもPHPで動いているので、影響を受ける会社はとても多いはずです。しかも、PHP 8.1以前には修正が出ません。この記事は、技術に詳しくない経営者・担当者の方が「自社は関係あるか」「何をすればいいか」を判断できるように、まず結論を書き、技術的な中身は後半に分けて書きます。

まず結論──3行で

• ログインなしで、外からサーバー上のプログラムを動かされる重い脆弱性です。PHPで動いているWebシステム・WordPressのほぼすべてが対象です。
• 修正が出たのは PHP 8.2〜8.5 だけです。それも修正版（8.2.35／8.3.36／8.4.27／8.5.12）以上に更新して、初めて直ります。
• PHP 8.1以前（7系・5系を含む）には修正が出ません。ただし「止める」か「作り直す」かの二択ではなく、新しいバージョンへ上げる道があります。

何が起きたのか

PHPの開発元は、10月20日に「重大なセキュリティ修正を出す」と予告し、10月21日の23時（日本時間）に修正版を公開しました。対象の脆弱性は2件で、どちらも深刻度は「Critical（緊急）」、国際的な評価の数字（CVSS v4.0）では10点満点中9.2です（PHP公式の告知）。

起きうる被害を一言でいうと、サーバーを他人に操作されることです。ログインも、パスワードも要りません。サーバーを操作されれば、そこにあるデータ（お客様の情報を含む）を抜き取られる、画面を書き換えられる、ほかへの攻撃の踏み台にされる、といったことが起こりえます。

さらに悪いことに、この脆弱性の情報は正式な公表の前日に外へ漏れていました（Huntress社の報告）。AWSは、公表の4日前の10月17日に、攻撃を観測するためのおとりのサーバー網で、攻撃の試みを捉えたと報告しています（AWSのセキュリティブログ）。「様子を見てから」ではなく、今すぐ確かめる必要がある種類の話です。

自社は関係あるか──確かめる3つのこと

次の3つが分かれば、自社がどの状況にあるかが決まります。

1. PHPを使っているか。自社で作った業務システムや会員サイトに加えて、WordPressで作ったサイトもPHPで動いています。分からなければ、作った会社・管理している会社に聞くのが確実です。
2. PHPのバージョンは何か。「8.4」ではなく「8.4.27」のように、細かい番号まで確かめてください。今回は細かい番号で直っているかどうかが分かれます。
3. 誰が管理しているか。自社の担当者か、開発会社か、レンタルサーバーの会社か。対応を頼む相手が決まります。

管理している会社に聞くときは、次の文面をそのまま使えます。

「対応済みです」と返ってきたら、何番に更新したのかまで聞いてください。番号で答えられない場合は、本当に修正版になっているかを確かめる必要があります。

バージョン別に、やること

いまのバージョン	やること
8.2.35／8.3.36／8.4.27／8.5.12 以上	修正済み。今回の対応は済んでいます（8.2 は2026年12月31日でサポートが終わります）
8.2〜8.5 で、上の番号より前	修正版へ更新します。多くの場合、比較的すぐにできます
7.4・8.0・8.1	正式な修正は出ません（公式は最小限の緩和策だけ）。新しいバージョン（8.3以上）への移行が必要です
7.3以前・5系	何も出ません。新しいバージョンへの移行が必要です。それまでは前段で守る対策で被害の可能性を下げます

PHPの開発元は、7.4・8.0・8.1 向けに「最小限の緩和策」（完全な修正ではありません）をソースコードの形で出していますが、これは自分でPHPを作り直す人向けのもので、正式な修正版ではありません。また、OSのパッケージ（Linuxの配布元）によっては、古いバージョン向けに独自に修正を入れている場合があります（PHP公式の告知）。

「止めるか、作り直すか」の二択ではない

修正が出ないバージョンを使っていると分かると、「システムを止めるしかない」「作り直すしかない」と考えがちです。実際には、選べる道はもう少しあります。

• 修正版へ更新する（8.2〜8.5 の場合）。いちばん確実で、手間も小さい方法です。
• 前段で守る。WAF（不正な通信を手前で止める仕組み）や、PHPの設定の変更で、攻撃の成功を難しくします。ただしPHP公式は「完全な緩和策は無く、更新だけが安全な選択」としています。あくまで移行までの期限つきの対策です。
• 新しいバージョンへ上げる。プログラムの修正が要ることがありますが、作り直しよりはずっと小さな工事で済むことが多い方法です。
• PHPを使わない形に置き換える。たとえば会社案内のように更新が中心のWordPressサイトなら、PHPを使わない静的なサイトに置き換えれば、今回のような脆弱性の対象から外れます。

どれが合うかは、システムの中身と使い方によって変わります。大事なのは、止めるか作り直すかを決める前に、まず「どこまで上げられるか」を確かめることです。

経営者が考えるべきこと──その仕組みを、誰に任せているか

自転車の整備なら、自分でやっても構いません。でも、自動車の整備を、仕組みを知らない人に任せるでしょうか。Webシステムも同じで、外から誰でも触れる場所に置いてある以上、任せている相手が仕組みを理解しているかが、そのまま会社のリスクになります。

今回のような事態で、任せる相手を見極める目安は2つです。

• バージョンを番号で答えられるか。「たぶん大丈夫です」ではなく、「8.4.27 に更新済みです」と答えられるか。
• 更新した後に、何で動作を確かめたかを説明できるか。バージョンを上げると、見た目は動いていても中身がずれる不具合が起きることがあります。確かめた範囲と、確かめていない範囲を言えるか。

【技術解説】修正版の届き方は、PHPを入れた配布元しだい

（ここから4つの見出しは技術担当者向けの詳細です。要点だけ知りたい方は「まとめ」まで読み飛ばしてかまいません。）

PHP公式の修正版は 8.5.12／8.4.27／8.3.36／8.2.35 です。ただ、実際にサーバーへ届くのは、PHPを入れた配布元（OSのパッケージ・Dockerイメージなど）を通してです。PHP公式によると、Linuxの配布元や長期サポートの事業者には事前に修正が渡されています。自社の環境の配布元の告知を確かめてください。

• Amazon Linux 2023：AWSは修正済みのPHPパッケージを公開しています（AWSのセキュリティ速報）。ただし Amazon Linux 2023 はリポジトリのバージョンが固定されているので、dnf update だけでは新しい修正が入らないことがあります。dnf upgrade --releasever=latest で最新のリポジトリを指定してください。
• Lightsail：AWSは「動いているインスタンスをその場で更新することはできない」とし、更新済みのイメージから新しいインスタンスを作って移す方法を案内しています（同速報）。
• Dockerの公式phpイメージ：修正版のタグが出ています。イメージを作り直して入れ替えてください。7.4 など終了したバージョンのイメージは更新されません。
• ソースから自分で入れたPHP：自分で作り直す必要があります。

更新した後は、実際に動いているPHPのバージョンを確かめてください（php -v だけでなく、Webサーバー経由で動いているPHP-FPMなども）。PHP-FPMなどの常駐プロセスは、再起動しないと古いまま動き続けます。

【技術解説】動かし方の違いと、設定でできる低減策

PHP公式は、Webのリクエストを処理しているすべてのPHP（PHP-FPM・Apacheのmod_php・php-cgi・FrankenPHP・LiteSpeed）を対象としています。そのうえで、最も危険なのは mod_phpで、アプリのコードが動く前に、ログインなしのリクエストで攻撃が成立することが実証されている、としています。PHP-FPMなら安全、というわけではありません。

すぐに更新できない場合の低減策として、PHP公式は次を挙げています（PHP公式の告知）。公式も「これで安全になるわけではない」と明記しています。

• CVE-2026-109618（メモリ不足の処理）向け：memory_limit=-1 を、アプリが上書きできない形（FPMのプールやApacheの php_admin_value）で設定する。post_max_size を小さくする（アップロードが不要なら 8M、必要なら 32M。upload_max_filesize はそれより小さく）。Webサーバーやプロキシでリクエストの大きさを制限する。メモリの上限はコンテナやcgroupで掛ける
• CVE-2026-109619（リクエストをまたいで残る状態）向け：session.upload_progress.enabled=0 を、リクエストの解析より前に効く場所（php.ini・FPMのプール・サーバーの設定）で設定し、すべてのワーカーを再起動する。ini_set() や FPM の .user.ini では効かない。リクエストごとに当てている無効・非推奨の設定を消す

【技術解説】WAFでできること・できないこと

WAFは、移行までの時間を稼ぐ手段としては有効ですが、修正の代わりにはなりません。攻撃側はWAFの検知を避けるように手口を変えてきます。

• AWS WAF：PHP向けのマネージドルール（PHP application managed rule group）が更新されています。既定の版を使っていれば自動で保護され、版を固定している場合は 2.4 以上へ上げる必要があります（2.4 で CVE-2026-109618 も直接検知するようになりました。10月22日時点の最新は 2.5）（AWS WAF マネージドルールの変更履歴）。
• ALB（ロードバランサー）に付けた AWS WAF は、リクエスト本文を先頭の8KBまでしか検査しません（CloudFront は既定で16KB、最大64KBまで広げられます）。それより後ろに仕込まれた内容は見えません。AWSは、上限を超える本文そのものを遮断するルールの置き方を案内しています（AWS WAF の検査サイズの上限）。
• そのほかのWAF（Cloudflareなど）も、各社がルールを出しています。ルールが「遮断」になっているか、「検知だけ」になっていないかを確かめてください。

【技術解説】攻撃を受けていないかの確かめ方

AWSは、攻撃の試みを10月17日に観測しています。調べる期間は公表日（10月21日）からではなく、少なくとも10月17日からにしてください（AWSのセキュリティブログ）。

AWSとJPCERT/CCが挙げている着眼点は次のとおりです（JPCERT/CCの注意喚起）。

• ファイルのアップロードを伴うフォームの送信（multipart/form-data のPOST）に、PHP_SESSION_UPLOAD_PROGRESS という文字列が含まれていないか
• 過去の応答で、不自然に長い、または形式のおかしい PHPSESSID のCookieを返していないか
• 不審な multipart/form-data のリクエストの前後に、PHPのメモリ上限に関するエラーや、500エラーが出ていないか
• PHPのワーカープロセスが、予期せず異常終了したり、頻繁に再起動したりしていないか
• 見覚えの無いプロセスの実行や、ファイルの作成・変更、外部への通信が無いか

JPCERT/CCは、悪用の経路が複数あり、痕跡が残らない場合もあるので、これらが見つからなくても攻撃を受けていないとは断定できないとしています。

痕跡が見つかった場合は、PHPを更新するだけでは不十分です。まずログなどの証拠を保全し、該当するシステムを切り離したうえで、影響の範囲を調べます。侵入された前提で、パスワードや鍵の入れ替えも必要になります。

まとめ

• まず、自社のPHPのバージョンを細かい番号まで確かめる（WordPressのサイトも対象）。
• 8.2〜8.5 なら、修正版（8.2.35／8.3.36／8.4.27／8.5.12）以上へ更新する。
• 8.1以前なら、修正は出ない。前段で守る対策は期限つきと考え、新しいバージョンへの移行を計画する。止めるか作り直すかを決める前に、どこまで上げられるかを確かめる。

アクシアでは、古いPHPのシステムのバージョンアップを、確定価格・短期間でお引き受けしています。どこまで上げられるかは無料で診断します。詳しくは「PHPバージョンアップ」をご覧ください。

一次情報

本文中の各記述の出典は、該当箇所にリンクしています。中でも一次情報にあたるのは以下です（2026年10月23日に確認）。

• PHP公式：Security advisory: Critical remote code execution vulnerabilities, update now
• GitHub Security Advisory：CVE-2026-109618（メモリ不足の処理による破壊）
• GitHub Security Advisory：CVE-2026-109619（リクエストをまたいで残る状態）
• AWS セキュリティ速報 2026-143-AWS
• AWS WAF マネージドルールの変更履歴
• AWS セキュリティブログ：公表前の攻撃の観測（MadPot）
• JPCERT/CC 注意喚起 JPCERT-AT-2026-0033

関連記事

• WordPressコアの緊急脆弱性「wp2shell」──経営者が今すぐ確認すべきこと
• サーバーOSのアップグレード・移行｜作り直さず延命する選択肢
• レガシーシステムとは？問題点と脱却の手法（モダナイゼーション）を解説
• 「保守を断られた」ときに読む──他社が作ったシステムを引き継ぐ条件