PHP に重大な RCE 2件｜8.4.27 などへ今夜更新・自分のサーバーの確かめ方

はじめに

2026年10月21日、PHP の開発チームが PHP 8.5.12／8.4.27／8.3.36／8.2.35 を公開しました。直したのは 2 件の脆弱性 CVE-2026-109618 と CVE-2026-109619 で、どちらも「認証なしの遠隔コード実行（RCE）につながりうる」もの。深刻度は CVSS v4.0 で 2 件とも 9.2（Critical） です。前日に予告が出ていたこと、同日夜に首相が SNS で対応を呼びかけたこと（2026-10-21）、国内のレンタルサーバー各社が予防のために管理画面などを止めたことも重なり、ふだん PHP を意識しない人にまで話が広がりました。

この記事のゴールは、読み終えたときに次の 3 つが分かっていることです。この穴が社会のどこに効き、放置すると何が起きるのか。更新で何が直り、何が残るのか。そして、個人と、事業者・自治体などの社会インフラの側で、それぞれ誰が何をすればよいのか。 自分のサイトやサーバーが対象かどうかの確かめ方も第 8 節に残しています。状況は時間単位で動いているので、ディストロと事業者の状況は 2026年10月22日 0時30分（日本時間）時点の一次情報の表記で書いています。

🐘 1. PHP とは ── Web ページを「その場で作る」言語

PHP が動いている場所

PHP は、Web サーバーの上で動くプログラミング言語です。ブラウザから「このページをください」というリクエストが届くたびに、PHP のプログラムがデータベースを読み、HTML をその場で組み立てて返します。ブログの記事一覧、ネットショップのカート、問い合わせフォームの送信処理。こうした「アクセスのたびに中身が変わるページ」の裏で、PHP は 30 年近く使われてきました。

使われている量は桁違いです。W3Techs の調査（2026年10月21日）では、サーバー側の言語が判別できたサイトの 69.3% が PHP で動いています。その大きな理由が WordPress で、CMS が判別できたサイトの 58.3% を占めます。WordPress は PHP で書かれているので、WordPress のサイトはそのまま PHP のサイトです。レンタルサーバーの「簡単インストール」で WordPress を入れたことがあるなら、その時点で PHP の利用者です。

リクエストを処理する「ワーカー」

今回の 2 件を理解するのに必要なのは、PHP がリクエストを処理する仕組みです。

PHP は Web サーバーの中に組み込まれるか（Apache の mod_php）、別のプロセスとして待機して Web サーバーから処理を受け取ります（PHP-FPM。nginx と組み合わせるのが定番）。どちらでも、リクエストを処理するワーカーというプロセスが何本か常駐し、1 本のワーカーが次々と別のリクエストを使い回して処理します。毎回プロセスを起動し直すより速いからです。

1 回のリクエストは、大きく ①開始処理（送られてきたフォームやファイルの読み取り）→ ②アプリの実行 → ③終了処理（そのリクエストで使ったメモリの片付け）の 3 段で進みます。今回の 2 件は、どちらもアプリのコードではなく、この①と③の周辺、つまり PHP 本体の中にあります。だから WordPress やプラグインを更新しても直りません。

RCE とは

RCE（Remote Code Execution・遠隔コード実行）は、ネットワーク越しに、攻撃者が選んだプログラムをサーバーの上で動かせてしまう種類の穴です。脆弱性の中でも最も重い部類に入ります。サーバーの持ち主ができることの多くが、攻撃者にもできるようになるからです。具体的に何が起きるかは第 5 節で扱います。

今回は「認証なし」、つまりログインしていない、ただの訪問者のリクエストから届きうる点が重く見られています。PHP の開発チームが確認した影響は「Web のワーカーのアカウントの権限での実行」です。OS の管理者権限ではありませんが、そのアカウントは通常、サイトのファイルとデータベースの接続情報に触れられます。

🗓️ 2. 何が起きたか ── 予告から公開まで 2 日

今回は、修正版の公開の前日に「重大な修正を出す」と予告し、Linux ディストロなどの配布元には事前にパッチを渡しておく、という段取りで進みました。時刻はすべて日本時間です。

• 8月24日: Wiz によると、同社が見つけた問題を PHP に報告（8月19日に発見、9月21日に PHP が受理）
• 10月20日: php.net が「Upcoming Critical PHP Security Release」を掲載。公開は「21 October 2026 at 14:00 UTC」（日本時間 23時）、2 件とも CVSS v4.0 9.2 と予告し、詳細が漏れたり悪用が見つかったりすれば前倒しすると書きました
• 10月21日 日中: IPA が「【事前準備のお願い】PHPのセキュリティリリース公開予定について」を掲載し、PHP を使っているプログラムの棚卸しを依頼。エックスサーバーは 16時から公式サイトと管理画面を予防的に止め、ロリポップも PHP の修正版公開に先立つ緊急メンテナンスに入りました
• 10月21日 21時55分: 高市首相が X で、PHP の 2 件の脆弱性への対応を呼びかけました（全文は第 10 節）
• 22時34分〜23時: GitHub で 2 件のセキュリティアドバイザリ（GHSA）を公開、22時48分と 22時54分に CVE レコードを公開。php.net に advisory と 4 本のリリースが並びました。WordPress.org も 22時44分に告知を出しています
• 22時56分: Ubuntu が USN-8948-1 を公開。Debian も trixie 向けに DSA-6574-1 を出しています（公開時刻は未確認）
• 10月22日 0時16分: Docker 公式 php イメージの更新が official-images にマージ（Docker Hub へのタグの反映は 0時30分時点でまだ）

予告から公開まで約 1 日半、公開と同時に主要ディストロの修正版が揃いはじめた、という流れです。PHP の開発チームは「Linux distributions and LTS vendors received the patches in advance（Linux ディストロと LTS ベンダーには事前にパッチを渡した。訳は筆者）」と書いています。

🌐 3. 社会的影響 ── PHP の上に何が乗っているか

世界の 7 割。国内の内訳を示す一次はない

第 1 節で見たとおり、サーバー側の言語が判別できたサイトの 69.3% が PHP です。ただしこれは世界のサイトを数えた W3Techs の集計で、筆者が確認した公開ページには、国別や業種別の内訳は載っていません。国内の EC・会員サイト・自治体・医療機関・決済の現場で PHP がどれだけ使われているかを示す一次の統計も、見当たりませんでした。

なので、この記事では規模を推定しません。言えるのは、アクセスのたびにページを組み立てるサイトなら、業種を問わず PHP で動いている可能性がある、というところまでです。そして PHP で動いているなら、今回の 2 件は CMS や業種に関係なく、PHP 本体の中で効きます。

どんなサイトで、誰が困るか

困るのは、サイトの持ち主だけではありません。会員・購入者・住民・患者といった利用者の情報が漏れ、サイトの制作や保守を外に委託している企業や自治体（委託元）は、自分で触っていないサーバーの穴の説明責任を負います。ネットショップの決済画面が書き換えられると、入力された瞬間のカード番号が抜き取られる Web スキミングにつながります。手口と国内の事例はサイバー攻撃まとめの記事で整理しました。

社会インフラの問題として扱われた

今回は、修正版が出る前から、事業者・独立行政法人・政府がそろって動きました。

• IPA: 公開前の 10月21日 日中に「事前準備のお願い」を掲載し、PHP を使っているプログラムの棚卸しを依頼
• レンタルサーバー各社: 修正版を待たずに、管理画面などを予防的に停止（エックスサーバーは 16時から）。報道は「国内大手サービスで緊急メンテやサービス停止」と伝えました
• 首相と国家サイバー統括室（NCO）: 公開のおよそ 1 時間前に首相が、公開後に NCO が、X で適用を呼びかけ（全文は第 10 節）

1 つのオープンソースのソフトウェアの更新に、ここまでの範囲が同時に動いた例は多くありません。この記事では、これを PHP が一部の開発者の道具ではなく、社会の情報インフラの一部として扱われた印として読みます。だから対応も、個人のサーバーの話と、社会インフラの話の二層で考える必要があります（第 7 節）。

🔍 4. 2 件の脆弱性 ── どちらも「片付けそこね」の穴

CVE レコードの分類は、2 件とも CWE-416（解放後使用） を筆頭に、例外条件の扱いの誤り（CWE-755）、初期化されていないポインタへのアクセス（CWE-824）などです。影響する版は「8.2.35 未満の 8.2 系」から「8.5.12 未満の 8.5 系」まで、サポート中の 4 系列すべてです。

CVE-2026-109618 ── メモリ不足で処理が途中で止まる

PHP には、1 回のリクエストが使えるメモリの上限（memory_limit）があります。上限を超えると PHP はその場で処理を打ち切ります。php.net の advisory は、問題をこう説明しています。

out-of-memory handling can interrupt PHP while internal request data is only partially initialized. Request cleanup may then treat the invalid data as valid.

（メモリ不足の処理が、リクエストの内部データの初期化が途中のときに PHP を中断させることがある。その後の終了処理が、その不正なデータを正しいものとして扱ってしまう。訳は筆者）

先の図でいえば、①の途中で打ち切られ、③が「半端な状態のメモリ」を片付けようとして踏み外す、という形です。

CVE-2026-109619 ── 前のリクエストの「残り物」を次が使う

もう 1 件は、ワーカーの使い回しに関わります。

request-owned internal state can survive after its backing memory has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it.

（リクエストに属する内部状態が、その裏付けのメモリが解放された後も残ることがある。同じワーカーが処理する後のリクエストが、通常の初期化でリセットされる前にその古い状態を使ってしまう。訳は筆者）

③で片付けそこねた「前のリクエストの残り物」を、次のリクエストの①が使ってしまう。解放済みのメモリを指したまま使うので、解放後使用の典型です。

構成によって危険度が違う

php.net は対象を「PHP-FPM、Apache with mod_php、php-cgi、FrankenPHP、LiteSpeed を含む、Web リクエストを処理するすべての PHP」としたうえで、mod_php のリスクを最も高いと位置づけています。GHSA によると、mod_php ではアプリのコードが動き出す前に、認証なしのリクエストで攻撃が成立することが実証されています。PHP-FPM は、CVE-2026-109618 ではソースコードの分析から「影響を受けうる」とされ、完全な攻撃は実証されていません。一方 CVE-2026-109619 では、条件に合うアプリの処理があれば、FPM でも遠隔コード実行が検証されています。

Red Hat は自社の評価を Important（Critical の一つ下）としています。理由として、RHEL の標準構成は mod_php ではなく PHP-FPM で、「FPM のワーカーは初期化の早い段階で失敗すると終了するため、実際には遠隔コード実行は難しい（remote code execution is difficult in practice。訳は筆者）」と説明しています。開発元と配布元の評価が分かれているのは、同じ PHP でも、どう組み込むかで危険度が変わることの表れです。いずれにしても、直す方法は同じで、修正版への更新です。

発見の経緯にも触れておきます。CVE レコードの謝辞には、報告者として Wiz、Calif.io の研究者、OpenAI が並んでいます。Wiz のブログの見出しは「PHP2Shell: AI uncovers critical RCE vulnerabilities（AI が重大な RCE を見つけた）」です。Wiz は、PHP 5.4 以降のこの 10 年に出たすべての版が少なくともどちらか 1 件の影響を受けると主張しています。php.net が影響する版として挙げているのはサポート中の 8.2〜8.5 で、それより古い版については「PHP の開発チームはもう更新を出さない」という書き方です。

なお、本記事では攻撃の手順や再現の方法には触れません。公式の advisory には技術的な詳細が載っていますが、守る側に必要なのは、放置したときに何が起きるかと、更新で何が変わるかです。次の 2 節でそれを扱います。

⚠️ 5. 対応しないとどうなるか ── 放置の帰結と前例

修正版の公開は、穴の場所の公開でもある

修正版が出ると、どこをどう直したかという差分も公開されます。今回は php.net と GHSA に技術的な詳細まで載りました。守る側には直す手がかりで、攻撃する側には穴の場所の手がかりです。IPA も修正版の公開前の時点で、「攻撃者はこれらの脆弱性を悪用し、極めて短時間で攻撃を実行する可能性もある」と書いています。

その「短時間」は、年々縮んでいます。Mandiant（Google Cloud）が、2023年に公表されて実際に悪用された 138 件の脆弱性を分析した報告（2024年10月公表）によると、悪用までにかかった平均日数（Time-to-Exploit。修正の公開の前後を含む）は次のように変わりました。

2023年の 5 日は、統計上の外れ値 15 件を除いた平均です（含めると 47 日）。それでも、「週末に様子を見てから」では間に合わない日数になっています。

乗っ取られたサーバーで攻撃者ができること

認証なしの RCE が成立すると、攻撃者は Web のワーカーの権限で、サーバーの上で好きなプログラムを動かせます。そこから先は、一般にこう広がります。

• Web シェル（裏口）: サーバーに置かれる小さなプログラムで、攻撃者はその後、ブラウザから何度でも命令を送れます。穴を塞いでも、置かれた裏口は残ります
• 改ざん: 偽のお知らせ、マルウェアの配布ページへの誘導、決済画面の書き換え（Web スキミング）
• 情報窃取: 設定ファイルにあるデータベースの接続情報から、会員情報や問い合わせの履歴を持ち出す
• ランサムウェア: ファイルを暗号化し、盗んだデータの公開をちらつかせて二重に脅す
• 踏み台・ボット化: 別の組織への攻撃の中継点や、大量の通信を送りつける攻撃の送信元に使われる。IPA は、踏み台にされると「意図せずに他組織への攻撃活動に加担してしまう」と書いています

前例：2024年の PHP-CGI の穴と Log4Shell

「修正版が出た穴が、実際にどれくらいの速さで悪用されたか」は、CISA の KEV（Known Exploited Vulnerabilities：悪用が確認された脆弱性の一覧）の掲載日で追えます。

CVE-2024-4577 は、Windows 上の Apache で PHP を CGI として動かす構成の穴でした。発見した DEVCORE は、Windows が日本語（コードページ 932）、繁体字中国語、簡体字中国語の設定で動いていると、認証なしで直接コードを実行できることを確認したと書いています。つまり、日本語の Windows サーバーが条件にそのまま当てはまる穴でした。PHP は 2024年6月6日に 8.3.8／8.2.20／8.1.29 で修正し、CISA は 6月12日に KEV に載せています。KEV の記載では、ランサムウェアの攻撃での利用も「Known（確認済み）」です。

そして IPA は 2024年7月5日、国内での被害をこう書きました。

IPA では、The PHP Group が提供する PHP の脆弱性 (CVE-2024-4577) を悪用した攻撃による被害を確認しています。具体的には、国内の複数組織においてこの脆弱性が悪用され、当該製品が稼働する Web サービスに webshell が設置されていたとの指摘があります。

修正版の公開からおよそ 1 か月の時点で、国内の Web サービスに裏口が置かれていた、ということです。

Log4Shell（CVE-2021-44228）は PHP ではなく Java のログ部品の穴ですが、多くの製品に組み込まれた部品の RCE が、CVE の公開と同じ日に KEV に載った例です。広く使われている部品の穴ほど、攻撃側にとっても一度の準備で多くの標的に届く、ということを示しています。

今回の 2 件は、CISA の KEV（2026.10.21 版・10月21日 14時04分 UTC）には載っていません。2024年の穴は Windows の CGI という限られた構成が対象でしたが、今回はサポート中の 8.2〜8.5 で Web リクエストを処理するすべての PHP が対象です。条件の広さは今回のほうが上です。

🛡️ 6. なぜ更新が必要か ── 更新で何が変わり、何が残るか

修正は何を塞いだか

GHSA は、修正の中身を概念のレベルで説明しています。

• CVE-2026-109618: メモリ不足のときに処理をその場で飛び出す仕組みをやめ、次の安全な区切りで穏やかに止める形と、さらに上の上限を超えたらワーカーごと即座に終了する形に置き換えました。終了処理が半端なデータを見ることはなくなり、メモリの上限という PHP の機能そのものは残ります
• CVE-2026-109619: 前のリクエストに属していた内部状態を、次のリクエストの初期化より前に残さないよう、広い範囲でリセットするようにしました。ChangeLog の表記は「Avoid state corruption via bailout（途中脱出による状態の破損を防ぐ）」です

どちらも、「使い終えたメモリを、正しいデータのつもりで使う」経路を根元で断つ修正です。これで、細工したリクエストでワーカーのメモリを壊し、攻撃者のコードを動かす、という道筋が閉じます。

設定の工夫ではなく、更新が要る理由

第 9 節で紹介する緩和策は、特定の経路を狭めるだけです。CVE-2026-109619 の GHSA は、はっきりこう書いています。

There is no complete generic configuration mitigation as an application, extension or server path may publish stale state or consume it without a predictable log entry.

（設定による完全で汎用的な緩和策はない。アプリ、拡張、サーバーのどの経路も、予測できるログを残さずに古い状態を残したり使ったりしうるからだ。訳は筆者）

古い状態が残る経路は、アプリや拡張の組み合わせの数だけあります。設定で一つずつ塞ぐのではなく、PHP 本体で「残さない」ようにしたのが今回の修正版です。

パッチ版の更新は、互換性を壊さない方針

更新をためらう理由として多いのが、「上げたらサイトが動かなくなるのでは」という心配です。PHP のリリースの方針（php/policies の Release Process）は、8.4.26 から 8.4.27 のようなパッチ版の更新について、新しい機能を加えてはならない（MUST NOT）、PHP のコードから見た API の後方互換を保たなければならない（MUST）と定めています。拡張モジュールのバイナリ互換も、重大なセキュリティ修正では「保つべき（SHOULD）」とされています。

つまり、同じ系列の中での更新は、原則としてアプリを書き換えずに入れられる更新です。8.1 から 8.3 のように系列をまたぐ移行とは、性質が違います。

「更新すれば大丈夫」の範囲と範囲外

🏢 7. 二層の対応 ── 個人と社会インフラ

同じ「更新して再起動」でも、ブログを 1 つ持つ個人と、多くのサイトや住民・顧客のデータを預かる組織とでは、確かめる範囲と、説明する相手が違います。

左の流れは「修正版がどう届くか」、右の流れは「国と基幹インフラの間で情報がどう回るか」です。個人は左の末端に、社会インフラの事業者は左右の両方にいます。

個人の層：自分のサイトとサーバーの持ち主として

個人がやることは、突き詰めると 3 つです。自分の PHP がどこにあるかを知る、修正版を入れてワーカーを再起動する、使っていない PHP は止める。 レンタルサーバーなら PHP 本体の更新は事業者の仕事で、利用者は告知を確かめ、自分のアプリ（WordPress のプラグインなど）を最新にしておきます。自宅サーバーやクラウドの VPS は、持ち主がそのまま当事者です。

学習用に PHP を入れた PC も見落としがちです。外部に公開していなければ攻撃は届きにくいですが、ルーターのポート開放などで公開しているなら、自宅サーバーと同じ扱いになります。具体的な確かめ方は第 8 節にまとめました。

社会インフラの層：組織として、委託先と国まで

組織の側は、「自社のサーバーを更新した」だけでは終わりません。

• 能動的サイバー防御法: 2026年10月1日に本体が施行され、基幹インフラの 15 分野・258 事業者は、重要なシステムのサイバーインシデントやその原因となりうる事象を知ったとき、事業所管大臣と内閣総理大臣に報告する義務を負いました。報告の期限はサイバー攻撃まとめの記事で整理しています。施行の説明資料は、事業者が届け出る導入済みの製品の情報（期限は来年 3 月）と、国が入手する脆弱性の情報を突き合わせ、「ピンポイントで該当する基幹インフラ事業者に速やかに注意喚起する。これにより、AIで加速する脆弱性悪用にも対抗する」と書いています。今回のような穴で、どの事業者が該当する製品を使っているかを国が把握する仕組みが、まさに作られている最中です。なお、基幹インフラ以外の一般企業に新しい報告義務が直接課されたわけではありません
• NCO（国家サイバー統括室）: 内閣官房に置かれた司令塔で、今回は X の「注意・警戒情報」のアカウントで適用を呼びかけました
• IPA と JPCERT/CC: IPA は注意喚起と相談窓口を持ち、今回は修正版の公開前に事前準備を呼びかけました。JPCERT/CC はインシデント報告の受付と調整、注意喚起を担います。10月22日 1時時点で、JPCERT/CC の注意喚起に今回の PHP の件はまだ載っていません
• ホスティング事業者: PHP 本体を一括で更新するのは事業者です。エックスサーバーは、管理画面の再開後に「お客様にも追加の対策をお願いする場合があり」と書いています。利用者は告知を確かめ、自分のアプリの依存を確認します
• 委託先: サイトの制作や保守を外部に任せている企業や自治体は、委託先に「使っている PHP の版」「更新の予定と完了」「侵入の痕跡を確かめた結果」を聞く必要があります。個人情報保護法は委託先への監督を求めていて、2026年10月には委託先を起点にした漏えいの公表が相次ぎました。経緯はサイバー攻撃まとめの記事の委託先の節にまとめています

🔧 8. 個人の層：自分の環境の確かめ方

• WordPress・CMS: WordPress.org は「No WordPress update is required or planned for these issues（この件で WordPress の更新は不要で、予定もない。訳は筆者）」としています。直すのはその下の PHP です。Drupal や Joomla も同じです
• レンタルサーバー: PHP 本体は事業者が更新します。利用者は告知を確かめ、管理画面で自分のサイトの PHP の系列（8.2／8.3 など）を見ておきます
• 自前のサーバー: ディストロの修正版を入れ、PHP のワーカーを再起動します（mod_php なら Apache、PHP-FPM なら php-fpm）。再起動までが更新です
• Docker: 修正版のタグでイメージを取り直し、コンテナを作り直します。ホストの OS を更新しても、コンテナの中の PHP は変わりません
• 8.1 以前: 公式の更新はありません。今回は深刻度を理由に、ソースからビルドする人向けに 7.4・8.0・8.1 用の最小限の修正が php-src のブランチで提供されています。Ubuntu 22.04 の php8.1 のように、ディストロが修正を当てた例もあります

配布元ごとの修正の目印（2026年10月22日 0時30分時点）

ディストロの PHP は、php -v の番号を修正版と比べても判断できません。 たとえば Ubuntu 24.04 の修正版は 8.3.6-0ubuntu0.24.04.13 で、php -v には「8.3.6」と出ます。上流の 8.3.36 より小さく見えますが、Ubuntu が修正を当てた版です。次の表のパッケージ版で確かめます。また php -v が示すのはコマンドラインの PHP で、Web サーバーが使う PHP と同じとは限りません。

Debian 12（bookworm）は、セキュリティトラッカーの表示が 2 件で食い違っています。CVE-2026-109618 では 8.2.35-1~deb12u1 が修正済み、CVE-2026-109619 では同じ bookworm が 8.2.34-1~deb12u1 のまま「vulnerable」です。8.2.35 は上流の修正版と同じ番号なので両方を直したものと読むのが自然ですが、表示がそろうまでは断定しません。Alpine は、セキュリティ情報（secdb）の edge と v3.24 に php85 8.5.12-r0・php84 8.4.27-r0 が載っていますが、0時30分時点ではパッケージの一覧にまだ出ていません。

手順: Ubuntu・Debian（WSL の Ubuntu も同じ）と Docker

sudo apt update
apt list --installed 2>/dev/null | grep -E '^(php|libapache2-mod-php)'
apt policy php8.3              # 自分の系列名に置き換える（php8.1／php8.2 など）

• OK の条件: apt policy の「インストールされているバージョン」が上の表の版以上。足りなければ sudo apt upgrade のあと、sudo systemctl restart apache2（mod_php）か sudo systemctl restart php8.3-fpm（PHP-FPM・系列名は自分のものに）

docker ps --format '{{.Names}}\t{{.Image}}'        # どのイメージで動いているか
docker exec <コンテナ名> php -v                     # コンテナの中の PHP の版

• php:8.4-apache のような浮動タグは、0時30分時点では修正前の 8.4.26 を指していました。Hub のタグが更新されたあとで docker compose pull && docker compose up -d などで作り直します。公式イメージを土台にした自前のイメージも、ビルドし直します

手順: レンタルサーバー

管理画面の「PHP のバージョン設定」では、小数点以下 2 桁目（8.4.27 の「27」）まで出ないことも多いので、そこは事業者の告知で判断します。サポート終了の系列（8.1 以前）を選んでいるなら、この機会にサポート中の系列への切り替えを検討します。WordPress 自体も PHP 8.3 以上を推奨しています。

エックスサーバーは「各PHPバージョンを対象に、公式の修正版や弊社独自の修正を順次適用する予定」としています。さくらの緊急メンテナンスは、ウェブメールやファイルマネージャ、phpMyAdmin などの一部機能を止めるもので、告知に PHP や脆弱性の語はありません。0時30分時点で、利用者がやる具体的な操作を示した事業者はありませんでした。ConoHa WING の告知は、筆者の環境からは取得できませんでした。

🩹 9. 更新できないときの緩和と、構造的な回避

公式が示す緩和策

PHP の開発チームは「only an update is a complete solution（更新だけが完全な解決策。訳は筆者）」としたうえで、すぐに更新できない場合に特定の攻撃経路を狭める設定を挙げています。どれも「これで安全になるわけではない」と明記されています。

• CVE-2026-109618 向け: memory_limit=-1 を、アプリが上書きできない形（FPM のプール設定や Apache の php_admin_value）で設定する。post_max_size を低く（アップロード不要なら 8M、必要なら 32M）し、upload_max_filesize はそれ未満に。Web サーバーやプロキシの側でもリクエストの大きさなどを制限する
• CVE-2026-109619 向け: session.upload_progress.enabled=0 を php.ini などリクエストの解析より前に効く場所で設定し、すべてのワーカーを再起動する。PHP 8.5 では fatal_error_backtraces=0 も
• やってはいけないこと: RLIMIT_AS・RLIMIT_DATA での制限は、かえって問題の経路を呼び込むので使わない。error_reporting・display_errors・@ でエラーを隠しても効果はない

memory_limit=-1 は「PHP のメモリ上限をなくす」設定なので、1 本のリクエストがサーバーのメモリを食いつぶす危険と引き換えになります。php.net もコンテナや cgroup の上限を「可用性の境界」として併用するよう書いています。あくまで更新までのつなぎです。

構造的な回避策としての静的サイト化

もう一つ、今回のような穴を構造的に避ける方法があります。そもそもリクエストのたびに PHP を動かさないことです。

Hugo・Jekyll・Astro のような静的サイトジェネレーターは、記事を書いた時点で HTML を作っておき、サーバーは完成済みのファイルを配るだけにします。アクセスのたびにプログラムが動かないので、今回の 2 件のような「リクエストの処理の中の穴」は、サイト本体には存在しません。

移行するときに PHP が残りやすいのは、お問い合わせフォーム・サイト内検索・会員機能・コメント欄です。ここを PHP のまま別のサーバーに残すと、そこが今回の対象になります。外部のフォームサービスや、検索を JavaScript で行う仕組み、サーバーレスの API などに置き換えるのが定番です。当サイトも WordPress から Hugo に移ったときにコメント欄がなくなり、Azure Static Web Apps と Azure Functions で掲示板を作り直しました。動的な部分を小さな API に切り出すと、守る場所もそこに絞れます。

🏛️ 10. なぜ首相が呼びかけたのか

呼びかけの事実関係

首相は 10月21日夜、X で PHP の 2 件の脆弱性への対応を呼びかけました。首相が特定のソフトウェアの更新を直接呼びかけるのは異例です。投稿の全文は次のとおりです。

高市首相の X 投稿（2026年10月21日 21:55）

皆様に、今夜に対応して頂きたい大至急のお願いです。

多くのウェブサイトで使用されているPHPに関し、PHPのセキュリティチームが、重大な２件の脆弱性に関する注意喚起を行っています。

公開しているウェブサイトでPHPを使用しているか確認し、今夜、10月21日午後11時（日本時間）に公開される修正パッチについて、可及的速やかに適用できるよう準備をお願いします。

修正パッチを速やかに適用することが困難な場合は、例えばウェブサイト等を一時的に停止させることも、リスクを低減させるための有効策の一つと考えられます。

国家サイバー統括室のXアカウントでも関係する情報を発信していますので、そちらも参考にして下さい。

投稿にある「10月21日午後11時（日本時間）」は、php.net が前日に予告した公開時刻「14:00 UTC」と同じです。修正版の公開のおよそ 1 時間前に、「使っているかの確認」と「適用の準備」を求めた形です。すぐに適用できない場合の選択肢として「ウェブサイト等を一時的に停止させること」を挙げていますが、これは第 9 節の公式の緩和策（PHP の設定の変更）には含まれていない選択肢です。

投稿が参照先に挙げた国家サイバー統括室（NCO）の X アカウント「国家サイバー統括室（注意・警戒情報）」（@cyber_forecast）は、同じ夜に次のように投稿しました。

国家サイバー統括室（注意・警戒情報）の X 投稿（2026年10月21日 22:57）

2026年10月21日、多くのウェブサイトで使用されているPHP更新プログラムが公開されました。重大な脆弱性に関するセキュリティ修正が含まれていますので、可及的速やかに適用してください。適切な対応がなされない場合、ウェブサイト等が侵害を受ける可能性があります。

2026年10月22日 0時45分時点で、首相官邸・内閣官房・NCO の Web サイトに同趣旨の掲載はなく、Web 上の政府系の一次情報は IPA の「事前準備のお願い」です。

IPA の掲載は、修正版の公開前の時点で、次のように書いています。

本情報の対象となる2つの脆弱性について、現時点でIPAが悪用した攻撃を確認しているわけではありません。

そのうえで IPA は、サポート終了の古い PHP を使い続けているサイトも見受けられるとし、「攻撃者はこれらの脆弱性を悪用し、極めて短時間で攻撃を実行する可能性もある」として、公開後すぐに適用できるよう準備を求めています。

背景にある 10月1日からの新しい体制

政府は呼びかけの理由を Web で説明していないので、ここからは背景の整理です。2026年10月1日、いわゆる能動的サイバー防御法（正式名「重要電子計算機に対する不正な行為による被害の防止に関する法律」）の本体が施行され、基幹インフラ事業者にインシデント報告の義務が課されました。その司令塔が、内閣官房の 国家サイバー統括室（NCO） です。制度のうち今回の対応に関わる部分は第 7 節に、制度の全体と、2025〜2026年に日本企業が実際にどこから破られたかはサイバー攻撃まとめの記事にまとめています。

🔧 技術者の所感

✅ まとめ

• CVE-2026-109618 と CVE-2026-109619 は、どちらも PHP 本体のリクエスト処理の中の解放後使用の穴。CVSS v4.0 は 2 件とも 9.2。修正版は 8.5.12／8.4.27／8.3.36／8.2.35
• PHP は世界のサイトの 7 割で動く。国内の業種別の規模を示す一次はないが、EC・会員・予約・自治体など、ページを組み立てるサイトなら業種を問わず及びうる。修正版の公開前後に IPA・事業者・首相・NCO がそろって動いた
• 放置すれば Web シェル、改ざん、情報窃取、ランサムウェア、踏み台。2024年の PHP-CGI の穴は修正版から 6 日で KEV に載り、国内でも Web シェルが置かれた
• 更新とワーカーの再起動で今回の 2 件の経路は閉じ、パッチ版の更新は互換性を保つ方針。ただし、すでに置かれた裏口や、CMS・プラグイン・OS の穴は別に片付ける
• 個人は「どこに PHP があるか知る・更新・再起動・確認」、社会インフラは「棚卸し・委託先の確認・報告」まで

この記事で、今回の穴が社会のどこに効き、更新で何が直って何が残り、自分がどちらの層で何をすればよいかまで、たどり着けたはずです。次の一手は、個人なら自分が PHP を管理している場所（VPS・自宅サーバー・Docker）を洗い出し、修正版を入れてワーカーを再起動し、ログを一度見ること。組織なら、委託先とホスティング事業者に版と更新の完了を確かめることです。Red Hat と Amazon Linux の修正版、Docker Hub のタグ、各社の対応完了、KEV への掲載の有無は、出しだい本記事に追記します。

よくある質問（FAQ）

Q. WordPress を更新すれば大丈夫ですか？

A. いいえ。今回の穴は WordPress ではなく、その下で動く PHP 本体にあります。WordPress.org も「この件で WordPress の更新は不要で、予定もない」としています。直すのは PHP で、レンタルサーバーなら事業者が、自前のサーバーなら自分が更新します。

Q. 実際に悪用されていますか？

A. 2026年10月22日 0時30分時点で、悪用は確認されていません。CISA の KEV（10月21日版）に掲載はなく、CVE レコードに付いた CISA の SSVC 評価も悪用「none」です。IPA も「現時点でIPAが悪用した攻撃を確認しているわけではありません」としています。ただし修正の中身が公開された以上、攻撃が組み立てられる前提で早めに更新します。2024年の PHP-CGI の穴は、修正版の公開から 6 日で KEV に載りました。

Q. 個人の小さなサイトでも狙われますか？

A. 狙われます。攻撃の多くは特定のサイトを選ぶのではなく、インターネット全体を自動で走査して、穴のあるサーバーを探す形で行われます。JPCERT/CC も 2026年10月、国内の不正アクセスの調査で、攻撃者が AI を利用して既知の脆弱性のスキャンを行っていたことを確認したと書いています。小さなサイトでも、乗っ取れば Web シェルを置いて踏み台やボットとして使えるので、規模の小ささは狙われない理由になりません。IPA は 2024年の PHP の穴の件で、踏み台にされると「意図せずに他組織への攻撃活動に加担してしまう」と注意しています。

Q. php -v で 8.3.6 と出ます。古いままですか？

A. Ubuntu や Debian のパッケージなら、php -v の番号では判断できません。たとえば Ubuntu 24.04 の修正版は 8.3.6-0ubuntu0.24.04.13 で、表示は 8.3.6 のままです。apt policy php8.3 でパッケージ版を見て、第 8 節の表と比べます。

Q. レンタルサーバーで自分がやることはありますか？

A. PHP 本体の更新は事業者が行います。10月22日 0時30分時点では、各社とも利用者に具体的な操作を求めていません。事業者の告知を確認し、管理画面で自分のサイトの PHP の系列を見ておきます。8.1 以前のサポート終了の系列を使っているなら、サポート中の系列への切り替えを検討します。

Q. ホスティング事業者が PHP を更新してくれるなら、何もしなくていいですか？

A. PHP 本体については、事業者の更新を待てば足ります。ただし、それで片付くのは PHP 本体の穴だけです。WordPress のプラグインやテーマ、自分で入れたライブラリ、自分で選んだ PHP の系列（8.1 以前など）は利用者の担当です。また、更新の前にすでに侵入されていた場合、置かれた Web シェルは事業者の PHP の更新では消えません。事業者の告知（エックスサーバーは利用者に追加の対策を求める場合があるとしています）を確かめ、管理画面のアクセスログや、最近変わったファイルに見覚えのないものがないかを一度見ておきます。

Q. 静的サイトなら PHP の脆弱性は無関係ですか？

A. サイト本体は、リクエストのたびに PHP が動かないので今回の対象になりません。ただし、同じサーバーやアカウントで動かしている別の PHP アプリ（お問い合わせフォーム・管理画面・別のサイト）や、ローカルの開発環境に入っている PHP は別です。第 8 節の手順で php -v と apt policy を確かめます。

Q. すぐに更新できない場合はどうすればいいですか？

A. PHP の開発チームは、memory_limit=-1 を管理者の設定で固定する、post_max_size を低くする、session.upload_progress.enabled=0 にしてワーカーを再起動する、といった緩和策を示しています。ただし「更新だけが完全な解決策」で、緩和策は特定の経路を狭めるだけです。更新までのつなぎとして使います。それも難しい場合や、更新先のない 8.1 以前を使っている場合は、サイトやサーバーを一時的に止めるのも選択肢です。首相の X 投稿は「ウェブサイト等を一時的に停止させること」を有効策の一つに挙げ、WordPress.org も、8.2 より前の PHP を自分で運用しているなら、新しい版へ更新する準備の間はサーバーをオフラインにすることを検討するよう書いています。

関連記事

• 日本企業はどこから破られたのか｜2025〜2026年の侵入口とAI時代の守り方 — 能動的サイバー防御法と NCO の役割、委託先を起点にした漏えい
• PwnEscape（CVE-2026-99999）｜VMのパケットがホストを書き換える穴と確かめ方 — 同じ週の Linux カーネルの穴と、ディストロの版の見方
• curl 8.23.0 で脆弱性24件を修正｜HTTP/2 の解放後使用と自分の curl の確かめ方 — 同じ「解放後使用」の穴と、AI の支援による発見
• Microsoft 10月パッチ 1,400件超｜リスクコホートで自宅PCに効く更新を見分ける — 同じ月の Windows 側の更新
• GitHub Actions に lockfile｜actions.lock でタグすり替えを防ぎ依存を SHA 固定 — 静的サイトにも残る CI/CD のリスク
• 【完全無料】Azure Static Web Apps + Cosmos DB でサーバーレス掲示板 — WordPress から Hugo に移って失った動的機能を作り直した話

参考

• Security advisory: Critical remote code execution vulnerabilities（php.net）
• GHSA-w8hw-w9fx-j79w（CVE-2026-109618）
• GHSA-6wmf-4rv5-p3rp（CVE-2026-109619）
• Release Process（php/policies）
• CISA KEV の JSON フィード
• IPA「PHPの脆弱性（CVE-2024-4577）を狙う攻撃について」（2024年7月5日）
• DEVCORE: Security Alert: CVE-2024-4577
• Mandiant: An Analysis of 2023 Time-to-Exploit Trends
• USN-8948-1（Ubuntu）
• Debian Security Tracker: CVE-2026-109618
• IPA【事前準備のお願い】PHPのセキュリティリリース公開予定について
• WordPress.org: Critical PHP Security Release
• 内閣官房 国家サイバー統括室「重要電子計算機に対する不正な行為による被害の防止に関する法律の施行について」