- PHPに重大な脆弱性が見つかり、外部から認証なしでコードを実行される危険性が実証された。
- 「ネットの7割」はPHPの利用率を示す数字であり、すべての該当サイトが侵害されるという意味ではない。
- AIの活用により、長年存在しながら悪用の実証が難しかった欠陥が、現実の脅威として浮かび上がった。
- 公表前の情報漏洩が対応を混乱させ、修正版の公開前後には攻撃の試みも観測された。
- 企業には、PHPの利用状況の把握、速やかな更新、侵入の有無の確認と、平時からの対応体制の整備が求められる。

10月20日から21日にかけて、海外のセキュリティ業界はPHPの重大な脆弱性をめぐって騒然となった。通称「PHP2Shell」。識別番号はCVE-2026-109618とCVE-2026-109619の2件である。
なお、一部の解説ではCVE-2024-11233の番号が挙げられているが、これは別物だ。米国立標準技術研究所(NIST)の脆弱性データベースによれば、CVE-2024-11233は2024年11月に公表された、特定のデータ変換フィルターで1バイトの読み過ぎが起きる不具合で、PHP 8.1.31、8.2.26、8.3.14で修正済みである。今回の騒動とは時期も中身も異なる。
「インターネットの7割に影響」という見出しも飛び交った。何が本当で、何が誇張なのか。そして今回の件は、重大な脆弱性がまた一つ見つかったという話にとどまらない。AIによって、これまで実際の攻撃に結びつけるのが難しかった欠陥までが発見・実証されるようになったという変化を示している。海外の一次情報と専門メディアの報道をもとに整理したい。
何が起きたのか
PHP財団の説明によると、この脆弱性は当初、10月22日(協定世界時14時)に修正版と同時に公表される予定だった。ところが20日の協定世界時15時ごろ、2件のCVE番号がネット上の掲示板やSNSで出回り始めた。その一つが米国の技術者向け掲示板Hacker Newsへの投稿(現在は削除)で、公表日と深刻度(最高の10点)を誤って伝えていた(Infosecurity Magazine)。PHP財団は、この段階で技術的な詳細は漏れていなかったとしている。
これを受けてPHPは同日午後に事前告知を前倒しで公表し、公開を1日早めて21日の協定世界時14時に変更した。日本時間では21日の夜にあたる。EUのコンピューター緊急対応チーム(CERT-EU)と英国の国家サイバーセキュリティセンター(NCSC)も、即座に更新できるよう準備を求める緊急の注意喚起を出した。
そして21日、PHPは修正版の8.5.12、8.4.27、8.3.36、8.2.35を公開した。あわせて、サポートが終わった7.4、8.0、8.1向けにも、最小限の修正パッチを例外的に出している(SecurityWeek)。
脆弱性の中身
PHP財団の説明をもとに、2件の中身を整理する。
CVE-2026-109618は、リクエストがメモリ上限に悪いタイミングで達すると、PHPが初期化途中の内部データを残し、後でそれを正しいものとして扱ってしまう問題だ。平たく言えば、メモリ不足で処理が途中で止まったとき、後片付けが中途半端なデータを正常なものと取り違える不具合である。Apache(mod_php)では、認証なしのリクエストによって、アプリのコードが動く前に問題を引き起こすことができ、初期設定のままで遠隔コード実行(外部からプログラムを動かすこと)が実証された。PHP-FPMでも、アプリ側の処理経路を通じて遠隔コード実行が確認されている。
CVE-2026-109619は、致命的エラーが悪い場所で起きると、内部状態が前のリクエストのメモリを指したまま残り、同じプロセスが処理する次のリクエストがその解放済みメモリを使ってしまう問題だ。平たく言えば、すでに返却したメモリを、まだ自分のものだと思い込んで参照してしまう不具合である。報告者は、Apache(mod_php)上で動く実際のアプリに対して遠隔コード実行を実証した。
Wizは、最新版のWordPress、Drupal、Joomlaに対して認証なしの遠隔コード実行を実証したとしている。ただしこれらは代表例にすぎず、欠陥はPHPそのものにあるため、単純な「Hello World」程度のアプリでも対象になり得るという。さらに、遠隔コード実行まで至らなくても、PHPプロセスのメモリからパスワードや認証トークン、APIキーを読み出せることも示している。
重要なのは、問題が特定のアプリやプラグインではなく、PHPエンジンそのものの中枢にあることだ。PHP財団は、2件ともほぼすべてのリクエストが通るメモリ管理とエラー処理の部分にあり、その中心性こそが深刻さと修正の難しさの理由だと説明している。PHPは、PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedなど、ウェブのリクエストを処理するPHP環境に広く影響し得るとしている。Google Cloudによると、対象はPHP 5.4から8.5.11までのバージョンだ。ただし個々のシステムの実際の危険性は、構成やバージョンによって異なる。
「ネットの7割」は本当か
「7割」の根拠はウェブ技術の調査会社W3Techsの統計だ。同社のデータでは、サーバー側の言語が判別できるウェブサイトのうち約70%がPHPを使っている。発見者のWizも「インターネットの70%に影響」という表現を使っているが、これはPHPの利用率であって、侵害されるサイトの割合ではない。しかも「判別できるサイトのうち」という条件付きだ。PHPを使っていることと、脆弱なバージョンがインターネットに露出していることは別の話である。
実際に外から攻撃できる状態のサーバーについて、CyberScoop(米)は、研究者の推計でインターネットに露出した脆弱なホストが130万台超、検索エンジンShodanでの集計では約190万台と報じている。調査の方法も数え方も異なるため、両者は単純には比較できない。桁の目安と受け止めるべきだろう。
より深刻なのは、同じ記事が紹介するVirusTotal(Google傘下)の分析だ。これはバージョン情報を公開しているサーバーに限った集計で、インターネット上の全サーバーを網羅したものではない。その範囲では、すでにセキュリティ更新が止まった5.4〜8.1系を動かしているのが約75万8000台、サポート中の系列は約27万2000台だった。通常の公式セキュリティ更新の対象外となった古い環境のほうが多いのである。
深刻度についても整理しておく。漏洩情報は最高の10点と伝えたが、PHPが付けた評価はCVSS v4.0で9.2点だ(PHP財団)。「最高点」は誇張だった。ただし9.2点は「緊急(Critical)」の区分であり、軽い話ではない。
攻撃は始まっているのか
ここは、何が確認されたのかを3つに分けて見る必要がある。
まず、研究者による実証。これは確定している。先に述べた通り、発見者とPHP財団は、認証なしの遠隔コード実行が実際に可能だと確認している。
次に、実環境での攻撃の試み。これも複数の企業が観測している。SecurityWeekによると、watchTowrは自社のおとり(ハニーポット)網で修正版公開とほぼ同時に攻撃の試みを観測したが、成功したものはまだないとしている。CloudflareとPatchstackも当日の早い段階で攻撃の試みを観測した。Hadrianは修正公開の数時間前に、大規模な悪用を確認したと報告している。
そして、攻撃者が実際のシステムを侵害したという確認。ここは各機関の報告内容や確認状況が異なる。米国のサイバーセキュリティ・インフラストラクチャ安全保障庁(CISA)は公表時点で悪用を確認していないとし、Huntressも顧客のシステムでの攻撃成功は確認していないとCyberScoopに語った。PHP財団も、漏洩後に出回った攻撃コードを検証したが、公開時点では実際に機能するものは確認できなかったとしている。
つまり現時点では、「攻撃が可能なことは実証され、攻撃の試みも始まっている。ただし実際の侵害については、各機関の報告内容や確認状況が異なる」というのが正確なところだ。
本当の新しさはAIにある
今回の件で私が最も注目しているのは、深刻度の点数ではなく、発見の経緯である。
PHP財団は経緯を率直に公表している。2024年、PHPはドイツのSovereign Tech Agencyの資金で久しぶりの外部セキュリティ監査を受けた。その指摘を修正する過程で、今回のメモリ不足の問題の兆候が見つかっていた。しかし具体的な攻撃経路が見つからず、修正方法をめぐる議論もまとまらないまま、作業は何カ月も停滞した。PHP財団はこれを、意思決定の仕組みと人手不足による構造的な失敗だったと認めている。
状況を変えたのがAIを使った調査だった。PHP財団によれば、OpenAIの支援プログラムの一環でセキュリティ企業Califが7月30日にPHPの監査を始め、8月11日、同じ根本原因による遠隔コード実行をCalifとOpenAIがそれぞれ独立に報告した。8月24日にはクラウドセキュリティ企業のWizが、別の攻撃経路を報告している。
Wizは、調査に自社のAI脆弱性調査ツールWiz Atlas、GoogleのGemini 4 Argon、OpenAIのGPT-5.6 Solを使ったと明かしている。とくにGemini 4 Argonは、脆弱性の発見、攻撃コードの開発、攻撃の検知、修正の検証に大きく貢献したという。なお、発見・報告に関わった企業(Calif、OpenAI、Wiz)と、Wizが使ったAIモデルは別の話である。修正する側のPHP財団も、今年はAnthropicのClaude MythosによるPHPの走査を行い、報告や攻撃コードの検証にOpenAIのツールも使っている。
Wizの説明はこうだ。問題のコードは10年以上前から存在していた。しかし、複数の欠陥をつなぎ合わせ、異なるバージョンや設定ごとに攻撃を調整する作業は、人間の手作業では実用的ではなかった。最先端のAIと適切な道具があれば、1人の研究者が1週間で、以前なら世界最高水準のチームが何カ月もかけた仕事を終えられた、という。
AIは報告の量も変えている。PHP財団によれば、AIを使った調査の広がりで報告が大幅に増え、7月1日以降だけで15件のCVEを公表した一方、無効な報告や重複した報告、再現できない報告も100件以上処理した。AIは報告の検証を助けるが、判断と修正はすべて人間が行っているという。
ここから先は私の見方である。この能力は防御側だけのものではない。「理論上はあり得るが、実際に悪用するのは難しい」という理由で後回しにされてきた欠陥が、これからは攻撃者の手でも現実の脅威に変わっていくだろう。「攻撃が難しい」ことは、もはや安全の根拠にならない。
漏洩が壊した「協調開示」
もう一つの特殊性は、情報の広がり方だ。脆弱性は本来、発見者と開発者が修正版を用意し、関係者に行き渡らせてから一斉に公表する「協調開示」で扱われる。攻撃者が知る前に、防御側が修正する時間を確保するための仕組みである。今回も8月から2カ月以上、その準備が進められていた。
しかしPHP財団によれば、CVE番号の漏洩と事前告知の後、報告者の1社であるCalifが誤って、攻撃が実際に機能する様子を示す動画を公開してしまった。動画は削除されたが複製がSNSで出回り、さまざまな攻撃コードの開発を加速させた。重要インフラ事業者向けに事前提供した緩和策の助言も漏れた可能性があるという。さらに21日、コンテナ企業のChainguardが、事前に受け取った修正を含むイメージを公表の6時間以上前に独断で公開した。PHP財団は、攻撃者が修正をバイナリの形で研究できる状態になり、多くの関係者の数週間の努力が無視されたと強い不満を表明している。
一方で、協調開示が機能した面もある。Cloudflareは公表の9時間前に防御ルールを展開し、無料プランを含む全顧客に提供した。Linuxディストリビューションや長期サポート事業者にも修正が事前に配布されていた(Help Net Security)。修正版の準備と防御側への事前配布がいかに重要かを、今回の漏洩は逆説的に示したと言える。
いま企業と組織がすべきこと
対策ははっきりしている。利用している系列に応じて、PHPを8.5.12、8.4.27、8.3.36、8.2.35、または各系列のそれ以降のバージョンに更新することだ。PHP財団は、更新できない場合の緩和策は特定の攻撃経路への露出を減らすだけで、安全にはならないと明言している。
サポートが終わった7.4、8.0、8.1を使っている場合は、例外的に出された最小限の修正パッチを当てるか、利用しているLinuxディストリビューションや長期サポート事業者に確認する必要がある。英国NCSCは、すぐに修正できないシステムはオフラインにすることも検討するよう求めている。CloudflareなどのWAF(ウェブアプリケーションファイアウォール)による防御は、同社自身が認める通り、あくまでつなぎである。
ただし、日本の企業にとっての課題はパッチの適用だけではない。そもそも自社のどこでPHPが動いているかを把握できているか。自社のウェブサイトだけでなく、制作や運用を任せている委託先の環境、キャンペーン用に作ったまま放置されているサイト、古い業務システムまで含めて、という資産管理の問題である。コンピューター・フォレンジックの専門家ハル・ポメランツ氏は、組み込み機器や放置されたアプリの中に二度と更新されないPHPが大量にあり、この問題は長く尾を引くと指摘している(Help Net Security)。更新に加え、修正前に侵入されていなかったかの確認も欠かせない。
AI時代の「パッチ」の考え方
今回のPHP2Shell騒動が示したのは、AIが脆弱性の発見と実証にかかる時間と労力を大きく引き下げつつあるという現実だ。長年放置されてきた欠陥でも、悪用できることが実証されれば、突然、世界中のシステムにとって差し迫った脅威になる。
この能力は、防御側にも攻撃側にも強力な武器になる。だからこそ企業に求められるのは、脆弱性が発表されてから対応を考えることではない。自社が使うソフトウェアとシステムを把握し、修正情報をすばやく評価し、必要な更新を実行できる体制を、平時から整えておくことだ。
AI時代のサイバーセキュリティでは、脆弱性を見つける力だけでなく、見つかった問題をどれだけ早く直し、被害を防げるかが組織の実力を左右する。「パッチは時間のあるときに当てる」という発想は、もう通用しない。
【主な出典】
- PHP財団「Today’s PHP Security Release, and How We’re Strengthening PHP Security」2026年10月21日(thephp.foundation)
- PHP公式「セキュリティリリース告知」2026年10月20日・21日(php.net)
- Wiz「PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet」2026年10月21日(wiz.io)
- SecurityWeek「PHP2Shell Patches Land as First Exploitation Attempts Hit Sensors」2026年10月21日(securityweek.com)
- CyberScoop「Prepare yourselves: PHP to release emergency fixes for 2 critical vulnerabilities」2026年10月21日(cyberscoop.com)
- Infosecurity Magazine「Critical PHP Vulnerabilities Leaked Ahead of Scheduled Security Patches」2026年10月21日(infosecurity-magazine.com)
- Help Net Security「PHP2Shell: Critical PHP vulnerabilities patched, update now!」2026年10月21日(helpnetsecurity.com)
- Google Cloud「Responding to core PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619」2026年10月21日(cloud.google.com)
- W3Techs「Usage statistics of PHP」(w3techs.com)
- 米国NIST脆弱性データベース「CVE-2024-11233 Detail」(nvd.nist.gov)







コメント