ある日、カードの明細を開く。買った覚えのない20万円の商品が5件。合計100万円の請求が載っていたら、どうしますか。
これは、危険を具体的に考えるための仮定です。いつもの通販サイトの決済画面が改ざんされ、入力したカード番号、有効期限、セキュリティコードを盗まれる。そして、他人の買い物に使われる。サイトにカード情報を保存していなくても、入力する瞬間を狙われる手口があります。日本サイバー犯罪対策センターも注意を呼びかけています。
サイトを持つ方には、別の怖さがあります。自社のサーバーを勝手に使われ、別の会社への攻撃の発信元にされる。自分も侵入された被害者なのに、管理上の不備を問われ、被害を受けた相手から損害賠償を求められる。争いが訴訟になれば、弁護士に相談し、裁判への対応も必要になる。そこまで発展する場合を考えてほしいのです。
あえて、金額まで置いた極端な例から書きました。「PHPは知らない」「自分には関係ない」と読み飛ばした先に、自分のお金や法的な責任に関わる問題があると伝えたいからです。100万円という金額や訴訟の場面は仮定であり、今回の欠陥による被害事例を報告したものではありません。
カードには不正利用の補償制度があります。例えばJCBは、所定の届け出と調査を経て不正利用と認めた場合、規約に基づき請求を取り消すと案内しています。100万円を必ず自分で払うという意味ではありません。身に覚えのない利用に気づいたら、カード発行会社へすぐに連絡してください。
損害賠償の責任も、被害が出ただけで自動的に決まるものではありません。対策の不備、被害との因果関係、契約などが問題になります。責任や紛争の扱いは、政府の法令解説でも確認できます。攻撃の踏み台にされたことと、本人が犯罪をしたことも別です。
今回のPHPの欠陥では、条件がそろうと、ログインしていない攻撃者がWeb処理の権限でプログラムを実行できます。その先で何を盗めるか、何を書き換えられるかは、サイトの構成と権限によって変わります。ここから、どこに危険があり、誰が何を確認するのかを説明します。
PHPは、サイトの「裏側の仕事」を動かしている
ネットショップをお店に例えるなら、画面に見える写真やボタンは売り場、注文を受け付けて記録する処理は裏側の仕事です。PHPは、そうしたサーバー側の処理を書くためのプログラミング言語です。ブログやホームページを管理するWordPressでも使われています。
利用の広がりには根拠があります。Web技術を調べるW3Techsの10月22日の集計では、サーバー側の言語を判別できるサイトのうち、PHPを使う割合は69.3%でした。対象は「言語を判別できるサイト」です。世界中のサイトの69.3%が被害を受けた、という数字ではありません。
だから、自分でプログラムを書かなくても関係があります。制作会社に頼んだホームページがPHPで動いている場合もあれば、日々使う外部サービスの中にPHPがある場合もあります。利用者からは、画面の見た目だけで区別できません。
危険度は9.2。パスワードを盗まずに攻撃できる点が重大
今回の2件は、危険度を評価するCVSSの第4版で、どちらも10点満点の9.2、最も高い区分の「Critical」です。これは深刻さの評価であり、92%の確率で被害に遭うという意味ではありません。
通常なら、管理者のパスワードを知らない相手には操作を許しません。ところが今回の問題は、ログインの前に動く処理などから悪用される可能性があります。開発元の報告では、Apacheのmod_phpという動かし方で、サイト固有のプログラムが動き始める前に攻撃できることが確認されています。
「担当者が不審なメールを開かなければ大丈夫」「管理画面に二段階認証があるから大丈夫」とは言えません。今回の修正対象は、ログインの仕組みよりも下で働くPHP本体だからです。
- 情報を読まれる：Web処理がアクセスできる顧客情報や設定情報などが、外へ持ち出されるおそれがあります。
- 内容を変えられる：書き込み可能なページやデータを書き換えられ、利用者をだます表示などに悪用されるおそれがあります。
- 使えなくなる：処理やデータを壊され、予約・注文などが止まるおそれがあります。
ただし、「どの環境でも、すぐにすべてを奪われる」とまでは言えません。攻撃の成立条件は環境によって異なります。公式報告が示すのはWeb処理を動かすアカウントの権限での実行で、必ずサーバー全体の最高権限を得るという説明ではありません。それでも、その権限が顧客データに届くなら、事業と利用者にとって重大です。
2つの欠陥は、どこにあるのか
一つは、メモリが不足したときに、不完全な内部データが正しく扱われなくなる問題です。識別番号は CVE-2026-109618。もう一つは、前の処理で使い終えたメモリへの参照が残り、後の処理がそれを使ってしまう問題で、CVE-2026-109619 です。
細かな構造を暗記する必要はありません。2件目の開発元の報告も、条件がそろうと遠隔からの不正実行につながるとしています。問い合わせでは、この2つの番号を伝えると、別の古いPHPの問題と取り違えずに済みます。
作る人・使う事業者・一般利用者。それぞれに関係がある
自分のサイトを運営している方は、PHPを使っているか、誰が更新するかを確認する立場です。保守を外注していても、契約にサーバー更新が含まれるとは限りません。まず連絡先を確かめてください。
外部サービスを利用する方は、提供元の告知を確認する立場です。自分でPHPを更新できなくても、サービス停止が仕事に与える影響や、顧客への案内は判断する必要があります。
買い物や会員サービスを利用する方にも、預けた情報や利用できる時間を通じて影響する可能性があります。利用先の公式アプリやブックマークから告知を確認してください。PHPのニュースを見たことだけで、自分のスマートフォンが侵入されたことにはなりません。利用者が端末に「PHP修正ソフト」を入れる話でもありません。
広く関係するニュースであることと、全員に同じ操作が必要なことは別です。運営者は更新を進め、利用者は提供元の案内を確認する。この違いを知ると、必要な行動が見えてきます。
話題の動画から、現在の公式情報へ
堀江貴文さんも10月21日の解説動画で、PHPが使われる場面から入り、危険性や更新の必要性を説明しています。本記事でも、まず生活や仕事とのつながりを伝える順番を参考にしました。
動画は修正版の公開前の説明です。今読む方には、公開後に分かった対象や対応方法まで届ける必要があります。以降は、PHP開発元が公表した内容に基づいて確認先を示します。
今、直すべきものはPHP本体
画面を管理するアプリと、その下で処理を動かすPHP。更新する場所を取り違えないことが大切です。
WooCommerceの公式案内も、今回の対象はPHPであり、WordPressやWooCommerce自体の更新とは区別しています。管理画面でWordPressを最新版にしただけでは、PHPの修正を済ませたことにはなりません。
PHP公式が公開した修正版は、8.2.35、8.3.36、8.4.27、8.5.12です。提供元が古い版に修正を取り込む場合もあるため、版番号だけで結論を出さず、今回の2件が修正されたかを管理者に確認します。設定による一時的な対策だけで、安全になったとは言えません。
サイトを任せている方へ、そのまま送れる確認文
当社サイトでPHPを使用しているか、10月21日公表の2件の脆弱性に対応済みかを確認したいです。対象はCVE-2026-109618とCVE-2026-109619です。未対応なら、更新を担当する方と対応予定、更新までに必要な措置を教えてください。
HaruIroAIでも、記事の制作にあたり自社サイトのソースを確認しました。確認した範囲ではPHPファイルはありませんでした。ただし、これで利用中の外部サービスの内部まで確認できたわけではありません。どこを確認し、どこは提供元の返事が必要かを分けることを、当社は勧めます。
最新状況と、この問題から考えるべき運用の課題は、続編のPHPの緊急修正から考える、更新を届ける仕組みで掘り下げます。委託先との普段の確認には、公開アプリとサーバーの安全性を確認する質問もご覧ください。
サイトの構成や保守窓口から確認したい方は、はるいろWeb担当でご相談いただけます。
今回のニュースを、普段の安全な使い方を見直すきっかけにしてください。AIセキュリティ・チャレンジでは、情報の扱いや権限、業者に確かめる守りの基本を、選択式で学べます。
この記事の確かめ方
2026年10月22日にPHP公式と2件の開発元資料を確認しました。PHP Foundation、W3Techs、WooCommerce、さくらのクラウドの発表も参照しています。堀江貴文さんの動画は日本語自動字幕で本編を確認。高市首相の投稿はX公式の埋め込み情報で著者・冒頭・日付を、詳細はITmediaの報道で確認しました。本文の技術的な説明は開発元資料を優先しています。
実際の更新手順と提供元の対応状況は変わります。利用先の公式情報を確認し、管理者と対応してください。
