PHP脆弱性とWeb広告への影響｜確認と対応の手順
｜広告運用ノウハウ公開中！
より詳しく知りたい方は資料をダウンロード！
2026年10月21日の夜、PHPの重大な脆弱性2件を修正するセキュリティリリースが公開されました。深刻度はCVSS v4.0で9.2、認証を通らずに外部から任意のコードを実行される可能性があるものです。
パッチの公開前後で、国内でもECサイト、クリエイター向けサービス、ゲーム、レンタルサーバーが相次いで緊急メンテナンスに入りました。広告を配信している側から見ると、これは遷移先が予告なく落ちる事態です。
落ちたページに広告を送り続ければ費用が無駄になり、審査にも影響します。かといって配信を止めれば、積み上げた機械学習が振り出しに戻ります。どちらを選ぶかは、止まってから考えると間に合いません。
この記事では、何が起きたのかを公式の発表から整理し、自分のサイトがPHPで動いているかの確認方法、広告側で起きること、配信を止めるかどうかの判断と復旧後の手順をまとめます。
2026年10月21日の夜、高市早苗首相が自身のXで、公開しているウェブサイトでPHPを使っているかを確認し、修正パッチを速やかに適用できるよう準備することを呼びかけました。パッチの適用が難しい場合は、ウェブサイトを一時的に停止させることもリスクを下げる有効策の一つだとしています。
皆様に、今夜に対応して頂きたい大至急のお願いです。
— 高市早苗 (@takaichi_sanae) October 21, 2026
多くのウェブサイトで使用されているPHPに関し、PHPのセキュリティチームが、重大な２件の脆弱性に関する注意喚起を行っています。
公開しているウェブサイトでPHPを使用しているか確認し、今夜、10月21日午後11時（日本時間）に公開される修正パッチについて、可及的速やかに適用できるよう準備をお願いします。
修正パッチを速やかに適用することが困難な場合は、例えばウェブサイト等を一時的に停止させることも、リスクを低減させるための有効策の一つと考えられます。
国家サイバー統括室のXアカウントでも関係する情報を発信していますので、そちらも参考にして下さい。
国家サイバー統括室(注意・警戒情報)（@cyber_forecast） / X
＼LPの制作から検証まで、ひとつの画面で／
- ・10日間、有料プランの機能を無料でお試しいただけます
- ・LP制作からA/Bテスト、効果測定までワンストップ
目次
1. 何が起きたのか｜2件の脆弱性と緊急パッチ
PHPの開発チームは2026年10月20日に重大な脆弱性2件の存在を予告し、翌21日の夜に修正版を公開しました。修正版はPHP 8.5.12、8.4.27、8.3.36、8.2.35です。
2件の内容は次のとおりです。
| CVE-2026-109618 | CVE-2026-109619 | |
|---|---|---|
| 名称 | OOM時のlongjmpによるRCE | Stale Global StateによるRCE |
| 何が起きるか | メモリ不足の処理がPHPを中断させ、初期化が終わっていないデータを正常なものとして扱ってしまう | 解放済みのメモリに紐づく内部状態が次のリクエストまで残り、初期化前に使われてしまう |
| 深刻度（CVSS v4.0） | 9.2 | 9.2 |
公式のアドバイザリは、Webリクエストを処理しているPHPの環境すべてが対象だとしたうえで、リスクが最も高いのはApacheのmod_phpだと書いています。認証を通らないリクエストが、アプリケーションのコードが動き出す前に攻撃を成立させる実証があるためです。PHP-FPM、php-cgi、FrankenPHP、LiteSpeedも対象に挙がっています（出典：PHP公式アドバイザリ）。
影響範囲も広く、Wiz Researchは過去10年に公開されたPHPのすべてのバージョン（5.4以降）が、少なくともどちらか一方の影響を受けるとしています。発見は2026年8月19日で、8月21日にはWordPressの標準構成に対して認証なしでコードを実行できることを実証し、8月24日にPHPのセキュリティチームへ報告しています（出典：Wiz Research）。
設定変更による暫定策も出回りましたが、完全な回避にはなりません。GMO Flatt Securityは「session.upload_progress.enabled」を無効にする方法について、完全ではなく、これだけでは他の攻撃シナリオを回避できないと書いています。同社は脆弱性を悪用できると主張するコードが既にインターネット上に出回り始めているとも報告しています（出典：GMO Flatt Security）。更新することが唯一の完全な対処です。
公開の前後から、実際の攻撃が観測されています。セキュリティ企業のwatchTowrは自社のハニーポット網で2件とも悪用の試みを確認したと報告し、Cloudflareは公式リリースの前の段階で顧客を狙う攻撃トラフィックを観測、攻撃者が防御をすり抜けるためにペイロードを変化させていたとしています。Palo Alto NetworksのUnit 42は、公表時点でインターネット上に2,260万以上の脆弱なインスタンスが露出していると推定しています（出典：watchTowr、Cloudflare、Unit 42）。
2. 広告の遷移先が対象かどうかを確認する
広告運用の担当者がまず知りたいのは「自分の遷移先は対象なのか」です。
対象かどうかは、使っているCMSの種類では決まりません。WordPress.orgは今回の件について「今回の脆弱性は WordPress に固有のものではありません。PHP アプリケーションをホストしているすべてのサーバーが影響を受けます」と明記したうえで、WordPress本体の更新は必要なく、更新すべきなのはPHPのほうだと案内しています。ECサイトのパッケージ、LaravelやSymfonyで作られた自社システム、制作会社が作った独自のCMSも同じように対象です（出典：WordPress.org 日本語）。
ここからが広告運用側の仕事です。棚卸しの対象は本体のサイトだけではありません。広告の遷移先として使っているページを全部数えてください。
キャンペーンごとに作った特設ページ、過去に制作会社に依頼して別ドメインに置いたLP、アフィリエイト用に分けたページ。運用期間が長いほど、本体サイトとは別のところに遷移先が散らばっています。本体の対応が終わっても、そこが残っていれば広告は落ちたページに送られ続けます。
IPAも事前の注意喚起で、PHPを利用しているものを棚卸しし、公開後すぐに適用できるよう準備することを呼びかけています（出典：IPA）。
3. 広告側で起きること
遷移先が落ちるという一点から、広告側では問題が3つ起きます。
3-1. 審査に影響する
遷移先が表示できない状態で配信を続けると、媒体側の審査で不承認の対象になります。Google広告には「機能していないリンク先」というポリシー違反があり、サーバーエラーやメンテナンス表示が原因で出ることがあります。詳しい原因と復旧の手順はGoogle広告「機能していないリンク先」エラー｜原因と対処法で扱っています。
一度の不承認で止まるとは限りませんが、短期間に繰り返すとアカウントの評価に影響します。メンテナンスの予定が決まっているなら、落ちる前に配信を止めるほうが安全です。
3-2. 配信を止めると学習が振り出しに戻る
止めている間に取れなかったCVだけが損失ではありません。自動入札は停止と再開で学習期間に入り直すため、再開してからしばらくはCPAが不安定になります。
この仕組みと、止まったときに広告運用側で何を準備しておけるかはランサムウェアの情報漏洩対策｜広告を止めない体制にまとめています。原因がランサムウェアでもPHPの緊急対応でも、サイトが止まるという一点から先の構造は同じです。
3-3. 止めたつもりで止まっていない
見落とされやすいのがこれです。
- 症状：サイトをメンテナンスに入れたのに、広告費が通常どおり消化されている。管理画面を見ると主要なキャンペーンは停止済みで、担当者は止めたつもりでいる
- 原因：止め忘れが起きるのは、構成が分かれているところです。媒体をまたいで配信している場合の片方、別担当が運用しているキャンペーン、過去に作って放置したままの少額のキャンペーン、代理店に任せている分。管理画面を1つ見ただけでは全体が把握できません
- 対策：配信中のキャンペーンを媒体別・担当者別に書き出して、止める順番を先に決めておいてください。緊急時に一覧を作り始めるのでは間に合いません
- 回避策：遷移先を本体サイトと別の基盤に置いておけば、そもそも全部を止める必要がなくなります。影響を受けるページを配信しているキャンペーンだけを特定して止められます
4. 止めるか・続けるかの判断と、復旧後にやること
判断の軸は、遷移先が実際に落ちるかどうかです。本体サイトが止まっても遷移先が生きているなら、配信を止める理由はありません。
| 状況 | 配信の扱い |
|---|---|
| 遷移先がPHPのサイト上にあり、メンテナンスで落ちる | 落ちる前に停止する |
| 遷移先は別の基盤にあり、落ちない | 止めない。フォームの送信先が本体サイト側にある場合だけ確認する |
| 遷移先が落ちるか分からない | メンテナンスの開始時刻までに制作会社かサーバー会社に確認する |
復旧したあとは、設定を触らずに元の状態へ戻すことが基本です。停止していたキャンペーンを再開するという操作そのものが学習の起点になるため、そこにCPAの調整や構成の変更を重ねると、リセットが二重に起きます。数字が戻らないのは停止のせいなのか調整のせいなのか、後から切り分けられなくなります。
PHPのバージョンを上げた直後にサイトが500エラーになるケースもあります。原因の切り分けと復旧の手順はWordPressのバージョンアップで500エラーが出た時の対処法にまとめているので、該当する場合はそちらを参照してください。
5. Squad beyondで、広告の遷移先を本体サイトの外に持つ
配信を止めることになるかどうかは、遷移先がどの基盤に乗っているかで決まります。本体サイトと同じ基盤に置いていれば、情シスやサーバー会社が下した停止の判断が、そのまま広告にも及びます。
Squad beyondで作成・配信するLPはPHPを使っていません。今回のようにPHP側で緊急の更新が必要になっても、配信中のLPはその対象外です。
配信を止めずに済めば、再開後の学習の立ち上げも発生しません。3章で見たとおり、停止の損失は止めている期間だけでは終わらないので、ここが成果の分かれ目になります。
＼LPの制作から検証まで、ひとつの画面で／
- ・10日間、有料プランの機能を無料でお試しいただけます
- ・LP制作からA/Bテスト、効果測定までワンストップ
6. PHPの脆弱性と広告配信についてよくある質問（FAQ）
Q. パッチはすでに公開されていますが、今から対応しても間に合いますか？
更新がまだなら、今すぐ対応してください。GMO Flatt Securityは脆弱性を悪用できると主張するコードが出回り始めていると報告しており、watchTowrとCloudflareはいずれも実際の攻撃を観測したとしています。設定変更による暫定策も出回りましたが、同社は完全ではなく、これだけでは他の攻撃シナリオを回避できないとしています。更新することが唯一の完全な対処です。
Q. WordPressを使っています。WordPress本体の更新も必要ですか？
WordPress.orgは、今回の脆弱性はWordPressに固有のものではないとしたうえで、本体の更新は必要なく、更新すべきなのはPHPのほうだと案内しています。レンタルサーバーを使っている場合は、ホスティング会社がPHPの自動更新やWAFルールの導入を進めていることがあるので、契約先からの案内を先に確認してください。自社でサーバーを管理していてPHP 8.2以前を使っている場合については、サーバーを一時的にオフラインにすることも検討するよう書かれています。
Q. サイトを止めている間、広告は止めるべきですか？
遷移先が落ちるなら止めてください。表示できないページに配信を続けると、Google広告の「機能していないリンク先」のような不承認の対象になります。ただし配信を止めると自動入札の学習が入り直すため、再開後しばらくはCPAが不安定になります。判断の分かれ目は遷移先が落ちるかどうかなので、遷移先を本体サイトと別の基盤に置いていれば、そもそも止めずに済みます。Squad beyondで作成・配信するLPはPHPを使っていないため、本体サイトのメンテナンス中も広告を止めずに運用できます。
Q. 遷移先が落ちたまま配信を続けると、どうなりますか？
2つの損失が同時に出ます。1つは広告費で、表示できないページにクリックが発生した分がそのまま無駄になります。もう1つは媒体側の評価で、Google広告の「機能していないリンク先」のような不承認の対象になり、短期間に繰り返すとアカウントの評価に響きます。遷移先が落ちると分かっているなら、落ちる前に止めるのが安全です。Squad beyondで作成・配信するLPはPHPを使っていないため、本体サイトのメンテナンス中も配信を続けられます。
Q. PHPを更新したらサイトが表示されなくなりました。どうすればよいですか？
更新を急いだ結果として多いのが、500エラーでサイトが真っ白になるケースです。原因の多くは、古いプラグインやテーマが新しいPHPのルールに対応していないことにあります。まずレンタルサーバーの管理画面からPHPのバージョンを元に戻してサイトを復旧させ、そのうえで原因のプラグインを特定してから上げ直す、という順番になります。手順はWordPressのバージョンアップで500エラーが出た時の対処法にまとめています。復旧には数時間かかる前提で、広告をいつ止めるかを先に決めておいてください。
Q. 広告の遷移先が多すぎて、どこから手をつければよいですか？
配信金額の大きいキャンペーンから順に、遷移先のURLと、それがどのサーバーで動いているかを並べてください。全部を一度に洗い出そうとすると終わらないので、止めたときの損失が大きいものから確定させるのが現実的です。そのうえで、配信を止めたまま放置しているキャンペーンの遷移先を拾います。ここは忘れられやすい一方で、落ちていても気づかないため放置されがちな部分です。なお、広告の遷移先をSquad beyondのように本体サイトと別の基盤に置いていれば、この棚卸しの対象から外れます。
7. まとめ
2026年10月21日、PHPの重大な脆弱性2件を修正するセキュリティリリースが公開されました。CVE-2026-109618とCVE-2026-109619で、深刻度はいずれもCVSS v4.0で9.2です。過去10年に公開されたPHPのすべてのバージョンが、少なくともどちらか一方の影響を受けます。設定変更による暫定策は完全な回避にならないため、更新することが唯一の対処です。
広告運用の側で確認すべきなのは、本体サイトだけではありません。キャンペーンごとの特設ページ、別ドメインに置いたLP、制作会社に依頼したまま把握できていないページ。遷移先として使っているものを全部数えるところから始めてください。
遷移先が落ちるなら、落ちる前に配信を止める。落ちないなら止めない。判断の軸はこれだけですが、止まってから数えていては間に合いません。停止の対象を媒体別・担当者別に書き出したリストを、平時のうちに1枚作っておくことをおすすめします。
＼LPの制作から検証まで、ひとつの画面で／
- ・10日間、有料プランの機能を無料でお試しいただけます
- ・LP制作からA/Bテスト、効果測定までワンストップ
Squad beyondサービス紹介資料はこちらからダウンロード
