PHP2Shellは最後ではない：AIが見つける次のゼロデイに備えて、SOCが整えておくべきこと

2026年10月21日、PHPプロジェクトは緊急のセキュリティリリース（8.5.12、8.4.27、8.3.36、8.2.35）を公開しました。対象は、通称PHP2Shellと呼ばれる2件の重大な脆弱性（CVE-2026-109618、CVE-2026-109619）です。いずれもCVSS v4.0で9.2、認証なしで遠隔からコードを実行される可能性があります。公開の前後には、国内でも金融機関、航空会社、通信事業者などがWebサービスの一部を一時停止しました。

まだ更新が終わっていない場合は、そちらが最優先です。出発点はPHPのアドバイザリで、完全な対策は更新のみと明記されています。本稿が扱うのは、その「次」です。

単発の事件ではなく、繰り返される流れ

公開情報から読み取れる点は3つあります。

AIが、2つのチームから見つけた。 Califは、OpenAIのPatch the Planetの支援を受けた監査の中で、GPT-5.6 Solを使って最初の欠陥を発見しました。Wizは独自ツールのWiz Atlas、GoogleのGemini 4 Argon、GPT-5.6 Solを使い、2件を独立に発見しています。Wizの報告によると、問題のコードは10年以上前から存在し、実際に悪用できる形にするには、人間の研究者にとって限界に近い複雑な連鎖が必要でした。AIがその障壁を下げ、複数のアプリケーション向けにエクスプロイトを数時間で調整できたとのことです。

今後も増える見通し。 OpenAIは、PHPの件は発見済みの重大な脆弱性の一部であり、同様の発見が今後数か月で大きく増えると見ています（The New Stack）。同じ能力が攻撃者のエクスプロイト作成も速めるという警告も添えています。

非公開の期間は守られなかった。 Wizは8月24日にPHPへ報告し、10月21日に修正版が出ました。その間に詳細が漏れ、Cloudflareは公表の約9時間前から顧客の保護を始め、攻撃トラフィックを観測したとしています。Amazon Threat Intelligenceは10月17日、公表の4日前に最初の悪用試行を確認したと報告しています（Safeguardによる要約）。さらにJPCERT/CCは、実証コードが多数公開され、悪用を試みる通信の観測報告が相次いでいると注意喚起を更新しました。10月23日には設定条件付きの関連脆弱性（CVE-2026-115560）がPHPから公表され、IPAによれば10月26日にはPHP2Shellの2件がCISAのKEVカタログに掲載されました。なお、IPAは国内での攻撃被害の事例は把握していないとしています。

つまり、「公開されたら更新する」は最低ラインであり、それは攻撃側が動き出した後の話です。

「翌週」を左右するもの

flowchart TD
    A["何が動いているかを把握する"] --> B["新しい脆弱性情報を追う"]
    B --> C["修正前でも悪用の試みを検知する"]
    C --> D["修正が本当に動いているか確認する"]
    D --> E["証跡を残し報告する"]
    E --> A

1. 台帳ではなく、実際に稼働しているサーバーで把握する。 終了したキャンペーンサイト、忘れられたサブドメインの管理画面、PHPを内蔵する取引先の製品が見落としの典型です。シンガポールのCSAは、主サイトがPHPでなくても、サードパーティ製アプリがPHPを使っていないか確認するよう求めています。

2. 更新できない間の悪用の試みを検知する。 WizとJPCERT/CCは、ほぼ同じ初期の手がかりを挙げています。メモリ上限エラーやHTTP 500の前後に現れる不審なmultipart/form-dataリクエスト、レスポンスに含まれる異常に長い、または異常な形式のPHPSESSID Cookie、PHPワーカーの予期しない異常終了や頻繁な再起動です。Wizは、この種の欠陥はアプリケーション層より下で動くため、アプリのログには文脈が残りにくいと述べています。Webサーバーとプロセスのテレメトリが必要で、単一の検知ルールではすべての経路を捕捉できません。JPCERT/CCも、これらの痕跡がなくても攻撃を受けていないとは断定できないと明記しています。

3. 緩和策を修正と取り違えない。 PHPは暫定設定（たとえばsession.upload_progress.enabled=0やpost_max_sizeの制限）を案内していますが、特定の攻撃経路への対処にとどまり、更新のみが対策だとしています。PHP 8.1以前は修正版が提供されず、PHP 8.2も2026年12月31日にサポートが終了します。

4. 修正が本当に動いていることを確認する。 優秀なチームでもここでつまずきます。韓国のKISAは、PHPの実行環境をすべて再起動しない限り、古いバージョンがメモリ上で動き続けると警告しています。ディストリビューションのパッケージはバージョン番号を変えずに修正を取り込むことがあり、php -vだけでは判断できません。OpenAIのバージョン確認ツールも、バックポートされた修正が適用済みかどうかは確認できません。「修正済み」とは、修正されたコードが入っており、かつワーカーがその後に起動した状態を指します。

5. 証跡を残し、報告に備える。 侵害が疑われる場合、KISAは外部との接続を遮断し、再起動の前にログ、プロセス一覧、ネットワーク接続を保全するよう助言しています。再起動するとメモリ上の痕跡が消えるためです。顧客や監督当局から「何が、いつ起きたのか」と問われたとき、答えはログとケース記録にあります。

日本の読者の方へ

2026年10月21日の夜21時55分ごろ、首相がXで、当夜の対応を急ぐよう事業者に呼びかけたと報じられています（Safeguardの整理による）。IPAは同日の「事前準備のお願い」で稼働中のPHPの棚卸しを促し、22日の注意喚起では、古いサイトの扱いについて踏み込んだ助言をしています。更新・移行が終わるまで脆弱な状態で運用を放置せず、必要性、保守体制、予算を踏まえて、移行、機能縮小、公開終了まで検討するようにという内容です。

重大インフラの取引先として動いている会社には、別の観点があります。10月1日に施行されたサイバー対処能力強化法（能動的サイバー防御法）では、報告義務は特別社会基盤事業者にありますが、その報告に必要な事実は取引先の運用範囲やログに残ります。顧客から「御社の環境で同様の事案が起きたら、何時間で、何を、誰に報告できるか」と聞かれる場面が増えるでしょう。当社の能動的サイバー防御法と取引先の最初の30日の記事も参照してください。

本稿は一般的な技術・実務情報であり、法的助言ではありません。自社への適用は一次資料、顧客との契約、必要に応じて弁護士にご確認ください。

simpliSOCが現在できること、できないこと

存在するものを前提に計画していただきたいので、区別して示します。

現在提供している機能	現在は提供していないもの
Wazuh 4.xによる検知。9カテゴリ・50以上の独自ルールで、FortiGate（FW・VPN）、Windows AD・認証、VMware ESXi、Sysmon、脅威インテリジェンスのIOC照合、複数段階の相関検知に対応	PHPおよびWebサーバーのログ向けルールパック。Linuxサーバーなどの他のログソースには新しいデコーダーとルールが必要で、導入ごとに範囲を決めます
ルール単位のクールダウンによる重複アラートの抑制、ログ途絶の監視、重大度のマッピング	資産・バージョン台帳と、新しいCVEとの自動照合
メモ、資産、IOC、タイムライン、SLAタイマー付きのDFIR-IRISケース記録	再起動やバックポートの確認を含む、修正適用の検証
任意のShufflePlaybookと、任意のローカルLLMによるトリアージ補助（助言のみで、アラートを自動でクローズしません）	公的な報告様式への自動出力。24時間365日の分析官による監視は、本稿では約束していません

率直に言えば、simpliSOCにはPHP2Shell向けの検知パックは標準では含まれていません。基盤のWazuhはWebサーバーのログを取り込めますが、実際の作業はルールの作成と、お客様のトラフィックに合わせた調整です。

当社が検討を進めていること

以下はいずれも計画中のサービスであり、案件ごとに範囲を決めます。パッケージ化された製品ではありません。

simpliSOC向けのWeb層検知パック。 上記の公開されている手がかりをもとにしたWazuhルールを、導入の一部として提供し、お客様の実トラフィックで調整します。DFIR-IRISのケーステンプレートもあわせて用意します。

Exposure watch（露出の継続的な監視）。 稼働中のPHP実行環境、バージョン、主要設定を定期的に棚卸しし、新しい脆弱性情報と突き合わせます。さらに、バージョン文字列を鵜呑みにせず、ワーカーの最終再起動時刻やパッケージのchangelogにCVEが記載されているかを確認し、修正が本当に有効かを検証します。

お客様自身のコードに対するAI支援レビュー（人による検証付き）。 Intruderが公開している手法が全体像を示しています。入力点ごとにコードを切り出し、軽量モデルで絞り込み、重いモデルで悪用可能性を判定し、サンドボックスで実証します。Intruderはこの方法で、30万以上のユーザーを持つWordPressプラグインのSQLインジェクションを発見したと報告しています（BleepingComputer）。一方でOpenAIは、単純な指示ですべてのバグを見つけられるモデルはないとも述べています。当社が出すのは、開発者が再現できる証拠付きで、エンジニアが確認した報告であり、「AIがそう言った」だけのものではありません。

承認を前提とした是正。 ルール、WAF設定、構成修正、パッチのプルリクエストをエージェントが提案し、すべての実行は人が承認して記録します。これは当社のTier-1 SOCエージェントの記事で示した原則、つまり読み取り専用のツール、エージェントが覆せない重大度の上限、本番を変更する操作は人が行うことの延長にあります。

次に備えて、答えられるようにしておく7つの問い

1. Webトラフィックを受けているPHPの実行環境を、取引先製品や古いサイトも含めて1日以内に一覧化できますか。
2. 水曜の夜23時に、緊急パッチを承認して展開できる人は誰ですか。
3. Webサーバー、PHP-FPM、プロセスのログを検索できる場所に、どれだけの期間保存していますか。
4. パッチ後、ワーカーが再起動し修正が入っていることを、推測ではなくどう証明しますか。
5. 間に合わない場合、どのサービスを停止でき、誰が判断しますか。
6. 侵害が疑われる場合、再起動の前に証拠を保全する手順がありますか。
7. どの顧客や当局が時系列の説明を求め、ケース記録からそれを出せますか。

よくある質問

パッチを当てれば十分ではないですか。
パッチは必須ですが、それだけでは足りません。修正が出る前の期間と、「修正が出た」から「全環境で動いている」までの間に被害が起きやすく、どちらにも検知と検証が必要です。

当社はPHPを使っていません。影響はありますか。
間接的に受ける可能性があります。サードパーティ製アプリや取引先の機器がPHPを内蔵していることがあります。取引先のアドバイザリを確認し、実際に何が動いているかの棚卸しを行う機会にしてください。

simpliSOCは現在PHP2Shellを検知できますか。
標準では検知できません。PHPやWebサーバー向けのルールパックは含まれておらず、導入の一環としてお客様と範囲を決めて対応します。

AIによるコードレビューですべてのバグが見つかりますか。
いいえ。人間や従来のスキャナーが見逃すものを見つけることはありますが、誤検知も出ます。エンジニアの時間をどこに向けるかを絞る手段として使い、報告の前に必ず検証します。

これらの新サービスはすでに利用できますか。
計画中で、案件ごとに範囲を決めます。ご自身の環境に合いそうであれば、価格表ではなく、まず会話から始めてください。

24時間365日の監視は提供していますか。
本稿では約束していません。プラットフォームを超えた運用体制が必要な場合は、最初の相談でお知らせください。正直に範囲を検討します。

ご相談ください

次の2点をお知らせください。お使いのPHPのバージョンとホスティング（おおまかな一覧で構いません）、および、すでに収集しているログソースです。simpliSOCが現在検知できるものと、新たな開発が必要なものを分けた、カバレッジの評価をお返しします。hello@simplico.netまでご連絡ください。スタックの詳細はsimpliSOCのページ（英語）をご覧ください。

構築の背景はWazuh + IRIS-web で SOC をゼロから構築した実録に、また、創業パートナー募集：Wazuh・DFIR-IRIS・Shuffleで構築するオープンソースSOCもあわせてご覧ください。

参考資料

• PHPセキュリティアドバイザリ（php.net、英語）
• JPCERT/CC：JPCERT-AT-2026-0033
• IPA：PHPの脆弱性対策について（PHP2shell）
• Wiz Research：PHP2Shell（英語）
• The New Stack：AI found flaws in the code behind 70% of the web（英語）
• Safeguard：PHP2Shell in Asia（英語）
• BleepingComputer：Intruderの脆弱性自動発見パイプライン（英語）

2026年10月28日時点の内容です。状況は変化しているため、最新情報は各アドバイザリをご確認ください。