本記事のポイント
■ PHPの開発チームは2026年10月21日（日本時間同日夜）、認証なしで遠隔からコードを実行されるおそれのある脆弱性2件を修正したPHP 8.5.12・8.4.27・8.3.36・8.2.35を公開しました。
■ 対象はWebリクエストを処理するすべてのPHP環境で、PHP公式は設定変更による暫定策では安全にならず、更新だけが完全な対策だとしています。
■ サイト運営者は棚卸しと更新を、広告代理店は配信先LP・計測・クライアント連絡の確認を進める必要があります。

PHPは、企業サイトやWordPress、広告の遷移先となるLP、問い合わせフォームなど、多くのWebサイトで使われているプログラミング言語です。

今回のニュースを受けて、「自社サイトやクライアントのLPは対象なのか」「広告配信は止めるべきなのか」と迷った方も多いのではないでしょうか。

2026年10月21日、PHPの開発チームは深刻度の高い脆弱性2件（CVE-2026-109618、CVE-2026-109619）を修正したセキュリティリリースを公開しました。国内でも、IPA（情報処理推進機構）や国家サイバー統括室が修正版の速やかな適用を呼びかけています。

本記事では、PHP公式と公的機関の発表をもとに、脆弱性の概要と、サイト運営側がすべきこと、広告代理店が確認すべきことを整理して解説します。

※本記事は、PHP公式および公的機関が発信する情報をもとに、2026年10月22日時点の内容で作成しています。状況は今後変わる可能性があるため、最新かつ正確な情報は必ずPHP公式・IPA・ご利用中のサーバー会社などの発表をご確認ください。

目次

10月21日に何があった？PHPの重大な脆弱性2件と修正版の公開

2026年10月20日から21日にかけて、PHPの開発チームによる事前告知、国内の公的機関による注意喚起、修正版の公開が短い間隔で続きました。公式の告知から修正版の公開まで、約1日という短い期間での出来事です。

そもそもPHPとは？「脆弱性」とは？

PHPは、Webサイトの裏側（サーバー）で動くプログラミング言語です。問い合わせフォームの送信、会員ログイン、記事の表示など、アクセスに応じて内容が変わるページの多くは、サーバー上のプログラムが処理しています。WordPressもPHPで作られているため、WordPressで作ったサイトやブログもPHPの上で動いています。

脆弱性とは、プログラムの不具合のうち、悪用されると情報の盗み見やサイトの改ざんなどにつながるものを指します。今回の脆弱性は、個々のサイトの作りではなくPHPそのものにある不具合です。そのため、サイトをどれだけ丁寧に作っていても、PHPが古いままだと影響を受けるおそれがあります。

対策は、不具合を直した新しいPHP（修正版）に入れ替えることです。この入れ替え作業を「更新」や「パッチの適用」と呼びます。

事前告知から修正版公開までの経緯

PHPのセキュリティチームは10月20日、2026年10月21日14時（UTC）にセキュリティリリースを予定していること、対象はCVSS v4.0で9.2と評価された重大な脆弱性2件であることを事前に告知しました。あわせて、脆弱性の詳細が公になった場合や、実際の悪用が確認された場合には、公開を前倒しする可能性があるとしていました（参照：PHP公式「Upcoming Critical PHP Security Release」）。

これを受けてIPAは10月21日、修正版が日本時間の同日23時に公開予定であることを伝え、Webサイトの運営者や開発者に対し、PHPを利用しているプログラムの棚卸しと、公開後すぐに適用できる準備を呼びかけました。IPAは、この時点で悪用した攻撃は確認していないとしたうえで、悪用されるおそれがあるため予防的に情報を発信していると説明しています（参照：IPA「【事前準備のお願い】PHPのセキュリティリリース公開予定について」）。

同日、国家サイバー統括室（NCO）もPHPを利用する企業などに注意喚起を行い、高市早苗首相も自身のXで、修正プログラムを速やかに適用できるよう準備を求めました。修正プログラムの適用が難しい場合は、Webサイトの一時停止などがリスクを下げる有効策のひとつだとしています（参照：日本経済新聞「PHPの脆弱性発覚、高市首相『ウェブサイトの一時停止も有効』」）。

そして10月21日、PHP 8.5.12、8.4.27、8.3.36、8.2.35が公開され、PHP公式はすべての利用者にただちに更新するよう強く求めました（参照：PHP公式「Security advisory: Critical remote code execution vulnerabilities, update now」）。

対象となる環境はどこまで？

PHP公式のセキュリティアドバイザリによると、対象はPHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedを含む、Webリクエストを処理するすべてのPHP環境です。なかでもmod_phpはリスクが最も高いとされ、認証なしのリクエストによって、アプリケーションのコードが動く前に攻撃が成立する実証例が示されています。

PHP-FPMやmod_phpといった名前は、WebサーバーでPHPを動かすための方式の種類です。一般的な動かし方がほぼすべて含まれているため、専門用語がわからなくても「PHPで動いているサイトであれば、まず対象として確認する」と理解しておけば問題ありません。

また、IPAは、PHPがWebアプリケーションだけでなく、ソフトウェア製品やネットワーク機器の内部で使われている場合があり、その利用状況を利用者側では把握できない場合があると注意を促しています。

結局、何をすればいい？立場別にひとことで

詳しい手順は後半で解説しますが、まずは立場ごとの大まかな役割を押さえておきましょう。Webサービスを利用するだけの方は、自分でPHPを直す必要はなく、運営会社のお知らせを待つことが基本と考えられます。レンタルサーバーでサイトを運営している方は、サーバー会社のお知らせと、管理画面のPHPのバージョンを確認しましょう。自社でサーバーを管理している方は、修正版への更新が最優先です。広告代理店や広告担当の方は、広告の遷移先のLPが止まっていないか、誰が更新するのかを確認することから始めるとよいでしょう。

2件の脆弱性の内容と修正版のバージョン

今回修正された脆弱性は2件で、どちらも認証なしでのリモートコード実行（RCE）につながるおそれがあります。リモートコード実行とは、外部の第三者がサーバー上で任意のプログラムを動かせてしまう状態を指します。

つまり、悪用されると、サイトの改ざん、保存されている個人情報の持ち出し、ほかへの攻撃の踏み台としての利用など、サーバーを乗っ取られたのに近い被害につながるおそれがあるということです。また、深刻度を表す共通の指標であるCVSS（v4.0）で、2件とも10点満点中9.2と評価されており、非常に深刻な部類に入ります。

CVE-2026-109618：メモリ不足の処理に起因する脆弱性

メモリ不足（OOM）の処理によって、内部のリクエストデータが一部しか初期化されていない状態でPHPの処理が中断される場合があります。その後のリクエストの後片付けの処理で、不正なデータが正しいデータとして扱われるおそれがあるというものです（参照：PHP公式GitHub「GHSA-w8hw-w9fx-j79w」）。

わかりやすく言い換えると、サーバーのメモリが足りなくなって処理が途中で止まったときに、作りかけのデータが残ってしまい、その片付けの処理を悪用されるおそれがある、という問題です。

CVE-2026-109619：解放後も残る内部状態に起因する脆弱性

あるリクエストが持っていた内部状態が、そのメモリが解放されたあとも残ってしまう場合があります。同じワーカーが処理する次のリクエストで、通常の初期化によってリセットされる前に、残った古い状態が使われてしまうおそれがあるというものです（参照：PHP公式GitHub「GHSA-6wmf-4rv5-p3rp」）。

わかりやすく言い換えると、あるアクセスを処理したときの情報が、片付けたはずなのに残ってしまい、次のアクセスを処理するときに誤って使われるおそれがある、という問題です。ここでいう「ワーカー」とは、サーバーの中でアクセスを1件ずつ処理する担当のプログラムのことです。

修正版のバージョンと入手先

修正版は、PHP 8.5系が8.5.12、8.4系が8.4.27、8.3系が8.3.36、8.2系が8.2.35です。ソースコードとWindows版は、PHP公式のダウンロードページで公開されています（参照：PHP公式「Downloads」）。各バージョンの変更内容は、PHP公式のChangeLogで確認できます（参照：PHP公式「PHP 8 ChangeLog」）。

同アドバイザリによると、Linuxディストリビューションや長期サポート（LTS）の提供元には事前にパッチが共有されているため、OSの配布パッケージを使っている場合は提供元の更新パッケージを確認するよう案内されています。また、PHP公式の8.2.35リリース告知では、PHP 8.2は2026年12月31日でサポートが終了し、それ以降はセキュリティ修正が提供されないとしています。

サイト運営側は何をすべき？優先度順の対応手順

サイト運営側の対応で最も優先すべきなのは、稼働中のPHPを修正版に更新することです。PHP公式の各リリース告知では、完全な緩和策は存在せず、更新が唯一の安全な選択肢だと明記されています。公式・公的機関の発表をもとにすると、対応の流れは次のとおりです。

1. PHPを使っているサイト・システムを洗い出す（コーポレートサイト、LP、キャンペーンサイト、問い合わせフォーム、社内システムなど）。IPAが求めている棚卸しにあたります。
2. それぞれのPHPのバージョンと、PHPを提供・管理している主体（自社サーバー、OSの配布パッケージ、レンタルサーバー、制作会社や保守会社）を確認する。
3. 修正版（8.5.12、8.4.27、8.3.36、8.2.35）、または提供元が修正済みとして案内しているパッケージに更新する。
4. すぐに更新できない場合は、国家サイバー統括室の注意喚起にあるとおり、サイトの一時停止などでリスクを下げる。
5. 更新後も、不審な挙動がないかを確認する。

レンタルサーバーを利用している場合、PHP本体の更新はサーバー会社が対応することが一般的と考えられます。まずはご利用中のサーバー会社のお知らせで対応状況を確認し、管理画面でサイトに設定されているPHPのバージョンもあわせて確認しておくと安心です。

すぐに更新できない場合の暫定策はある？

PHP公式のアドバイザリでは、すぐに更新できない場合に特定の攻撃経路を減らす設定が、脆弱性ごとに示されています。CVE-2026-109618向けには、memory_limitを-1にする、post_max_sizeを小さくする（ファイルアップロード不要なら8M、必要なら32M）などの方法です。CVE-2026-109619向けには、session.upload_progress.enabledを0にしてすべてのワーカーを再起動する方法に加え、PHP 8.5ではfatal_error_backtracesを0にしてすべてのワーカーを再起動する方法が挙げられています。

設定する場所にも条件があります。公式は、memory_limitはFPMのプール設定やApacheの設定のphp_admin_valueなど、アプリケーション側で上書きできない方法で設定することを推奨しています。session.upload_progress.enabledは、php.iniやFPMのプール設定など、リクエストの解析前に反映される場所で設定し、ini_set()やFPMの.user.iniには頼らないよう求めています。ただし公式は、これらは環境を安全にするものではないと明記しています。設定変更はあくまで更新までのつなぎとして扱い、詳細な条件はアドバイザリ本文を確認したうえで、サーバー管理者が判断してください。

これらは、サーバーの設定ファイルを書き換える専門的な作業です。設定の意味がわからない場合は、ご自身で変更せず、サーバー会社や制作会社、保守の担当者に相談してください。誤った設定は、サイトが動かなくなる原因にもなります。

PHP 8.1以前の古いバージョンを使っている場合は？

PHP 8.1以前は、PHPプロジェクトからの更新が提供されません。PHP公式は、一部のディストリビューションやLTSの提供元が修正をバックポートしている場合があるため提供元に確認するか、サポート中のバージョンへ移行するよう案内しています。なお、今回は深刻度の高さから、ソースコードから自分でビルドする利用者などに向けて、PHP 7.4、8.0、8.1向けの最小限のソースコード修正も公開されています。

また、米国のサイバーセキュリティ・社会基盤安全保障庁（CISA）は、すぐに更新できない組織や、サポートが終了したPHP 8.1以前を使い続ける組織に対し、修正や更新が済むまでPHPで動くシステムをオフラインにするよう求めています。古いバージョンのまま公開を続けることは避け、移行が済むまではサイトの一時停止も含めて検討しましょう。

自社サイトのPHPのバージョンがわからない場合は、レンタルサーバーであれば管理画面のPHP設定の項目で確認できることが多いです。制作会社や保守会社に管理を任せている場合は、「今のPHPのバージョン」と「今回の修正版に更新済みか」の2点を問い合わせるとスムーズです。

更新後に確認しておきたいこと

CISAは、「php2shell」と呼ばれる今回の脆弱性について、ただちに修正を適用するよう強く求めています。あわせて、PHPのワーカープロセスがシェルを起動したり、ツールをダウンロードしたりするなどの不審な挙動を監視するよう呼びかけています（参照：CISA「Critical Vulnerabilities in PHP Require Immediate Patching」）。更新して終わりにせず、公開ディレクトリに見覚えのないファイルが増えていないか、管理画面に不明なアカウントが追加されていないかも、あわせて点検しておくとよいと考えられます。

広告代理店はどう対応すべき？LP・計測・クライアント対応の確認ポイント

広告代理店はサーバーを直接管理していなくても、広告の遷移先となるLP、計測タグ、問い合わせフォームなどを通じて、クライアントのWebサイトに深く関わっています。今回のような脆弱性対応では、どのLP・サイトが、誰の管理で、どの環境で動いているかを把握しておくことが対応の起点になると考えられます。以下は、当社の広告運用の観点から整理した確認ポイントです。

（1）配信先LP・キャンペーンサイトの棚卸しと管理主体の確認

まず、配信中の広告の遷移先URLを一覧にし、それぞれのLPやサイトが、クライアント自身、制作会社、代理店、LPツールのどこで管理されているかを確認します。代理店側で制作・管理しているLPやキャンペーンサイトがある場合は、自社の責任範囲として更新状況を確認する必要があります。一方、クライアントや制作会社が管理するサーバーについては、代理店が独断で設定を変えず、管理者に対応を依頼するのが基本と考えられます。

（2）LPが停止・メンテナンス中の広告配信はどうする？

サイトの一時停止やメンテナンスに入ったLPへ広告を配信し続けると、ユーザーをエラーページやメンテナンス画面に誘導することになり、広告費がむだになるおそれがあります。リンク先が正常に表示されない状態では、媒体の審査で広告が不承認になる可能性も考えられます。停止中のLPに向いている広告は一時停止するか、正常に表示される別の遷移先に切り替えるのが現実的な対応です。配信を再開するときは、ページの表示に加えて、フォームの送信や計測タグの発火も確認しておくと安心です。

（3）計測データ・レポートへの影響を記録する

LPやサイトを止めた期間は、セッション数やコンバージョン数が通常と異なる動きになると考えられます。あとから数値の変化を正しく説明できるよう、停止・再開の日時と対象ページをレポートや運用メモに記録しておくことをおすすめします。自動入札を使っているキャンペーンでは、停止期間の実績が入札に影響する可能性もあるため、再開後しばらくは数値の変動を注視するとよいでしょう。

（4）クライアントへの連絡と便乗詐欺への注意

クライアントへは、PHP公式やIPAなどの公式情報をもとに事実を伝え、更新の担当者と完了予定、広告配信への影響を確認しておくとスムーズです。LPのフォームで取得した個人情報がサーバーに保存されている場合は、その点もクライアントと共有しておきたいポイントです。また、大きなニュースのあとは、「脆弱性対応のため」などと称する偽のメールやSMSが出回ることも考えられます。確認は公式サイトや契約先の正規の窓口から行うよう、社内とクライアントの双方で意識をそろえておくと安心です。

対応を進めるうえでの注意点

（1）設定変更だけで「対応済み」としない

前述のとおり、PHP公式が示す設定変更は、特定の攻撃経路を減らすための暫定策にとどまります。社内やクライアントへの報告で「設定変更をしたので対応済み」と伝えてしまうと、更新が後回しになるおそれがあります。報告では「暫定策を実施」と「修正版へ更新済み」を分けて伝えるのがよいと考えられます。

（2）修正版の公開後こそ警戒が必要

IPAは、サポートが終了した古いPHPを使い続けているWebサイトやWebサービスも見受けられるとしたうえで、攻撃者がこれらの脆弱性を悪用し、極めて短時間で攻撃を実行する可能性があると指摘しています。修正版の公開で問題の箇所が広く知られるようになるため、更新が済んでいないサイトほど狙われやすくなると考えられます。長く更新していないキャンペーンサイトや、使い終わったLPが公開されたまま残っていないかも確認しておきましょう。

実際に、修正版の公開前後から、攻撃に関する報告も出始めています。セキュリティ企業のSophosは、X上で攻撃を再現する実証コード（PoC）を作成したと主張する投稿があることを伝えています（参照：Sophos「Proof-of-concept exploit released for PHP vulnerabilities」）。また、セキュリティ企業のSansecは、修正版の公開前の10月21日にCloudflareが初期の攻撃を報告したとまとめています（参照：Sansec「PHP2Shell: Critical PHP RCE」）。一方で、CISAやSophosは発表時点で実際の悪用は確認していないとしており、情報はまだ出そろっていません。攻撃が始まる前提で、更新を急ぐことが大切です。

よくある質問

WordPressで作ったサイトも対象になりますか？

WordPressはPHPで動いているため、サーバーのPHPが修正版になっているかの確認が必要です。PHP公式は、Webリクエストを処理するすべてのPHP環境を対象としています。今回の修正対象はPHP本体のため、WordPressの更新とは別に、サーバー側のPHPのバージョンを確認してください。

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

PHP本体の更新はサーバー会社が対応することが一般的と考えられますが、サーバー会社のお知らせで対応状況を確認することをおすすめします。あわせて、管理画面でサイトに設定されているPHPのバージョンを確認し、サポートが終了した古いバージョンであれば、新しいバージョンへの切り替えを検討してください。

設定を変更すれば更新しなくても大丈夫ですか？

いいえ。PHP公式は、暫定策の設定は特定の攻撃経路を減らすだけで、環境を安全にするものではないとしています。完全な対策は修正版への更新のみです。すぐに更新できない場合は、サイトの一時停止なども含めて検討してください。

広告代理店はクライアントのサーバーを更新すべきですか？

サーバーの更新は、そのサーバーを管理するクライアントや制作会社、サーバー会社が行うのが基本と考えられます。代理店は、配信先LPの管理主体と対応状況を確認し、停止中のLPへの配信を調整する役割を担うのが現実的です。代理店が制作・管理しているLPやサイトについては、自社で更新状況を確認してください。

まとめ

2026年10月21日、PHPの開発チームは、認証なしでのリモートコード実行につながるおそれのある脆弱性2件を修正したPHP 8.5.12、8.4.27、8.3.36、8.2.35を公開しました。対象はWebリクエストを処理するすべてのPHP環境で、完全な対策は修正版への更新のみとされています。

サイト運営側は、PHPを使っているサイトの棚卸し、修正版への更新、すぐに更新できない場合の一時停止の検討、更新後の点検を進めることが求められます。広告代理店は、配信先LPの管理主体と対応状況を把握し、停止中のLPへの配信を止めることで、広告費のむだやクライアントへの影響を抑えられると考えられます。

今後も、PHP公式やIPAなどから追加の情報が出る可能性があります。自社サイトやクライアントのLPについて、公式の発表を確認しながら、一つずつ対応状況を確かめていきましょう。

• Tweet