PHP2Shellの地獄：AIによってパッチ適用までの猶予が数日から数時間に短縮された理由

なぜこの時期になると、ホリデーシーズン直前に広範囲にわたる悪質なサイバーインシデントが発生するのでしょうか？セキュリティ専門家たちがようやくLog4J/Log4Shellの悪夢から解放されたと思った矢先、今度はPHPの重大な脆弱性が次々と発見され、大きな混乱を引き起こしています。10月21日、何百ものウェブサイトがオフラインになりました。これは攻撃者によるエクスプロイト（脆弱性攻撃）を受けたからではなく、技術チームがパッチの確認と適用を行う間、攻撃を防ぐために政府や企業、組織が自ら予防措置として停止させたものです。原因は、推定で

ウェブサイトの70%で使用されているプログラミング言語、PHPに潜んでいた2つの重大な欠陥でした。PHP2Shellとして知られるCVE-2026-109618およびCVE-2026-109619は、適切な条件下において、認証されていない攻撃者がサーバー上でリモートコード実行（RCE）を行うことを可能にするものでした。

バグ自体はPHPの基盤であるC言語に存在します。このインシデントの技術的な詳細を掘り下げるのは興味深いことですが、より重要なのは、このメモリ不足（OOM）バグが新しいものではないという点です。この問題は2004年に初めて指摘され、その後2019年、そして2024年にも再び浮上していました。そして何より注目すべきは、12年間優先順位が低かったこのOOMバグが、なぜ2026年の夏になって突然、PHP Foundationのセキュリティチームにとって最優先事項となったのかという点です。

一体何が起きたのでしょうか？それは、AIモデルの登場です。

AIは、バグの発見から悪用までの期間を劇的に短縮しました

これらのバグを悪用するのは容易ではありません。これらの欠陥を組み合わせて攻撃ベクトルを構築するには、PHPがリクエスト間でどのようにメモリを割り当て、再利用するかについての深い理解が必要です。経験豊富なセキュリティ研究者なら誰もが知っている通り、仕事の中で最も難しいのは影響を証明することです。到達不可能なバグは悪用できず、悪用できないバグは、リソースが限られ、バックログが山積している技術チームにとって、修正を優先させるための十分な緊急性を生み出しません。

これらのバグが長年放置されてきたのは、誰も悪用方法を見つけられなかったからです。また、修正が複雑であり、後方互換性、サービス拒否（DoS）攻撃の可能性、そして調整が困難なサードパーティ製拡張機能の変更といった深刻なトレードオフを伴うため、2024年の修正の試みは停滞していました。このシナリオは、セキュリティ上の発見をトリアージするチームであれば誰しも見覚えがあるはずです。修正コストが高い理論上の問題は、明確で実証済みの影響を持つ問題に負けてしまう傾向があるのです。

しかし、この夏、PHPプロジェクトがOpenAIの「Patch the Planet」プログラムに追加されたことで状況が一変しました。AIを活用したPHPの新たなセキュリティ監査は、バグを露呈させただけでなく、修正を優先させるために必要な実用的なエクスプロイトの概念実証（PoC）まで作成しました。Califのタイムラインによると、バグへの道筋を発見してからPHP Foundationに実用的な概念実証（PoC）を提出するまで、わずか2週間足らずでした。Wizはその報告書の中で、何が決定的な違いを生んだのかを明確に指摘しています。「最先端のAIモデルと適切なツールがあれば、一人の研究者が、以前なら世界クラスのチームが数ヶ月かけて行う作業をわずか1週間で完了できる」

この脆弱性の概要

PHPのリクエストがメモリ不足に陥ると、PHPは即座にリクエストを停止します。この突然の停止により、メモリのクリーンアップ手順がスキップされ、解放後使用（Use After Free）というメモリ破損の脆弱性が生じます。タイミングが悪いと、PHPは初期化が不完全な内部データを残したままそれを有効なものとして扱ったり、メモリを破損させたり、あるいは前のリクエストのメモリを指し示す内部状態を残したりする可能性があります。

これら2つのバグを実用的な攻撃に転換するのは複雑な作業でした。以下の手順が必要となります：

• 深くネストされたフォームフィールドを持つ小さなリクエストを使用して、PHPがリクエストサイズよりもはるかに多くのメモリを割り当てるように仕向け、特定のポイントでメモリ不足エラーを強制的に発生させる（Calif）
• 攻撃者が制御するデータが解放されたメモリ領域に配置されるように調整し、PHPがそれを自身の内部構造として読み込ませる（Calif）
• 一部の攻撃チェーンでは、2つ目の欠陥を使用してメモリの内容を漏洩させ、アドレスの場所を特定することで、アドレスのランダム化を無効化する（Wiz）

このエクスプロイトの技術的な詳細を理解したい方は、PHP2Shellの仕組みをステップバイステップで解説した公開ウォークスルーをご覧ください：[今すぐ再生]

新しい世界：リアルタイムで監視される攻撃の試み

AIの恩恵を受けているのがセキュリティ研究者や技術チームだけなら良かったのですが、そうではありません。PHP2Shellのインシデントは、攻撃者が開示情報やパッチをエクスプロイトに変換するスピードがどれほど劇的に向上したかを目の当たりにした最初の事例です。AWSやCloudflareのような組織は事前に情報を得ていたため、顧客ベース全体で攻撃の試みを監視することができました。また、PHPは推定でウェブサイトの70%で使用されていると特定できるため、PHP2Shellの攻撃対象領域は非常に広大です。

• Cloudflareは、PHP2Shellが公表される前の10時間で、数千件もの攻撃の試みを観測しました。発表から24時間も経たないうちに、同社は数百万件もの攻撃の試みを追跡していました。
• Amazonの脅威インテリジェンスは、公開開示の4日前である10月17日にPHP2Shellの攻撃の試みを特定しました。パッチがリリースされてから数時間以内に、AWSは「広範囲にわたる攻撃の試み」を確認したと報告しています。

これは、チームがもはや30日、あるいは7日といったパッチ適用や緩和のタイムラインを当てにできないことを示しています。重大な脆弱性に対しては、AIの活用により、そのタイムラインは数時間にまで短縮されているのです。

結論

技術チームおよびセキュリティチームは、2つの前提を見直す必要があります。

第一に、「既知の脆弱性なし」という言葉は、かつてほどの安心材料にはなりません。AIツールの普及により、攻撃コードを作成するコストが劇的に低下したためです。かつては理論上のみとされていた脆弱性も、今や再評価が必要です。コード作成が容易になったことで、攻撃の実行もまた容易になっているのです。

第二に、修正に数週間を要する現状では、数時間で攻撃を仕掛けてくる脅威に対抗できず、投資対効果（ROI）の計算が根本から覆ります。今や、事前の予防こそが最善のリスク軽減策です。もしチームがパッチ未適用の古いPHPバージョンでアプリケーションを運用しているなら、アップデートの際に深刻な問題に直面する可能性があります。技術的負債は今や重大なセキュリティリスクであり、AIを活用した攻撃者の能力向上に伴い、この傾向は今後も続くと考えるべきでしょう。PHPはインターネットのサーバーインフラの大部分を支えているため、パッチの展開は極めて困難な作業になると予想されます。影響を受けるのはWebアプリケーションだけではありません。アプライアンス製品やインターネットに接続されたあらゆるシステムや製品が巻き込まれる可能性があり、セキュリティ担当者にとっては長期的な悩みの種となるでしょう。チームは既知の重大な脆弱性に対処するだけでなく、人間が書いたコードかAI生成コードかを問わず、ソフトウェア開発のあらゆる側面において「セキュリティ・ファースト」の姿勢で臨むことが不可欠です。[PLAY THE CHALLENGE][SPEAK TO AN EXPERT]