今回見つかったのは、Webサイトの裏側で動くPHPの弱点です。悪用されると、ログインしていない相手から、サイトを書き換えるなどの不正な処理を動かされるおそれがあります。 WordPressでブログや会社のサイトを運営している人にも、関係する場合があります。
対象はCVE-2026-109618とCVE-2026-109619の2件。修正版は2026年10月21日に公開されました。サイトの運営者は、利用しているサーバー会社や管理担当者の公式案内で、両方の修正が自分の環境に適用されたかを速やかに確認してください。
この記事は2026年10月22日に確認した情報をもとにしています。利用するだけの人と、サイトを運営する人では、できることが違います。まず問題の場所をつかみ、自分に必要な確認へ進みましょう。
PHPの脆弱性とは?今回の問題を先に整理
Webサイトの文章や画像を届けるコンピューターを、サーバーといいます。PHPは、そのサーバーの中で「記事を取り出す」「入力内容を確かめる」といった仕事をするために使われます。
厳密には、PHPはプログラムを書く言語の名前です。書かれたプログラムを動かすソフトウェアもPHPと呼ばれ、今回、修正が必要なのはこちらです。
ブラウザでページを開く。
PHPが記事を取り出し、返す内容を作る。
運営者はサーバー会社や管理担当者へ、修正が適用されたかを確認します。
利用者のパソコンへPHPを入れ直す、という対策ではありません。
「脆弱性」は「ぜいじゃくせい」と読み、安全を損なう弱点を指します。今回の2件は、条件がそろうと、攻撃者がログインせずにサーバー上でコードを実行できる可能性があります。報道などでは「PHP2Shell」という名前も使われています。
深刻度を共通の基準で評価するCVSSでは、v4.0で9.2。最も高い「Critical(緊急)」の区分です。優先して対応する必要がありますが、「使っている人の92%が被害に遭う」という意味ではありません。番号と点数の読み方は、CVEとCVSSの違いで別々に説明しています。
また、脆弱性があることと、そのサイトがすでに侵入されたことも別です。弱点を直す必要はありますが、個別の被害は調査しなければ分かりません。
PHPの脆弱性はどんなサイトに関係する?
画面に「PHP」と書かれていなくても、裏側で使われていることがあります。たとえば、WordPressで作ったブログや会社のサイトです。利用者がページを開くと、サーバー側でPHPが働き、表示する内容を作ります。
PHP公式は、Webからの依頼を処理するPHPを、広く更新対象としています。この依頼は「リクエスト」と呼ばれ、ページの表示やフォームの送信などで発生します。
告知にPHP-FPMやmod_phpと書かれていても、別製品の話だと思わなくて大丈夫です。どちらもサーバーとPHPをつなぐ方式の名前です。方式が違うだけで今回の問題を避けられるとは限らないため、提供元の対応状況を確認します。
自分との関係は、次のように分けると整理できます。
| 自分の立場 | 最初に確かめる相手・場所 |
|---|---|
| ブログや会社のサイトを運営している | サーバー会社の告知、制作会社、管理担当者 |
| サーバーを自分で管理している | PHPやOSの提供元のセキュリティ情報 |
| サービスを利用するだけ | そのサービスの公式のお知らせ |
サイトを見る人のパソコンに、PHPの修正版を入れる話ではありません。また、見た目が静かな会社案内サイトでも、管理機能でPHPを使うことがあります。URLの末尾や画面の見た目だけでは、使用の有無は判断できません。
PHPの位置から知りたい場合は、PHPとは何をするものかを読むと、ブラウザとサーバーの関係からつながります。
認証なしのリモートコード実行で起きること
リモートコード実行は、離れた場所から、対象のコンピューターに意図しない処理を実行させることです。「認証なし」は、その攻撃に有効なログイン情報が必要ないことを表します。
ラボの受付でたとえるなら、会員証を確認する場所より手前にも、荷物を受け取り、分け、片づける作業があります。その作業に問題があれば、会員証を厳しく確認するだけでは防げません。
実際のサーバーでも、アプリがログインを確認する前後に、PHPが受信データなどを処理します。PHP公式は、mod_phpという構成で、アプリのコードが動く前に攻撃できる例が示されたと説明しています。このたとえは順序をつかむためのもので、すべての構成が同じ経路で攻撃されるという意味ではありません。
ユイ
ログインのパスワードを変えれば、直ったことになるんでしょうか。
マコト
パスワードを守ることは大切だね。でも今回は、その確認とは別の処理に弱点がある。PHP自体の修正を確かめよう。
不正な処理が動くと、データを読まれる、サイトを書き換えられる、サービスを止められるといった被害につながり得ます。どこまで届くかは、処理に与えられた**権限、つまり「読んでよい・変更してよい範囲」**などで変わります。
たとえば、記事を表示する処理が顧客情報にも触れられるなら、その情報まで影響する可能性があります。どんな環境でも全データを奪われると決まったわけではありません。詳しくはリモートコード実行の意味と被害の条件で扱います。
PHPの脆弱性2件は原因がどう違う?
2件に共通するのは、PHPが処理の途中で使う情報を、安全に扱えなくなる問題です。ただし、原因は同じではありません。
| 識別番号 | 初心者向けに言うと |
|---|---|
| CVE-2026-109618 | メモリ不足で作業が中断し、準備途中の情報を、正しく準備済みであるかのように後片づけで扱ってしまう |
| CVE-2026-109619 | 前の依頼で使ったメモリを返したあとも古い状態が残り、次の依頼の処理で使われてしまう |
メモリは、コンピューターが処理中の情報を置く作業用の領域です。使い終えた領域を返すことを「解放」といいます。空き容量を増やすことだけが今回の対策になる、という話ではありません。
前者の問題はPHP開発元のセキュリティ勧告でも、メモリ不足時の処理と不完全な初期化の関係として説明されています。内部の用語をもう一段知りたい人向けに、メモリの解放と解放後使用を用意しています。
PHPの修正版とバージョン確認の注意点
PHP開発元が2026年10月21日に公開した、各系列で今回の2件を修正した版は次のとおりです。根拠はPHP公式の緊急セキュリティ告知です。
| 使用中の系列 | 今回の修正が入った版 |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
これは「全員が8.5へ切り替えなければならない」という表ではありません。同じ系列の修正版で対応できる場合があります。一方、異なる系列への変更では、サイトの機能が正しく動くかの確認も必要です。
注意したいのがバックポートです。OSやサーバーの提供元が、元の版番号を大きく変えずに必要な修正を取り込むことがあります。そのため、画面に出る数字だけで「未修正」と断定できない場合があります。提供元が、両CVEに対応済みとしているかまで確認します。
PHP 8.1以前は、PHP開発元の通常のサポート対象外です。今回は7.4・8.0・8.1向けにも最小限のソース修正が用意されましたが、通常のサポート再開を意味しません。古い環境は提供元の対応状況を確認し、サポートされる系列への移行も相談する必要があります。
WordPress利用者がPHPの対策を確認する順番
WordPress本体やプラグインの更新と、サーバーのPHP更新は別の作業です。 WordPress側を最新にしただけでは、今回のPHP本体の修正適用を確認したことにはなりません。
レンタルサーバーなら、まず会社の公式告知で次の順に確かめます。
- 対象を探す:自分の契約サーバーと、利用中のPHPが含まれているか。
- 完了した作業を読む:「対策を開始」なのか、「修正の適用が完了」なのか。
- 自分の操作を確かめる:管理画面での変更などが必要か、会社側で完了するか。
告知の「パッチ」は、不具合を修正するための変更のことです。「一部の攻撃を防ぐ設定をした」という案内は、PHP本体の修正完了とは区別して読みます。
告知だけで判断できない場合は、次の内容を問い合わせると、調べてほしいことを伝えられます。
利用中のサーバーについて、CVE-2026-109618とCVE-2026-109619の両方の修正は適用済みでしょうか。こちらで必要な操作と、修正前の侵害有無について確認できている範囲を教えてください。
サイトのURLや契約情報は、提供元の正式な問い合わせ窓口で必要な範囲だけ伝えます。パスワードを公開コメントへ書く必要はありません。
自分でサーバーを管理している場合は、提供元の更新手順に従い、稼働中のPHPにも修正が反映されたかを確認します。初心者が、ネットで見かけたメモリ制限の解除などの設定だけをまねるのは避けたいところです。今回の問題は設定変更だけでは完全に解消できず、別の負荷や機能への影響も考える必要があります。
PHPの更新後も侵害の確認が必要な理由
修正は、弱点をふさぐためのものです。すでに侵入されていた場合に、不正なファイルや改変まで自動で取り除くものではありません。
これから同じ弱点を悪用されないよう、問題の処理を直す。
修正前に侵入されていなかったか、不正な変更が残っていないかを調べる。
更新だけで、過去の侵入や情報流出を取り消せるわけではありません。
Amazonの調査報告では、公表前の10月17日に観測用システムで攻撃の試みを確認したとしています。公表前の試みが実際の環境で成功したかは不明とする一方、公表後には広く悪用されていると報告しています。
この報告だけで、自分のサイトが侵入されたとは判断できません。ただし、「まだ攻撃は始まっていない」「公表後だけ調べればよい」と考えて対応を遅らせないことが大切です。
運営者は、更新完了に加えて、不審な動作や改変の確認が必要かを管理担当者へ相談してください。疑わしいファイルを見つけても、手当たり次第に削除すると調査の手がかりを失うことがあります。先に担当者と連絡を取り、記録の保全や必要な隔離を判断します。
利用者の立場なら、サービスの公式告知で被害の有無、対象、必要な対応を確かめます。予防的にサービスを止めている場合もあるため、停止だけで情報漏えいが起きたとはいえません。
「自分も何かしないといけないのか」。この問いには、難しい用語を全部覚えなくても答えを探せます。サイトを運営しているなら、まず提供元の告知で自分の環境に両方の修正が届いているかを確かめてください。利用するだけなら、サービス側が案内する対象と必要な操作を見るところからで大丈夫です。




