PHPの緊急脆弱性（CVE-2026-109618）｜対象と今やること

最終更新：2026年10月22日（JST）

10月21日の夜、私たちはこの更新の公開を待ちながら、自社で運用しているWordPressのサイトを1台ずつ確かめていました。PHPの開発チームは21日の早朝（日本時間）に「同じ日の23時に緊急の修正を出す」と予告していて、実際に新しい版が出たのは予告より少し早い22時半ごろでした（私たちの監視での確認）。自社で管理しているサーバーには、公開から1時間ほどで修正を当てています。

一方で、レンタルサーバー（共用サーバー）の上のサイトは、PHPの更新を事業者に任せるしかありません。更新が届くまでの間に自分でできることは限られていて、しかも公式は「一時対策では安全にならない」とはっきり書いています。「自分では上げられないのに、待っている間も狙われうる」。これが、多くの中小企業のサイトにとって一番悩ましい点です。

この記事では、PHPの公式の告知（php.net）とGitHubの2件のセキュリティ勧告、IPAの注意喚起を一次情報にして、何が起きたか、どの環境が対象か、今日やることを順に整理します。私たちが実際に対応して分かった注意点も、該当する箇所に入れました。

なお、10月21日にIPAが出した事前の注意喚起の時点では、IPAはこの2件を悪用した攻撃を確認していません（同じページは、追記があれば更新するとしています）。一方でCloudflareは、公開前に情報が漏れ、攻撃の通信を観測したと公表しています（下の追記）。攻撃が始まっている前提で、更新はできるだけ早く行ってください。

PHPの開発チームが10月21日に公開した内容

今回は、予告から公開までが1日足らずでした。日付は日本時間です（php.netの表記は協定世界時のため、予告は「10月20日」と表示されています）。

2件の中身は次のとおりです。どちらも、壊れたデータや解放済みのメモリを使ってしまう不具合（解放後の使用）で、細工したリクエストを送られると、サーバーの上で任意のプログラムを動かされるおそれがあります。

報道では、海外の研究者が公開した攻撃の実演動画の名前から「PHP2Shell（php2shell）」とも呼ばれています。難しい仕組みは覚えなくて大丈夫です。経営者や担当者が押さえるべきなのは、「ログインしていない第三者のリクエストだけで、サーバーを乗っ取られうる種類の不具合」だという点です。

対象になる環境と、更新後の版

PHPの開発チームは、Webのリクエストを処理しているすべてのPHPを対象としています。サポート中の系列ごとの修正版は次のとおりです。

危険度は、PHPの動かし方（Webサーバーとのつなぎ方）によって違います。GitHubの2件の勧告の評価をまとめると次のとおりです。

もう一つ大事な点があります。CVE-2026-109619で使われたセッションの進み具合の機能（session.upload_progress）は既定で有効で、アプリが session_start() を呼んでいなくても使われます。WordPressのようにセッションを使わないサイトでも、更新が要ることに変わりはありません。

Linuxディストリビューションは、公開前に修正を受け取っていました。ここで一つ注意があります。Ubuntuなどは修正を元の版の番号のまま取り込むため、版の表示が「8.3.36」にはなりません。たとえばUbuntu 24.04の php8.3 は、版の末尾が「0ubuntu0.24.04.13」以降なら修正済みです。修正済みかどうかは、版の末尾まで見て確かめてください。

また、IPAは、PHPがWebアプリだけでなく、ソフトウェア製品やネットワーク機器の中でも使われている場合があると注意しています。社内で使っている機器の管理画面なども、提供元のセキュリティ情報を確かめておくと安心です。

WordPressのサイトで今日やること

次の順に進めてください。上から順に、短い時間でできる作業です。

1. PHPの版を確かめる：WordPressの管理画面の「ツール」→「サイトヘルス」→「情報」→「サーバー」に、PHPの版が出ます。レンタルサーバーなら、サーバーの管理画面でも確かめられます。
2. レンタルサーバーなら、事業者のお知らせを確かめる：管理画面で選べるのは「8.3」「8.4」といった系列で、系列の中の修正（8.3.36など）を当てるのは事業者側、という形が多いはずです。障害・メンテナンス情報のページで、更新の予定と完了を確かめてください（たとえばKAGOYAは10月21日に、影響を調べていること、修正版を確認したうえで順次更新することを告知しています）。8.1以前を選んでいるなら、サポート中の系列に切り替えます。
3. VPSや自社のサーバーなら、更新して再起動する：更新の前にスナップショットかバックアップを取り、OSのパッケージを更新して、php-fpmなどPHPのプロセスを再起動します。私たちは、更新の前と後で主なページの応答（表示できたか、転送されたか）を比べ、変わっていないことを確かめてから作業を終えました。
4. 古いPHPの移行を決める：8.1以前は、開発チームからの修正がもう出ません。8.2も年末で終わります。今日のうちに、いつサポート中の系列へ移すかを決めておきます。
5. ほかのPHPを棚卸しする：問い合わせフォームの古いプログラム、社内の業務システム、機器の管理画面など、サイト以外でPHPが動いていないかを確かめます。IPAも、PHPを使うプログラムの棚卸しを勧めています。

すぐ更新できないときの一時対策

PHPの開発チームは、一時対策について「特定の攻撃の経路を減らすだけで、安全にはしない」と書いています。あくまで更新までのつなぎとして使ってください。公式が挙げている主な対策は次のとおりです。

レンタルサーバーでは、php.iniやFPMの設定に手が届かないことが多く、自分で取れる手は限られます。事業者によっては、.htaccess に残っている古い php_value（mbstring.internal_encoding など）を外すことと、multipartの送信をPHPの手前で止めることはできます。Apache互換の .htaccess で multipart を止めるなら、次のように書けます。

# PHPの更新が来るまでの一時対策：multipart/form-data の送信を止める
RewriteEngine On
RewriteCond %{HTTP:Content-Type} ^multipart/form-data [NC]
RewriteRule ^ - [F]

私たちが実際に試して分かった注意点が4つあります。

• 変数の書き方：「%{CONTENT_TYPE}」と書いても、Apacheの書き換え機能はこの名前を知らないため空のまま扱われ、エラーも出ずに何も止まりません。「%{HTTP:Content-Type}」と書きます。
• 入れる場所：.htaccess の先頭（WordPressの書き換えの規則より前）に入れます。下の階層に、自前の書き換えの規則を持つ .htaccess があると、そこでは親の規則が効かないことがあるので、そちらにも入れます。
• 止まるもの：WordPressの問い合わせフォーム（Contact Form 7など）は、ブラウザからmultipartで送るものが多く、止めている間は問い合わせも届きません。管理画面からの画像のアップロードも止まります。電話やメールの窓口をサイトに案内しておきます。
• 効いているかの確認：入れた後に、multipartの送信が拒否（403）になること、普段の閲覧や通常のフォーム送信が前と同じことを確かめます。Cloudflareなどの前段で止める場合は、サーバーのIPアドレスへ直接届く経路が残っていると抜けるので、その点も確かめます。

この方法で減らせるのは主にCVE-2026-109618の経路で、CVE-2026-109619は別の経路でも狙われえます。PHPが更新されたら、問い合わせを戻すために外すのを忘れないでください。

入られていないかの確かめ方

更新したからといって、それより前に入られていないとは限りません。公式の勧告も「ログにエラーが無いことは安全の証明にならない」としています。更新の前後で、次の点を確かめてください。

• PHPのプロセスの異常終了（エラーログの「exited on signal 11」「Segmentation fault」など）が、急に増えていないか。メモリを壊す攻撃の試行で出ることがあります。
• 画像などのアップロード用のフォルダ（WordPressなら wp-content/uploads）に、拡張子が .php のファイルが無いか。
• 最近変わった .php ファイルのうち、WordPress本体・テーマ・プラグインの更新で説明できないものが無いか。
• 知らない管理者ユーザーや、知らない定期実行（WordPressの予約イベントとサーバーのcron）が増えていないか。
• PHPのプロセスが、データベースや決まったAPI以外の外部へ通信していないか。

私たちの点検では、自分たちが対応のために足した定期実行の変更を、点検の仕組みが「入られた兆候」として拾ってしまう場面がありました。対応中に足した設定やcronは記録しておき、兆候と取り違えないようにしてください。

本当に兆候が見つかったら、サイトをメンテナンス表示に切り替え、ログを消さずに保存してから、ホスティング事業者やセキュリティの専門家に相談します。AIを使った攻撃も含めた中小企業の守り方は、AIサイバー攻撃とは｜中小企業の防御5手でも整理しています。

戻せるか：バックアップと復旧の準備

乗っ取りの被害で一番困るのは、「どこまで戻せばよいか分からない」「戻す先が無い」状態です。今回をきっかけに、次の4点を確かめておくと、最悪の場合でも戻す手順が決まった状態で動けます。

1. ファイルとデータベースの両方を取っているか：WordPressは、画像やプラグインのファイルと、記事や設定のデータベースの両方が無いと戻せません。
2. サーバーの外にも置いているか：同じサーバーの中だけのバックアップは、乗っ取られたときに一緒に消されたり書き換えられたりします。
3. いつの時点まで戻せるか：侵入が疑われたら、侵入より前の時点のバックアップから戻し、PHPを更新してから公開し直します。毎日1回なら、最大で1日分の更新をやり直すことになります。
4. 戻した後に替えるもの：管理者のパスワード、データベースのパスワード、wp-config.php の認証用キー（ソルト）、サイトに置いているAPIキーを替えます。

復旧の手順は、一度でも試しておくと当日に迷いません。年に一度の点検項目にしておくのがおすすめです。脆弱性を突いた攻撃への備えの全体像は、IPAの10大脅威をまとめた「情報セキュリティ10大脅威2026｜AIリスク初選出と企業の対策」でも取り上げています。

よくある質問

Q. レンタルサーバーを使っています。自分で何かする必要はありますか？

A. PHPの更新そのものは事業者が行います。事業者のお知らせで更新の予定と完了を確かめ、管理画面で古い系列（8.1以前）を選んでいるなら、サポート中の系列に切り替えてください。更新までの間は、問い合わせフォームを止めてよいかを決めたうえで、.htaccess でmultipartを止める一時対策も取れます。

Q. WordPressのセキュリティプラグインで防げますか？

A. 防げません。この2件はPHP本体の不具合で、mod_phpではWordPressの処理が始まる前に攻撃が成り立ちます。直す方法はPHPの更新です。

Q. Ubuntuのサーバーで、PHPの版が 8.3.6 のままです。大丈夫ですか？

A. Ubuntuは修正を元の番号のまま取り込みます。24.04の php8.3 なら「8.3.6-0ubuntu0.24.04.13」以降が修正済みです。版の末尾まで見て確かめてください。

Q. 一時対策を入れれば、更新しなくてもよいですか？

A. いいえ。PHPの開発チームは「更新だけが完全な対策」「一時対策は特定の攻撃の経路を減らすだけで、安全にはしない」としています。更新までのつなぎとして使ってください。

Q. この脆弱性を狙った攻撃は、もう起きていますか？

A. 10月21日のIPAの注意喚起の時点では、IPAは悪用した攻撃を確認していません。一方でCloudflareは10月21日、公開前に情報が漏れ、同社の顧客を狙う攻撃の通信を観測したと公表しています。攻撃が始まっている前提で更新を急ぎ、最新の状況はIPAとJPCERT/CCの情報で確かめてください。

まとめ：今日やる3つのこと

1. 自社サイトのPHPの版を確かめ、修正版（8.5.12・8.4.27・8.3.36・8.2.35、またはディストリビューションの修正パッケージ）になっているかを見る。
2. レンタルサーバーなら事業者の更新状況を確かめ、更新までの間の一時対策（multipartを止めるか）を、問い合わせへの影響と合わせて決める。
3. 入られていないかを確かめ、サーバーの外にあるバックアップから戻せるかを確かめる。

次に同じような緊急の更新が出た日の動き方は、WordPressの脆弱性対応｜緊急の更新が出た日に最初にやることに5段でまとめています。

自社のサイトや社内のシステムに、AIの時代の攻撃も含めてどんな穴がありうるかを一通り点検したい方は、事例集と自社点検シートをまとめた「AIエージェント時代のサイバー攻撃 事例集と自社点検シート」も使ってください。

参考・出典

• PHP: Security advisory: Critical remote code execution vulnerabilities, update now／PHP 8.5.12・8.4.27・8.3.36・8.2.35 Released!／Upcoming Critical PHP Security Release（10月20日） — php.net（参照日：2026-10-21）
• RCE via OOM corruption（GHSA-w8hw-w9fx-j79w・CVE-2026-109618） — php/php-src（GitHub）（参照日：2026-10-21）
• RCE via stale global state（GHSA-6wmf-4rv5-p3rp・CVE-2026-109619） — php/php-src（GitHub）（参照日：2026-10-21）
• 【事前準備のお願い】PHPのセキュリティリリース公開予定について — IPA 独立行政法人 情報処理推進機構（公開日：2026-10-21・参照日：2026-10-21）
• CVE-2026-109618 — Ubuntu（参照日：2026-10-21）
• PHPの脆弱性（CVE-2026-109618 / CVE-2026-109619）に関する当社サービスへの影響について — KAGOYA（10月21日 18時20分更新の版・参照日：2026-10-22）
• PHPに深刻度「9.2」の脆弱性が2件発覚、サーバー乗っ取りの恐れで緊急パッチを10月21日に公開へ — GIGAZINE（2026-10-21・参照日：2026-10-22）
• Cloudflare deploys protections against php2shell vulnerability — Cloudflare（2026-10-21・参照日：2026-10-22）
• WAF Release – 2026-10-21 – Emergency – Cloudflare Free Ruleset — Cloudflare（参照日：2026-10-22）