「破られる前提」で備える時代へ——PHPの深刻な脆弱性（php2shell）とAI時代のサイバー攻撃について、私が考えたこと

こんにちは。株式会社UPF代表の仲手川です。

ここ数日、「PHP」という言葉をニュースで耳にした方も多いと思います。
2026年10月21日、Webサイトを動かすプログラミング言語「PHP」に、2件の深刻な脆弱性が公表されました。
修正版の公開を前に、国の機関や自治体、銀行や証券会社、鉄道・航空、電力、レンタルサーバー事業者など、国内でも多くの組織がWebサイトやサービスを一時的に止める事態になりました。

普段、システム開発に関わる人でもなければ、PHPという言葉を使うことはまずありません。
ただ今回の件は、エンジニアだけの話ではなく、経営に直結する話だと私は感じています。
今日は、企業の情報マネジメントとリスクマネジメントをご支援する会社の代表として、何が起きたのか、そして企業はこれからどう備えればよいのかを、できるだけわかりやすく整理してみたいと思います。

まず、何が起きたのか。
PHPは、Webサーバーの側で動くプログラミング言語で、そのプログラムを実行するソフトウェアの名前でもあります。
WordPressをはじめ、多くのCMS（ホームページの更新システム）や会員サイト、ECサイトがPHPで動いています。
サーバー側の言語がわかっているWebサイトのうち、約7割がPHPを使っているという調査もあります（W3Techs調べ）。

今回見つかったのは、PHPがメモリを扱う処理の欠陥です。
少し乱暴に言えば、準備の途中だったり、すでに役目を終えて無効になっていたりするはずの情報を、そのまま有効なものとして使ってしまう。
その隙間に、不正なコードを紛れ込ませることができてしまう、という種類の問題です。

※公表資料・報道をもとに作成しました。
（出典：JPCERT/CC（10月22日）、窓の杜、piyolog）

今回の脆弱性が「特に怖い」と言われる理由は、3つあります。
1つ目は、ログインが要らないことです。
これまで、システムが破られる典型的なパターンは「ログインされてしまう」ことでした。
パスワードが流出し、攻撃者が管理者になりすましてログインし、データを抜き取ったり消したりする。
ところが今回は、ログインしなくても、外部から攻撃が成立し得る。
管理者のパスワードを盗む必要すらないのです。

2つ目は、サイトのプログラムが動く前に攻撃できてしまう場合があることです。
一部の構成では、Webサイト側のプログラムが処理を始める前の段階で、攻撃が成立することが確認されています。
つまり、サイト側でどれだけ丁寧にプログラムを作り込んでいても、その手前で入られてしまうおそれがあるということです。

3つ目は、PHPがあまりにも広く使われていることです。
1つの欠陥が、世界中の膨大な数のサイトに同時に当てはまってしまう。
この3つがそろったことが、今回の事態の大きさにつながりました。

実際に攻撃を受けた場合には、ホームページの改ざん、PHPからアクセスできる情報の窃取、不正なプログラムの設置などが起こり得るとされています。
発見者の検証では、サーバーのメモリからパスワードやAPIキーといった重要な情報を読み出せることも示されています。

10年以上潜んでいた穴を、AIが突き止めた。
今回もうひとつ大きかったのは、この脆弱性を見つけたのがAIだったことです。
関係各社の発表や報道によると、2026年8月、複数のセキュリティ企業などが、それぞれ最先端のAIモデルを使って、この欠陥と具体的な攻撃の方法を相次いで突き止めました。
問題のもとになった不具合は10年以上前からPHPの中に残っていたとされ、2024年の外部監査をきっかけに兆候が見つかった際にも、具体的な攻撃経路までは特定されていませんでした。

世界中で長年使われ続けながら、具体的な攻撃の方法までは特定されていなかった穴を、AIが突き止めた。
もし、これを先に見つけたのが悪意のある攻撃者だったらと考えると、正直、背筋が寒くなります。

さらに今回は、順番も悪かった。
本来、脆弱性は「こういう穴が見つかりました。修正版はこちらです」と、修正版と同時に公表されるのが通常の流れです。
そうすれば、企業はすぐに更新に動けます。
ところが今回は、修正版の公開を前に、脆弱性の識別番号などの情報がネット上に出回り、修正版の公開は当初の予定より1日前倒しされました。
「どこかに大きな穴があるらしい」という情報だけが先に広まると、攻撃者に狙いどころを教えることにもなりかねません。
実際、公表の前から攻撃の試みが観測されていました。
米Cloudflare社のCEOは、同社のネットワークで、公表後45分で数万件、2時間以内に数十万件の攻撃の試みがあったと明らかにしています。

国内では10月21日の夜、高市総理がXで修正版の適用準備を呼びかけ、適用が難しい場合はWebサイトの一時停止も有効な策のひとつだと発信する、異例の展開になりました。
セキュリティ研究者の集計では、確認できただけでも200を超える国内の組織が、サイトやサービスを予防的に止めています。
すぐに動いてサイトを止めたところは被害を防ぎやすい一方で、状況がよくわからないまま放置してしまったところは狙われやすくなる。
そういうことが、実際に起こり得る状況だったのです。

（出典：INTERNET Watch、piyolog、Fortune）

AIが「穴」を見つける時代に、防ぐだけでは追いつかない。
私が今回いちばん考えさせられたのは、これが一度きりの出来事ではない、ということです。
誰も気づかなかった隙間を、AIがこれから次々と見つけていく可能性があります。
そしてAIは、守る側だけでなく、攻める側も使えます。
攻撃の準備から実行までをAIで自動化できれば、攻撃のスピードも規模も、これまでとは比べものになりません。

守る側もAIを使って防御を固めていくべきですが、現実には攻める側のほうが速い場面も多いでしょう。
「穴が見つかる、止める、直す、再開する。そしてまた次の穴が見つかる」。
そんなことが、これからは珍しくなくなるかもしれません。

そもそも、世界中で10年以上使われながら攻撃経路が特定されていなかった穴に、一企業が自力で気づくのは現実的ではありません。
どれだけ対策をしていても、「うちは破られない」とは言い切れない時代になったのだと思います。

だからこそ、「破られない」ではなく「破られる前提」で。
大事なのは、破られたときに「情報を全部持っていかれた」「業務が全部止まった」とならないようにしておくことです。
システムは乗っ取られることがあるし、不正に操作されることもある。
その前提に立って、それでもこの情報は守る、この業務は続ける、という仕組みを、あらかじめ考えて磨いておくこと。
セキュリティの世界で「侵害を前提とした対策」とも呼ばれる考え方で、これからの企業にとって欠かせないものになると考えています。

具体的には、たとえば次のようなことです。

• 把握する：自社のサイトやシステムのどこでPHPやCMSが動いているかを、Web制作会社やレンタルサーバーなどの委託先も含めて、すぐに答えられるようにしておく
• すぐ塞ぐ：更新の手順と、「止める」「更新する」を誰が判断するのかを決めておく
• 気づく：ログや監視の仕組みを整え、異常に早く気づけるようにしておく
• 持たない・広げない：Webサーバーに必要以上の個人情報や機密情報を置かない。アクセスできる権限も必要最小限にする
• 止めても続ける：サイトやシステムを一時停止したときに、問い合わせや受注をどう受けるか、代わりの手段を決めておく

ISMSやPマークは、こうした備えを「回し続ける」ための仕組みです。
ここに挙げたことは、実は特別なことではありません。
ISMS（ISO/IEC 27001）では、情報資産の把握、技術的な脆弱性の管理、委託先の管理、インシデントへの対応、事業継続のための備えなどが、管理策として整理されています。
プライバシーマーク（Pマーク）でも、個人情報のリスクを洗い出して対策を決め、漏えいなどが起きたときの手順を定めて運用し、見直していくことが求められます。

ただ、こうした仕組みは、取得しただけでなく、日頃から実際に回しているかどうかで、いざというときの動きが大きく変わります。
今回の件を振り返って、次の3つを確かめてみると、自社の仕組みが実際に回っているかどうかを知るよい機会になるはずです。

• 自社のサイトがPHPで動いているかどうか、すぐに答えられたか
• Web制作会社やサーバー事業者と、すぐに連絡が取れたか
• 「止めるか、続けるか」を、誰が、何を基準に判断したか

UPFは、PマークやISMSの取得・運用を通じて、企業の情報マネジメントとリスクマネジメントを支える仕事をしています。
これからの時代、「破られないこと」と同じくらい、「破られたときに、何を守り、どう続けるか」をお客様と一緒に考えることが、私たちの役割として大きくなっていくと感じています。

最後にひとつ。
今回の穴を突き止めたのも、AIでした。
AIは攻める側の道具であると同時に、守る側の強力な道具でもあります。
システムが便利になるほど、社会はかえって不安定になっていく。そんな少し嫌な時代になったのも事実です。
だからこそ、守る側も新しい道具をしっかり使いこなしていかなければならない。
今回のニュースを見ながら、改めてそう感じました。

よくある質問

Q. PHPの脆弱性「php2shell」とは何ですか？
A. 2026年10月21日に公表された、PHPの2件の脆弱性（CVE-2026-109618、CVE-2026-109619）の通称です。
認証なしで、外部からPHPの実行権限で任意のコードを実行されるおそれがあり、PHPの開発チームはCVSS 4.0で9.2（緊急）と評価しています。
修正版は、PHP 8.5.12、8.4.27、8.3.36、8.2.35です。

Q. 自社のWebサイトが影響を受けるかどうかは、どう確認すればよいですか？
A. まず、サイトやシステムでPHPが使われているか、使われているバージョンは何かを確認します。
レンタルサーバーやクラウドサービスを利用している場合は事業者のお知らせを確認し、Webサイトの制作・保守を委託している場合は、委託先に対応状況を問い合わせてください。
PHP 8.1以前は公式の修正版が提供されないため、サポートされているバージョンへの移行も検討が必要です。

Q. 修正版に更新すれば、対応は完了ですか？
A. 更新は最も重要な対策ですが、それだけで完了とは言い切れません。
今回は公表前から攻撃の試みが観測されており、JPCERT/CCも、更新とあわせて侵害の有無を確認するよう呼びかけています。
ログに不審なリクエストやエラーがないか、不審なファイルやプロセス、外部への通信がないかなどを確認し、侵害が疑われる場合は、ログなどの証拠を保全したうえで調査を行います。

Q. 不正アクセスで個人情報が漏えいした場合、どのような対応が必要ですか？
A. 現行の個人情報保護法（2026年10月時点）では、不正アクセスのように不正な目的で行われたおそれがある個人データの漏えい等（おそれを含む）は、件数にかかわらず、個人情報保護委員会への報告と、原則として本人への通知が必要とされています。
いざというときに慌てないよう、報告や連絡の手順と担当者を、あらかじめ決めておくことをおすすめします。

Q. ISMSやPマークは、こうしたサイバー攻撃への備えに役立ちますか？
A. ISMS（ISO/IEC 27001）やプライバシーマーク（Pマーク）は、情報資産の把握、脆弱性への対応、委託先の管理、インシデントへの対応、事業継続の備えなどを、組織の仕組みとして整え、継続して見直していくための枠組みです。
日頃から運用を回しておくことで、今回のような事態が起きたときにも、状況の把握や判断を早く行いやすくなります。
UPFでは、取得だけでなく、取得後に実際に運用を回し続けるところまでご支援しています。

株式会社UPFは、プライバシーマーク・ISMS（ISO/IEC 27001）などの認証の取得・運用支援で、累計5,695社（2026年10月1日時点）の企業をご支援してきました。
「自社のどこに、どんな情報資産があるのか整理したい」「インシデントが起きたときの対応手順を見直したい」「取得したISMS・Pマークの運用を見直したい」といったご相談も承っております。
お気軽にお問い合わせください。

• プライバシーマーク（Pマーク）取得支援の無料相談
• ISMS（ISO/IEC 27001）取得支援の無料相談

数字の定義と根拠は「UPFの支援実績・継続率などの数字の定義と根拠」をご覧ください。