PHPの重大な脆弱性、海外ではどう受け止められた?サイト停止や利用者の不安を調査

0コメント
世界の話題
このページは広告が含まれています。

(最終更新日:2026年10月22日)

「銀行口座にはログインしない方がいいの?」。2026年10月21日、ウェブサイトの運営に広く使われている「PHP」で重大な脆弱性が公表され、海外の掲示板サイトRedditにはこんな不安の声が寄せられました。

一部の政府機関が予防的にウェブサイトを停止する一方、サイト管理者たちは緊急の更新作業に追われています。今回の問題は何が危険なのか、なぜこれほど大きなニュースになったのか。公式発表と海外の反応をもとに、その背景を調べました。

広告下に海外の反応が続いています
広告下に海外の反応が続いています

PHPの脆弱性で何が起きたのか?

PHPとは、ウェブサイトの裏側で動くプログラミング言語の一つです。

例えば、私たちがブログの記事を開いたり、通販サイトで商品を検索したりするとき、ウェブサイトのサーバー(サイトを動かすコンピューター)では必要な情報を取り出し、画面に表示するための処理が行われています。PHPは、こうした処理を担う技術として広く使われています。

ブログや企業サイトの作成に使われる「WordPress」もPHPで動作します。

ウェブ技術の利用状況を調べるW3Techsによると、2026年10月22日時点で、サーバー側のプログラミング言語を特定できたウェブサイトの69.3%がPHPを使用しています。インターネット全体の69.3%という意味ではありませんが、非常に多くのサイトに関わる技術であることが分かります。

今回見つかったのは、PHPの内部でメモリを扱う際などに生じる2件の欠陥です。

それぞれ「CVE-2026-109618」「CVE-2026-109619」という識別番号が付けられています。脆弱性の重大度を示す「CVSS」という評価基準では、どちらも最高区分の「重大」に当たる9.2(10点満点)と評価されました。

この数値は、攻撃される確率ではなく、脆弱性の深刻さを示すものです。

問題となっているのは、条件がそろうと、攻撃者がログインせずに外部からサーバー上で不正なプログラムを実行できることです。

このような攻撃は「遠隔コード実行」と呼ばれます。悪用されれば、ウェブサイトの改ざんや、サーバーに保存された情報の窃取などにつながるおそれがあります。

PHPの開発チームは10月21日、次の修正版を公開し、速やかな更新を呼びかけました。

  • PHP 8.5.12
  • PHP 8.4.27
  • PHP 8.3.36
  • PHP 8.2.35

古いPHPについても、利用しているサーバーの基本ソフトや保守サービスによっては、修正を取り込んだ更新が提供されています。

この脆弱性が見つかったからといって、すべてのサイトが攻撃を受けたわけではありません。

ただし、ウェブサイトの安全対策などを提供する米Cloudflareは10月21日、今回の欠陥を狙った攻撃通信を観測したと発表しています。攻撃の試みが確認されたことと、実際にサイトが乗っ取られたことは区別する必要があります。

広告下に記事が続いています
広告下に記事が続いています

「普通にネットを使って大丈夫?」一般利用者にも広がる不安

Redditのサイバーセキュリティを扱うコミュニティ「r/cybersecurity」では、技術に詳しくないという投稿主が、今回のニュースを受けて相談していました。

自分のスマートフォンやパソコンにも危険があるのか、普段どおりインターネットを利用してよいのか、という疑問です。

同じように戸惑っている人もいました。

私も技術に詳しいわけじゃないから、よく分からないんだ。これから何が起こるのか、本当に心配してる。 🙁

— u/Admirable_Noise_6753

話題のニュースや出来事の背景を質問するコミュニティ「r/OutOfTheLoop」でも、ニュースの意味を知ろうとする人たちがやり取りしていました。

じゃあ、普通にインターネットを使っている人は、何をすればいいの? 何ができる? 銀行口座にはログインしない方がいい?

— u/GoofManRoofMan

これに対して、次のような返信が寄せられています。

基本的には心配しなくていいよ。この脆弱性で攻撃できるのはサーバーであって、そこに接続している人そのものじゃないんだ。

強いて言えば、サーバーからあなたの情報が直接盗まれる可能性はあるけど、今あなたが何をしても、その可能性には影響しない。

— u/miguescout

今回の脆弱性は、ウェブサイトを閲覧しただけで利用者のスマートフォンやパソコンが直接乗っ取られる、というものではありません。

危険にさらされるのは、主にPHPを動かしているウェブサーバーです。

ただし、サーバーが実際に侵害され、保存された個人情報が盗まれたり、ウェブサイトが改ざんされたりすれば、利用者にも被害が及ぶ可能性があります。

今回のニュースだけを理由に、銀行サイトを含むすべてのウェブサイトの利用を一律に中止する必要はありませんが、利用しているサービスからセキュリティ上の注意喚起が出ている場合は、その案内に従うことが大切です。

一般の利用者が自分の端末でPHPの更新作業をする必要はありません。更新を担うのは、サイトの運営者やサーバー管理者、利用しているサービスの提供会社です。

なお、WordPress自体を更新するだけでは今回の脆弱性は解消されず、サイトが使用しているPHPを修正する必要があります。レンタルサーバーなどを利用している場合は、契約先の事業者が更新を行うこともあります。

利用者としては、普段からパスワードを使い回さず、不審なメールやリンクに注意することが引き続き重要になります。今回の脆弱性を口実にした偽の「セキュリティ対策」案内にも気を付けたいところです。

海外では政府機関のサイトも予防的に停止

今回のニュースが大きく取り上げられた理由の一つに、実際にウェブサイトの停止という対応が取られたことがあります。

オランダの国家サイバーセキュリティセンター(NCSC)は、重大な脆弱性への予防措置として、自らのウェブサイトを一時的に停止したと発表しました。

同機関によると、ほかにも政府機関を含む複数の組織が予防的にサイトを停止しています。その後、修正版が公開されたため、各組織に速やかな更新を求めました。

サイトの停止は、それ自体が攻撃を受けた証拠ではありません。修正が終わるまで外部からの接続を遮断し、危険を減らすための対応です。

こうした動きは、Redditに投稿していたサイト管理者の間でも見られました。

PHPの開発者が集まる「r/PHP」では、修正版の公開を待つ段階で、次のコメントが寄せられています。

うちはもう、運営しているサイトを全部停止したよ。危険を冒せないから。

— u/Morlaix

自分でサーバーを運営する人たちが集まる「r/selfhosted」には、多くの顧客サイトを抱える人からの声もありました。

お客さんが大騒ぎしてる。うちはWordPressのサイトを400件抱えてるんだよ、ははは。今日は長い一日になりそうだ……。

— u/Acrobatic_Equipment1

サイトを運営する側にとっては、修正版が出たら更新するだけ、というわけにもいきません。

更新後にサイトが正常に動くか確認し、問題が生じた場合には復旧する必要があります。多数のサイトを管理していれば、それだけ作業も増えます。

WordPressのコミュニティでは、修正版の公開日についてこんなコメントもありました。

金曜日じゃなくて、水曜日に公開してくれてよかった。

追記:Ubuntuの更新は発表後すぐに利用できるようになって、問題なく完了したよ。

— u/Gaston-Glocksicle

Ubuntuは、ウェブサーバーなどでも使われる基本ソフトの一つです。この方は、PHPの修正を含む更新を無事に適用できたようです。

ところが、そのコメントには思わぬ返信が付いていました。

でも今、俺は誕生日にサーバーの修正作業をしてるんだよね。

— u/GunGeekATX

急なセキュリティ対応は、週末どころか誕生日の予定にも割り込んでくるようです。

広告下に記事が続いています
広告下に記事が続いています

「何年も更新を先延ばしにしていた」古いシステムを抱える会社の事情

今回の問題で、技術者たちが特に頭を悩ませていたのが、長い間更新されていないPHPです。

PHPには複数のバージョンがあり、古いものは開発元による通常のセキュリティサポートが終了しています。

ところが、企業で使われているシステムを新しいバージョンに移すには、プログラムの修正や動作確認が必要になる場合があります。業務に欠かせないシステムほど、更新を簡単には決められないこともあるようです。

r/PHPでは、ある技術者が会社の事情を率直に書き込んでいました。

この件について、上司にいくつか情報を伝えたところだ。

うちは2021年からずっとPHP 7.2を使っていて、毎年「今年の夏が終わるまでには更新する」と言われてきた。

でも会社はPHPのバージョンアップに関心がない。会社からすれば、それで利益が増えるわけじゃないから、どうでもいいんだ。

最初に更新を検討し始めたときはPHP 8.1を目指していたのに、何度も延期されて、今ではPHP 8.4への更新を考えている。

今回の件で、あいつらもようやく動く気になるかもしれない。

追記(10月21日朝):どうやらうちのセキュリティ担当チームも把握していたらしい(当然だけど)。みんなパニック状態だよ(笑)。何とか計画をまとめて、できるだけ早く全部PHP 8.2.35に更新しようとしてる。楽しいことになってきた。

追記2(10月21日夜):やったぞ、Reddit! 本番環境をPHP 8.2.35に更新できた!

Linuxのディストリビューション自体があまりにも古くて、そっちも更新しなきゃならなかったから、丸一日かかった。でも終わったよ。

新年にはPHP 8.4へ移行する話もした。実現するかは分からないけどね。

正直なところ、ようやくPHP 8系のコードを書けるのがうれしいよ(笑)。この会社に入ってからずっと7.2だったから、たとえ8.2でもいい変化だ。

— u/300ConfirmedGorillas

ここでいう「本番環境」とは、実際の利用者がアクセスするシステムのことです。また、Linuxのディストリビューションは、サーバーなどで使われる基本ソフト「Linux」を利用できる形にまとめたものを指します。

この方の場合、PHPだけでなく、その土台となるソフトも古かったため、更新作業が丸一日がかりになりました。

ただ、長年先延ばしになっていた更新が、今回のニュースをきっかけに実現したという点は印象的です。

同じコメントへの返信には、こんな皮肉もありました。

うちにはPHP 5.6で動いている古いサーバーが1台あるよ。

幸いなことに、会社でいちばん利益を上げている事業の部分だから、更新する必要なんてないね。

— u/Fun-Consequence_3112

利益を上げている大切なシステムなのに、古いPHPを使い続けている状況を皮肉ったコメントです。

更新に消極的なのは、システムが古い会社だけではないようです。

修正版の公開を知らせるスレッドには、こんな愚痴もありました。

大丈夫だよ、みんな。うちの上司によると、作業量を見積もったJiraのチケットがなければ修正を適用できないし、次のスプリントまで待ってもいいらしい……。

🙄

— u/DOOManiac

Jiraは、開発チームが作業や進捗を管理するサービスです。「スプリント」は、一定期間に区切って開発作業を進める際の単位を指します。

緊急の修正なのに、通常の作業手続きを優先するという話に、別の人が返信しました。

冗談であることを心から願うよ! はは。

— u/wmichben

(冗談じゃなかったんだ。でもありがたいことに、ほかの人が引き継いでくれたから、もう自分の問題じゃなくなったよ。)

— u/DOOManiac

技術的には修正方法が用意されていても、会社の判断や作業体制によって対応が遅れることがあります。

なお、PHPの開発元がサポートを終了した古いバージョンでも、サーバー用ソフトの提供会社が修正を取り込んでいる場合があります。単純にバージョン番号が古いから未対策だとは判断できず、実際に使っている製品の更新状況を確認する必要があります。

広告下に記事が続いています
広告下に記事が続いています

なぜ修正版を出す前に危険を知らせたのか?

Redditでは、PHP開発チームが修正版の公開に先立って警告したことについても議論が起きていました。

通常、セキュリティ上の欠陥を詳しく公表すると、攻撃者にもその情報が伝わります。

そのため、修正版を用意してから問題を公表することには意味があります。

今回の事前警告に疑問を持った人もいました。

更新版を公開する前に発表したのが理解できない。

脆弱性に注目が集まるのは、修正版が利用できるようになった「後」であってほしい。公開前じゃなくてね。

— u/SurelyNotAnOctopus

これに対して、次のような返信が寄せられています。

修正を公開すれば、具体的にどこに脆弱性があるのかを知らせることにもなるからだよ。

ほとんどのIT担当者は、いきなり公開されたら完全に不意を突かれる。すぐには対応できないからね。

修正版の公開を予定しておくことで、その問題をできる限り軽減したんだ。

完璧な方法ではないし、今回の件で、あらゆるソフトウェアの更新を配布する仕組みに欠点があることがはっきりしたのも確かだ。

— u/PolarityInversion

これは今回の発表をめぐる難しさをよく表したやり取りです。

開発元が突然修正版を公開しても、世界中のサイト管理者が同時に更新できるわけではありません。

一方、事前に危険性を知らせれば、攻撃者が対策の進んでいないサイトを狙う手がかりになるおそれもあります。

PHPの開発を支援する非営利組織「PHP Foundation」によると、当初は10月22日に修正版を公開する予定でした。しかし、10月20日に脆弱性の識別番号などの情報が予定より先に出回ったため、公開を1日前倒しして21日としたそうです。

事前に修正版を配布して準備していた関係企業の作業も考慮し、警告と修正版の公開時期を調整したと説明しています。

広告下に記事が続いています
広告下に記事が続いています

実は2024年から問題の兆候が見つかっていた

今回の問題には、もう一つ気になる背景があります。

PHP Foundationは、今回の2件のうち、メモリ不足時の処理に関係する脆弱性について、2024年の時点ですでに問題の兆候を把握していたことを明らかにしました。

外部のセキュリティ監査をきっかけに、PHP内部の処理に問題があることが分かったものの、当時は具体的な攻撃方法が見つかっていませんでした。

さらに、修正によって従来のプログラムが動かなくなったり、別の不具合が生じたりする懸念もあり、対応が進まなかったといいます。

PHP Foundationは、この遅れについて、セキュリティチームの意思決定の仕組みや人員不足による問題だったと認めています。

その後、2026年8月に複数のセキュリティ研究者から、外部から不正なプログラムを実行できるという報告が寄せられ、危険性の大きさが明らかになりました。

今回の発表は、突如発見された欠陥だけでなく、以前から認識されていた問題が、実際に悪用できる重大な脆弱性として確認された結果でもあったわけです。

脆弱性の調査にもAIが使われていた

今回の調査には、AIも関わっています。

PHP Foundationによると、2026年にはAIを利用したコードの調査や、報告された脆弱性が本当に悪用可能かを確認する作業が行われていました。

同組織は、AIを活用したセキュリティ調査が増えたことで、以前より多くの報告が寄せられていると説明しています。一方で、誤った報告や重複した報告も多く、それらを検証する作業が必要になっているそうです。

ただし、今回の問題が「AIによって初めて発見された」というわけではありません。先ほどのとおり、少なくとも一方の欠陥については2024年に兆候が確認されていました。

脆弱性の発見が相次ぐ状況について、WordPressのコミュニティでは、こんな不安の声もありました。

そう感じるのは自分だけかな。ネット上のあらゆるものが、きしみ始めているように感じる。

— u/sensesalt

昔からきしんでいたんだよ。今になって、その音が聞こえるようになっただけさ。こうした修正が行われるのは、いいことだよ。

— u/DashBC

次々と見つかる脆弱性を、インターネット全体が危うくなっている証拠と受け止める人もいれば、これまで表面化していなかった問題が発見され、修正されていると考える人もいます。

今回のRedditでは、利用者の不安だけでなく、サイトを守るために仕事を中断する人、何年も先延ばしにされてきた更新を実現した人、そして修正の公開方法そのものを議論する人たちの姿が見られました。

私たちが普段何気なく利用しているウェブサイトも、裏側では多くの人の作業によって支えられているのですね。

amazon.co.jp
東洋図書出版 パスワード管理帳 B6 120 アカウント 上製本 ハードカバー 日本製
¥1,100円 税込(2026年10月22日時点)
Amazon.co.jpで見る

参考情報と翻訳元

公式発表・調査資料

Redditの翻訳元

コメント

タイトルとURLをコピーしました