重大な脆弱性への対応では、被害が確認されていなくても、Webサービスの一時停止を迫られる場合があります。2026年10月、PHPの問題に対応するため、Wikimedia Foundationは関連サービスの一部を停止しました。今回、AIは問題の発見に加え、複雑な条件の分析や、攻撃が実際に成立するかの検証にも使われました。従来は悪用が難しかった脆弱性が、現実的な攻撃対象になりつつあります。修正版の公開直後から攻撃が試みられるなか、企業は更新を急ぐ必要があります。安全性を確保できるまでサービスを一時停止するかどうかも、判断できるようにしておかなければなりません。

【関連記事】MCPの時代は終わった？ AIの進化で変わるツール連携の形

AIが複雑な脆弱性の悪用を容易にする

長く使われ、多くの開発者が確認してきたソフトウェアにも、重大な問題が残る場合があります。さらに、問題の存在を把握していても、実際に攻撃できる条件が分からないことがあります。今回のPHPの事例は、AIがその条件を解明し、脆弱性の悪用を容易にし得ることを示しています。

PHPの実行環境で見つかった重大な問題

PHPは、Webサーバー上でプログラムを動かすために使われる言語であり、その実行環境でもあります。Webサイトの作成・管理に使われるWordPressやDrupalなどもPHPで動きます。2026年10月21日、PHPプロジェクトは、2件の重大な脆弱性を修正したPHP 8.5.12、8.4.27、8.3.36、8.2.35を公開しました。脆弱性は、それぞれCVE-2026-109618、CVE-2026-109619という識別番号で管理されています。条件によっては、ログインしていない攻撃者が、離れた場所からサーバー上でプログラムを実行できます。

問題は、PHPが通信を処理している途中でメモリ不足などの異常が起きた際に、内部のデータを正しく扱えなくなる点にあります。準備が終わっていないデータを有効なものとして扱ったり、すでに解放したメモリを後の処理で使ったりする危険があります。通常の処理が異常終了した後も、その影響が内部に残り、別の処理へ及ぶ場合があります。攻撃者はこうした状態を引き起こし、情報の取得やプログラムの実行に悪用できるかを調べます。

攻撃の条件は、PHPの動かし方によって異なります。PHPの公式発表によると、WebサーバーのApacheに組み込んで使うmod_phpでは、アプリケーションのコードが動く前に攻撃できる経路が実証されています。PHPを別のプロセスで動かすPHP-FPMでも、アプリケーションの処理を通じた遠隔コード実行が確認されました。Webシステムの管理者は、使っているPHPの版に加え、実際にどの構成で動いているかも把握する必要があります。

AIが攻撃の成立条件を調べる

PHP Foundationによると、一部の問題については、2024年の外部監査後の作業ですでに兆候が見つかっていました。当時は具体的な悪用経路が確立されておらず、修正方法を決めるのも難しい状況でした。従来のプログラムとの互換性、処理性能、PHPに機能を追加する拡張機能への影響などを考慮する必要があったためです。2026年にCalif、OpenAI、Wizなどから報告が寄せられ、実際に攻撃できる経路と影響が明らかになると、修正が最優先になりました。

OpenAIは、セキュリティ企業Califが、オープンソースソフトウェアの安全性を高める取り組み「Patch the Planet」でGPT-5.6 Solを使い、重大な問題を発見したと説明しています。Wizも独立して調査し、Wiz Atlas、Gemini 4 Argon、GPT-5.6 Solを使用しました。特にGemini 4 Argonは、脆弱性の発見や攻撃の検証、防御側での攻撃の検知、修正版の確認に貢献したとされています。AIの利用は、ソースコードを読んで怪しい箇所を指摘する段階から、検証結果を確かめながら調査を進める段階へと広がっています。

Wizの研究では、複数の不具合を組み合わせ、PHPがメモリを確保・再利用する動きに合わせて攻撃方法を調整する必要がありました。PHPの版、設定、アプリケーションの挙動が変わると、同じ方法がそのまま使えるとは限りません。失敗の原因を調べ、条件を変えて試す作業が繰り返されます。AIは、この分析と調整を助けました。Wizは、人の手では実装や展開が難しかった複雑な攻撃も、AIの支援によって実行に移せるようになったと評価しています。今回の問題が重大なのは、従来は悪用しにくかった脆弱性も、AIによって実際の攻撃対象になり得るためです。

発見から修正までを支える検証

PHP以外でも、AIでソフトウェアを調べ、開発者への報告と修正を進める取り組みが広がっています。Anthropicは2026年3月、Mozillaとの協力で、Claude Opus 4.6が2週間でFirefoxの脆弱性を22件発見したと発表しました。このうち14件を、Mozillaは深刻度の高い問題と評価しています。

AIの報告を受け取った開発者は、どの条件で問題が起きるかを確かめ、修正後に同じ問題が起きなくなったかを検証します。修正によって、これまで正常に動いていた機能が損なわれていないかも確認します。Anthropicは、問題の再現と通常のテストの両方を使ってAIの提案を検証する方法を紹介しています。PHP FoundationもAIを報告の確認に使いながら、判断と修正は担当者が行っていると説明しています。

AIによって問題を見つけやすくなると、開発者が報告を確認し、修正を行い、利用者向けに修正版を提供する作業も増えます。利用企業に修正版が届き、実際のサービスへ適用されるまで、脆弱性は残ります。今回もPHPの保守担当者が修正と公開を主導し、研究者やサービス事業者が検証や防御策の準備に参加しました。問題を発見するだけでなく、その後の修正や適用まで進めて初めて、AIの調査成果が利用者の保護に役立ちます。

被害を防ぐためにサービスを止める

修正版が公開された時点で、運用担当者が落ち着いて準備を始められるとは限りません。攻撃者も公開情報を調べ、更新前のサーバーを探します。被害を防ぐため、更新と安全性の確認が終わるまで、サービスを一時停止しなければならない場合があります。

修正版の公開直後から使われる攻撃用コード

AWSの脅威調査チームは、攻撃を観測するシステム「MadPot」で、10月17日に今回の脆弱性「PHP2Shell」の悪用を試みる通信を確認したと報告しています。これは修正版と詳細情報の公開より前です。公開日の10月21日にも、複数の送信元から攻撃の試行を観測しました。脆弱性の情報が一般に公開される日と、攻撃者が活動を始める日は、必ずしも一致しません。

同チームは、修正版と情報の公開から数時間以内に追加の攻撃用実証コードが現れ、それらを使ったセンサーへの攻撃をほぼ直ちに観測したと報告しています。実証コードは、脆弱性を利用できるか確かめるためのプログラムです。こうしたコードが出回ると、ほかの攻撃者も試せるようになります。AWSは、観測した試行が実際の運用環境で成功したかは不明としています。攻撃の試行が、そのままサーバーへの侵入や情報流出を意味するわけではありません。ただし、運用側が対応を始める時点では、すでに攻撃が試みられていました。

AWSは、AIを使って修正前後のコードの違いや告知内容を分析すると、攻撃方法の開発にかかる負担が下がると説明しています。修正されたコードは、防ぐべき問題を開発者へ伝えると同時に、攻撃者が問題の箇所を調べる手掛かりにもなります。そこから攻撃方法を組み立て、対象の環境に合わせる作業をAIが助けると、利用企業が更新を終える前に攻撃が広がり得ます。

公開された情報を読み、影響を調べ、更新日を相談するという通常の保守の進め方では、危険な状態が長く残る場合があります。自社で更新するのか、サービス事業者や保守先へ依頼するのかによって、担当者が実行できる作業も変わります。更新を依頼した後も、完了まで公開を続けるか、接続を制限するか、停止するかを判断する必要があります。

公開サーバーは日常的に探索されている

NICTが2026年2月に公表したNICTER観測レポートでは、2025年に観測したサイバー攻撃関連通信は約7,010億パケットに達しました。前年から約2.2%増え、過去最多となっています。観測には、通常の通信には使われていないIPアドレスなどで構成するダークネット観測網を使用しています。NICTは、インターネット上の探索活動や攻撃の準備が、高い水準で常態化していると説明しています。

この通信には、調査目的と推定されるスキャンも含まれます。観測したパケット数は、侵入に成功した件数を表すものではありません。ただ、通信先を探して接続を試す活動が、日常的に続いている様子を示しています。脆弱性の情報を得た攻撃者は、特定の企業を詳しく調べるだけでなく、インターネット上を広く探索して攻撃対象を探します。自社を名指しした攻撃の予告がなくても、インターネットへ公開したシステムが探索される可能性を踏まえて対策する必要があります。被害の報告が増えるのを待ち、その後で対応を検討している間にも、更新前のシステムは公開されたままです。自社のシステムが影響を受けるか、対策が完了するまでにどのような措置を取れるかを、早い段階で確かめる必要があります。

安全に更新するまで公開を止める

Wikimedia Foundationは今回、PHPの脆弱性へ対応するため、多くの関連サービスを意図的に停止したと公表しました。対象には、開発者がツールやサービスを動かすToolforgeやCloud VPSなどが含まれます。同財団は、安全に修正を適用して再開できるようになるまで、サービスを公開しない方針を示しています。侵入による被害が直ちに確認されなくても、被害を防ぐための停止が必要になる場合があります。

同財団によると、サービスを担当するボランティア開発者が変更を加える必要があり、安全に再開できる状態になるまで停止を続けるサービスもあります。利用者がPHPの版を直接管理している場合には、財団側で一括して修正し、安全に再開するのが難しくなります。サービスの運営元と、実際にソフトウェアを更新する担当者が異なるためです。修正版の入手後も、対象を特定し、担当者と連絡を取り、更新の完了を確かめる時間が必要になります。

AIが複雑な脆弱性の悪用を容易にし、広く使われるソフトウェアで同様の問題が見つかると、今回のように緊急更新や一時停止を迫られる状況が再び起こる可能性があります。企業は、侵入による損害に備えるとともに、被害を防ぐためにサービスを停止した場合にも、その期間を短くできるよう準備しておく必要があります。緊急時にソフトウェアを更新できるよう、どのようなサービスを運用しているかを一覧で確認し、更新を実行する担当者や保守先も把握しておく必要があります。どのサービスが影響を受け、誰が修正できるかの確認が長引くと、公開を続ける危険や、停止による利用者への影響も長く続きます。更新を依頼する相手に、実際の作業を行う権限があるかを確認しておきます。更新後の安全性の確認や再開の判断を誰が担うかも決めておくと、緊急時の依頼と確認を進めやすくなります。

WAFとMFAでWebシステムの防御を整える

緊急更新までの危険を下げる対策と、日常的なアカウントの乗っ取りを防ぐ対策には、それぞれ役割があります。Webへの通信を検査するWAFと、利用者の認証を強めるMFAを、更新や接続経路の制限と組み合わせて使う必要があります。

要求と応答の両方を使って攻撃を検知するWAF

WAFはWeb Application Firewallの略で、Webアプリケーションに届く通信を検査する仕組みです。データベースを不正に操作しようとする入力や悪意のあるスクリプトを検知し、接続元のIPアドレスなどもルールに照らして通信を判定します。AWS WAFでは、文字列、データの長さ、接続元などの条件を組み合わせられます。業務で必要な通信を通しながら、攻撃に使われる通信を遮断するための対策です。

Cloudflareは、脆弱性の公開前から防御策を準備し、無料・有料プランのWAF利用者に標準で適用したと説明しています。適用を始めたのは10月21日03:02 UTCで、日本時間では同日12時02分です。同社は攻撃通信を観測し、防御を回避しようと送信内容を変える動きも確認しました。広く使われるソフトウェアの脆弱性に対し、防御サービスの提供元が対策を配布する仕組みは、個々の利用企業がPHPを更新するまでの危険を下げる助けになります。

Cloudflareは、今回の対策で、同じHTTP通信の要求と応答を組み合わせて検知するfull transaction detectionという新機能を使いました。利用者から届く要求だけでは攻撃と正常な利用を十分に見分けられない場合に、サーバーが返す内容も確認して判断します。条件に一致した応答は、要求元へ届く前に遮断できます。要求の内容に加え、サーバー側での処理結果も検知に使えるようになりました。同社は、こうしたWAFの防御を使っている場合にも、PHP自体の更新を求めています。

WAFを通る接続経路と検査範囲を確かめる

WAFを有効に働かせるには、実際にプログラムが動くサーバーへの接続経路も整える必要があります。利用者向けのドメインを通る通信はWAFで検査していても、別の経路でサーバーへ直接接続できる場合、その通信は検査を受けずにサーバーへ届きます。Cloudflareは、接続元の制限や、サーバーに公開IPアドレスを持たせず、外向きの通信で接続するCloudflare Tunnelなどを案内しています。守りたいサーバーへ届く通信が、どこを通るかまで確認しましょう。

検査できるデータ量には上限もあります。たとえばAWS WAFをApplication Load Balancerと組み合わせる場合、要求本文の検査範囲は先頭8 KBです。上限を超えた場合の扱いは設定でき、WAFが通信を許可すると、検査範囲の外のデータもサーバーへ届きます。業務で必要なアップロードなどを考慮し、上限と超過時の扱いを確認する必要があります。防御ルールや検査範囲、接続経路を適切に設定するとともに、ソフトウェアを更新して脆弱性の原因を取り除きます。

フィッシングに強いパスキーでMFAの選択肢が広がる

MFAは多要素認証の略で、知っている情報、持っている端末、生体情報といった異なる種類の要素を組み合わせる認証です。パスワードに加え、認証アプリが生成するコードや、SMSで受け取るコードを使う方式が代表例です。ただし、偽サイトにコードを入力させ、それを正規サイトへ中継する攻撃もあります。米国のNISTは、ワンタイムコードを手入力する方式を、フィッシング耐性のある認証方式には分類していません。MFAに使う認証方法によって、こうした攻撃への強さが異なります。

普及が進むパスキーでは、端末などで管理する暗号鍵を使って認証します。基盤となるFIDO2/WebAuthnの仕組みは、認証先のドメインと認証を結び付け、偽サイトへ認証情報を渡すのを防ぎます。鍵の所持と、鍵を使うためのPINや生体認証による本人確認を組み合わせると、パスワードを入力しない多要素認証も実現できます。サービス側は、端末で本人確認が行われたかも検証します。利用者は、端末で本人確認を済ませ、正規の接続先へログインできます。導入時には、端末を失った際にアカウントを復旧する手段も用意し、本人確認や通知の方法を定める必要があります。

FIDO Allianceが10月15日に公開したPasskey Index 2026では、成功したログインに占めるパスキーの割合は、回答のあった12サービスの平均で36%でした。フィッシング被害の変化を測定した8サービスは、すべて導入後の被害減少を報告しています。パスキーは、対応機能が提供される段階を経て、利用者が日常的に使うものになってきています。

接続前の認証と緊急対応を組み合わせる

アプリケーション内のMFAは、そのシステムへログインする利用者を確認します。社内向けの業務システムなどで、接続できる利用者を限定する場合には、通信がアプリケーションへ届く前に利用者を認証する方法もあります。Cloudflare Accessなどの認証ゲートウェイは、利用者の所属や端末の状態、認証方式などを条件に、接続を許可します。今回のPHPの問題にはアプリケーションの処理前に攻撃できる経路もあるため、認証をどこで行うかも踏まえて防御を設計する必要があります。

緊急対応を速めるため、使用中のソフトウェアとその版、更新担当者、保守先への連絡方法を日頃から把握しておきましょう。重大な問題が公表された際には、担当者が影響を確認し、責任者が公開の継続や一時停止を判断します。更新後は正常に動くかを確かめるとともに、ログやサーバーの状態を調べ、不審な通信、予期しないプロセスの実行、ファイルの変更などを確認します。再開の判断まで担当者と責任者が連携できるようにしておきましょう。

WAFによる通信の検査、MFAによるログインの保護、更新による脆弱性の修正を組み合わせるとともに、必要な場合には接続先や利用者を制限します。停止が必要なサービスと担当者を特定し、安全性を確認したうえで再開できる体制を整えておくと、停止が長引くのを防ぎやすくなります。今回のような緊急対応に備え、製品の導入と保守・運用の両面で対策を進める必要があります。

まとめ

今回のPHPの事例は、AIが悪用の条件を解明すると、長く残っていた複雑な脆弱性も現実的な攻撃対象になり得ることを示しました。修正版の公開後には、数時間以内に現れた攻撃用コードが、ほぼ直ちに観測用システムへの攻撃に使われています。企業は、情報を得てから対応方針を相談している間にも、攻撃が始まる可能性を踏まえて備える必要があります。

侵入や情報流出が直ちに確認されなくても、サービスを公開したままでは危険が残るため、一時停止しなければならない場合があります。今後、AIによる調査や攻撃方法の開発が進むと、広く使われるソフトウェアを利用する企業は、同様の緊急対応を迫られる可能性があります。被害を防ぐための停止も、事業継続上の課題になります。

WAFやMFAを導入し、通信とアカウントを保護するとともに、緊急更新、停止、再開を速やかに進める体制を整えましょう。使用中のソフトウェアと担当者を把握し、防御設定の変更や更新後の安全性の確認を行えるようにしておくと、攻撃にさらされる時間と停止期間を短くするのに役立ちます。

参考文献

Security advisory: Critical remote code execution vulnerabilities, update now — PHP

Today’s PHP Security Release, and How We’re Strengthening PHP Security — The PHP Foundation

Cloudflare deploys protections against php2shell vulnerability — Cloudflare