Posted By ,

GitHub「php2shell」リポジトリ分析：PHP 脆弱性の公開直後に広がった PoC と防御ツール

概要

2026年10月21日に PHP の脆弱性 CVE-2026-109618 および CVE-2026-109619 が公開された直後、コード共有プラットフォームの GitHub で、「php2shell」という名前を使ったリポジトリが短期間に多数作成された。「php2shell」の検索結果上位100件のリポジトリ（フォークを除く）のうち、99件がこれらの脆弱性を扱っており、ほぼすべてが10月21日の1日で作成されていた。

PHP の公式発表によると、CVE-2026-109618 は、メモリ不足時の処理で、リクエストデータが一部しか初期化されていないままクリーンアップ処理が行われることで発生する。一方、CVE-2026-109619 は、メモリの解放後もリクエストに属する内部状態が残り、同じワーカープロセスが後続のリクエストでその古い状態を使用することで発生する。いずれも認証なしでのリモートコード実行につながるおそれがあり、CVSS v4.0 のスコアは9.2とされている。特に mod_php 環境でリスクが最も高い（PHP 公式発表）。一方、GitHub のリポジトリでは、session.upload_progress 機能が攻撃経路として挙げられ、PHP 5.4以降ではデフォルトで有効になっていると説明されている。ただし、これらの記述はリポジトリの説明に基づくものであり、本調査では公式発表による裏付けを確認できていない。

セキュリティ企業の watchTowr は、10月21日時点で、自社のハニーポットネットワークにおいて実際の悪用を観測したと発表した。また、PHP 5以降のすべてのバージョンが影響を受ける可能性があると報告する一方、この影響範囲は公式には確認されていないとしている。同社の FAQ が作成された時点では、これらの脆弱性は CISA の既知の悪用された脆弱性カタログ（KEV）に登録されていなかった（watchTowr FAQ）。

脅威インテリジェンスの観点では、公開 PoC が広がる規模や速度に加え、その信頼性にも目を向ける必要がある。攻撃コードと防御ツールが同じ時期に公開されたものの、両者に寄せられた関心には大きな差があり、出所を確認しにくいコードも多数含まれていた。

脅威分析

分析対象は、2026年10月22日13時30分に収集したリポジトリの一覧だ。一覧に記録された最終活動日時のうち、最も新しいものは10月21日16時27分（UTC）だった。リポジトリ名、説明、トピックに基づいて用途を分類しており、コード自体は直接確認していない。

用途別では、脆弱性チェック、緩和、検知を目的とする防御関連のリポジトリが46件、PoC や攻撃を再現する検証環境などの攻撃関連のリポジトリが36件だった。しかし、ユーザーの関心は攻撃関連に集中していた。GitHub でユーザーの関心を示すスターは、分析対象全体で1,394件だった。このうち約83%に当たる1,158件が PoC のリポジトリに付けられていたのに対し、防御関連のリポジトリは合計148件にとどまった（図 1）。スター数上位の ikow/php2shell-poc（617件）と eness の PoC リポジトリ（333件）の2件で全体の約68%を占め、上位5件では約81%に達した。上位10件を除く90件のリポジトリには、ほとんど関心が集まっていなかった。

スター数上位10件のうち5件が PoC で、防御関連では Apache 向けの緊急遮断ツール、upload-progress ハンドラーを無効化する PHP 拡張機能、オランダ国家サイバーセキュリティセンター（NCSC-NL）の運用情報リポジトリが含まれていた。

 

図 1. 用途別のリポジトリ数とスターの分布

 

作成時期を見ると、防御関連のリポジトリが先に登場していた。最も早い関連リポジトリは、10月18日06時43分（UTC）に作成された Corelight の検知ルールだった。PoC では、10月20日19時16分（UTC）に作成されたリポジトリが最も早かった。その後、10月21日の午後にかけて PoC の作成が増え、15時台（UTC、日本時間では22日0時台）にピークを迎えた（図 2）。

図 2. 時間帯別のリポジトリ作成件数の推移（UTC）

 

NCSC-NL、Corelight、syhunt、openai の各アカウントのリポジトリなど、機関や企業が直接参加した事例も確認された。プログラミング言語は Python が47件、Shell が24件と大半を占めていた。PoC や脆弱性チェックツールは主に Python、サーバー向けの緩和スクリプトは主に Shell で作成されていた。

ライセンスが指定されていないリポジトリは51件と、半数を超えていた。説明の多くは英語だったが、中国語、フランス語、ロシア語、ポルトガル語、スペイン語、オランダ語で書かれたものもあり、複数の国で同時に対応が進められたと考えられる。韓国語で書かれたリポジトリは確認されなかった。

公開コードの信頼性には注意が必要だ。PoC のリポジトリ27件のうち21件はスターが10件未満で、分析対象全体でも61件はスターが1件以下だった。説明のないリポジトリは29件、プログラミング言語の情報がないものは11件あり、これらは中身が空か、文書のみが置かれている可能性がある。先にリポジトリ名を確保し、後からコードを追加するケースもあるため、現時点の情報だけで安全性を判断することは難しい。

公開 PoC が実際に動作するかどうかも明らかではない。リモートコード実行が可能だと主張するリポジトリがある一方、リモートコード実行ではなく、内部状態が破損する不具合のみを再現したと説明するものや、再現に失敗した記録を残しているものもある。

あるリポジトリでは、説明が ikow/php2shell-poc と完全に一致していた。人気リポジトリを複製し、コードを変更して配布する手法が使われた可能性がある。注目を集める CVE に便乗し、偽の PoC に悪意のあるコードを仕込んでセキュリティ研究者を狙う事例は、過去にも繰り返し確認されている。

防御を目的とするツールも、リスクになり得る。一部の緩和スクリプトは「1行のコマンドですべての PHP 環境に適用できる」として配布されているが、root 権限で実行されるため、セキュリティツールを装った攻撃経路として悪用されるおそれがある。また、AI で作成しており、動作を保証しないと明記したツールも確認された。

 

対応と考察

根本的な対策は、PHP を修正バージョンにアップデートすることだ。PHP は10月21日にセキュリティリリースを公開し、公式発表では速やかなアップデートが最も確実な対策だとしている。運用担当者が取るべき対応は以下のとおりだ。

 

1.    PHP のバージョン確認とパッチ適用: 資産ごとに稼働中の PHP バージョンを把握し、各バージョン系列の修正版である8.5.12、8.4.27、8.3.36、8.2.35へアップデートする。8.2系列は2026年12月31日にサポートが終了する。ディストリビューションや長期サポート（LTS）の提供元には事前にパッチが提供されているため、まずパッケージの更新状況を確認し、リスクが最も高い mod_php 環境を優先して対応する。ダウンロードと変更履歴は PHP 公式サイトで確認できる（ダウンロード）。

2.  PHP 8.1以前のバージョンへの対応: 公式の修正リリースは提供されない。PHP セキュリティチームは、7.4、8.0、8.1向けに必要最小限の修正をバックポートしたブランチをソースコードリポジトリで公開しているため、ソースからビルドする環境では利用を検討できる。ただし、基本的にはサポート対象バージョンへ移行するか、LTS の提供元がバックポートを提供しているか確認する必要がある。

3.    一時的な遮断: 直ちにパッチを適用できないサーバーでは、session.upload_progress.enabled を Off に設定し、対象となる攻撃経路を一時的に制限する。この設定はファイルアップロードの進捗表示機能を無効にするため、その機能を使うサービスへの影響を事前に確認する必要がある。PHP の公式発表では、緩和策は一部の攻撃経路のリスクを軽減するにすぎず、システムの安全性を確保するものではないとしている。この設定をパッチの代わりにすることはできない。

4.    Web アプリケーションファイアウォールのルール適用: 不審な multipart リクエストを遮断するルールは、誤検知が発生しないか検証したうえで本番環境に適用する。

5.    検知ルールの活用: Corelight の Zeek・Suricata ルールや NCSC-NL の運用情報など、機関やセキュリティベンダーが提供する資料を優先して参照する。

6.    開コードの取り扱い: PoC や脆弱性チェックツールを使用する場合は、コードを直接確認して処理内容を把握したうえで、隔離された環境でのみ実行する。

 

パッチ適用前にインターネットに公開されていたサーバーについては、侵害の有無も調査する必要がある。watchTowr が10月21日に実際の悪用を観測したと発表しているため、アップデート前に公開されていたサーバーが侵害された可能性は否定できない。Web サーバーのログで異常な multipart リクエストを確認するとともに、Web ルートなどに不審なファイルが作成されていないか、Web サーバー用アカウントで異常なプロセスが実行されていないかを調べる。侵害の兆候が確認された場合は、証拠を保全したうえで、デジタルフォレンジックとインシデント対応（DFIR）の手順に沿って調査を進める。

韓国国内の機関は、韓国インターネット振興院（KISA）のインターネット侵害対応センターにインシデントを届け出る。個人情報の漏えいが確認された場合は、韓国の個人情報保護法に従い、個人情報保護委員会または KISA への届出と、本人への通知を行う必要がある。今回の事例では、脆弱性の公開後わずか1日で約100件の関連リポジトリが作成された一方、防御ツールに対する関心は相対的に低かった。また、動作するかどうかが不明な PoC や、出所が明確でないコードも多く含まれていた。

そのため、公式アドバイザリや信頼できる機関の資料を優先して確認し、未検証のリポジトリのコードは実行しないという方針を、組織内で共有する必要がある。

 

パッチおよび参考リンク

 

関連 IOC および詳細な解析情報は、AhnLab の次世代脅威インテリジェンスプラットフォーム 「AhnLab TIP」 サブスクリプションサービスを通して確認できる。

Categories: 脆弱性

Tagged as: ,