2026年10月23日金曜日

Webの7割が当事者になった夜。総理も警告したPHP2Shellの正体 - - YouTube動画の紹介と、解説、その他

Webの7割が当事者になった夜。総理も警告したPHP2Shellの正体

IT技術屋のボヤキ
チャンネル登録者数 1.8万人
37,522回視聴 2026/10/22 IT技術屋のボヤキ
2026年10月21日の夜、高市総理がXで「今夜のパッチに備えてください」と呼びかける異例の事態が起きました。 PHPの重大脆弱性PHP2Shell。 掲示板への匿名リークでエンバーゴが崩れ、オランダは政府サイトを予防停止、日本は総理が国民に注意喚起。 Webの7割を支える言語に何が起きたのか、そして総理の投稿で一番見過ごされている1行は何か。昨夜の騒動を追いかけます。 X（旧Twitter）でも配信情報や小ネタを発信中！ フォローはこちら → https://x.com/IT_BOYAKI @IT_BOYAKI 【目次】 00:00 オープニング 00:52 第1章 計画が崩れた瞬間 02:23 第2章 9.2が2つ、穴の中身 03:50 第3章 なぜ総理が動く規模なのか 05:08 第4章 パッチを待たずに止めた国 06:45 最終章 一番見過ごされている1行 #IT_BOYAKI #PHP #脆弱性 #セキュリティ #PHP2Shell #サイバーセキュリティ #エンジニア #プログラミング #ITエンジニア #インフラ #Web開発 #WordPress #情報セキュリティ #IT業界 #ソフトウェア #技術解説 #プログラマー #開発者 #AI #Copilot 音声: VOICEVOX:春日部つむぎ / VOICEVOX:雨晴はう
ポッドキャストを検索
IT技術屋のボヤキ
エピソード数: 238
IT技術屋のボヤキ
IT技術屋のボヤキ
この動画は、単なる「PHPに脆弱性がありました」というニュースではなく、
「なぜ世界中が数時間で大騒ぎになったのか」
を時系列で解説した内容です。 実際、Reutersや各国の政府機関の発表を見ると、動画で説明されている流れとほぼ一致しています。Reuters

第1章 「エンバーゴ」が破られた

この動画で一番面白いのがここです。

エンバーゴとは？

IT業界では重大な脆弱性が見つかると、 
研究者
 ↓
ソフトウェア開発者
 ↓
修正版を作る
 ↓
公開日時を決める
 ↓
みんな同時公開
という流れになります。 これを Coordinated Vulnerability Disclosure（協調的脆弱性公開） と言います。 つまり
「まだ直ってないから秘密にしておこう」
という約束です。

今回はそれが崩れた

ところが、
  • Hacker Newsへの投稿
  • SNSでの拡散
  • 誤って公開されたPoC動画
などにより、正式公開前に情報が広まりました。PHPチームは予定を前倒しして緊急公開に切り替えています。Huntress 業界では
「エンバーゴ破り」
はかなり重大な出来事です。

第2章 なぜCVSS9.2なのか

CVSSは 
0～3
低

4～6
中

7～8
高

9以上
Critical
です。 今回は 
9.2

しかも2件
でした。 これだけでも十分異常ですが、 さらに怖いのは 認証不要（Unauthenticated） だったことです。 つまり 
ログイン不要

↓

URLへアクセス

↓

攻撃成立
という可能性があるため、危険度が非常に高く評価されました。watchTowr

第3章 「Webの7割」が意味するもの

動画で
Webの7割
と言っています。 これは PHPの市場シェアのことです。 PHPは
  • WordPress
  • Laravel
  • Drupal
  • MediaWiki
  • phpMyAdmin
など非常に多くのソフトウェアの基盤になっています。 つまり 
WordPressだけ危険

×

PHP全部
なのです。 だから 
世界中

↓

数千万サイト

↓

一斉アップデート
という事態になりました。Huntress

第4章 オランダがサイトを止めた理由

一般人から見ると
パッチが出るまで待てば？
と思うかもしれません。 しかし、 
脆弱性が公開

↓

攻撃コードも出回る

↓

パッチはまだ適用できていない
この数時間が最も危険です。 だから一部の政府機関は 
サービス停止

↓

アップデート

↓

再開
を選びました。 セキュリティでは Availability（可用性） より Integrity（完全性） を優先した判断です。Reuters

高市総理が投稿した意味

動画でも強調されていました。 日本では 総理大臣が 
PHPを更新してください
と呼びかけるのは極めて異例です。 普通なら 
JPCERT

IPA

デジタル庁
あたりが発信します。 今回は 政府レベルで 「国のITインフラ全体に影響する」 と判断されたため、首相自ら注意喚起を行ったと受け止められています。Reuters

「一番見過ごされている1行」

動画では最後に
「パッチを当てて終わりではない」
という話が出てきます。 実はこれが現場では一番重要です。 アップデートしたら 
終わり
ではなく 
攻撃されていないか

↓

ログを見る

↓

侵入されてないか調査
ここまでやります。 攻撃者は 公開直後から 
自動スキャン

↓

攻撃

↓

WebShell設置
を行います。 もし 
攻撃

↓

その後パッチ
だった場合、 侵入されたまま最新版 という最悪の状態になります。

業界では「Log4Shell以来」と言われる理由

この動画を見ていて、多くのエンジニアが思い出したのが Log4Shell（2021年） です。 共通点があります。
Log4Shell PHP2Shell
世界中が使用 世界中が使用
RCE RCE
緊急アップデート 緊急アップデート
一斉メンテ 一斉メンテ
政府も警告 政府も警告
だから 業界では
「PHP版Log4Shell」
と呼ぶ人もいます。

エンジニアあるある

動画を見たPHPエンジニアは、 たぶんこんな一日だったでしょう。 
朝

「今日も平和だな」

↓

昼

「PHPにCritical？」

↓

夕方

「今日リリース予定だったんだけど…」

↓

夜

緊急メンテ

↓

深夜

アップデート

↓

翌朝

ログ確認
実際、多くの企業が夜間や深夜に緊急メンテナンスを実施し、Cloudflareなどは公開直後から攻撃試行が急増したことを報告しています。Reuters

この動画の本当のメッセージ

この動画が一番伝えたかったことは、 「セキュリティ対策は、アプリケーションのコードだけでは不十分」という現実です。 多くの開発者はSQLインジェクションやXSSのような「自分のコードの安全性」を意識します。しかし今回は、アプリケーションが正しく書かれていても、PHPランタイム自体の欠陥によって危険になるケースでした。だからこそ、OS・Webサーバー・PHP・ライブラリ・フレームワークまで含めて継続的に更新する「運用」が、ソフトウェア開発と同じくらい重要なのです。 この事件は、「安全なコードを書く」だけでなく、「安全な実行環境を維持する」ことの重要性を、Web業界全体に改めて突きつけた出来事と言えるでしょう。
 

2026年10月21日の夜、世界中のWebエンジニアやインフラ担当者の胃をキリキリさせ、日本の総理大臣までをも動かした大騒動「PHP2Shell」。

この事件は、単なる「よくあるソフトウェアのバグ」の枠を大きく超え、現代のインターネット構造が抱える根深い問題や、ITの歴史的背景を浮き彫りにする象徴的な出来事となりました。動画の解説をベースに、いくつかの雑学や業界話を交えながら、今回の騒動の裏側を紐解いていきます。

1. 「個人ホームページのアクセスカウンター」が、32年後に世界を揺るがすまで

今回の主役であるプログラミング言語「PHP」ですが、そのルーツは非常にユーモラスです。 1994年、カナダのプログラマであるラスマス・ラードフ（Rasmus Lerdorf）氏が、自分のオンライン履歴書を見る人がどれくらいいるのかを調べるために、「自分のホームページ用」に自作した極めてプライベートなツール、それがPHPの原型でした。当時、名前もそのまま「Personal Home Page Tools」という、言ってしまえば個人の趣味の延長のようなシロモノでした。

それが32年後の現在、世界のWebサイトの約7割、WordPressに至っては全Webの4割以上を支える巨大インフラに成長しています。「まさか自分の履歴書カウンターが、数十年後に一国の首相に『パッチを当てろ』と言わせることになるとは」、生みの親のラスマス氏も夢にも思わなかったはずです。

2. 「エンバーゴ（禁解禁）」を崩壊させた、掲示板の爆弾

セキュリティの世界には、脆弱性が見つかった際、パッチ（修正プログラム）が準備されるまで公表を控え、関係者間で秘密裏に対策を進める「エンバーゴ（Embargo / 禁解禁）」という不文律のルールがあります。

しかし今回は、公開予定日の直前に海外のエンジニア向け掲示板「Hacker News」に「重大な脆弱性が2件来る」という匿名リークが投下されてしまいました。「どうせオカルトだろ」と思いきや、セキュリティ企業が「情報は本物だ」と認めてしまったことで事態が一気に加速。 攻撃者にとって脆弱性の修正パッチやその差分コードは、いわば「最高の攻め方の教科書（答え合わせ）」です。修正版が出た瞬間から自動攻撃スクリプトが走り出すため、今回は「公開の15分で大規​​模攻撃が始まる」と予測されるほどの時間との戦いでした。だからこそ、オランダの国家サイバーセキュリティセンターをはじめ、各国が「直すより先にまずサイトを止める（予防停止）」という、行政としては異例の防衛策をとらざるを得なかったわけです。

3. 総理の投稿で見過ごされがちな「一番痛い1行」

今回の高市総理のXでの呼びかけで、多くの人が「総理がパッチなんて言葉を使った！」という驚きに目を奪われましたが、本当に恐ろしいのは、投稿に含まれていた「公開しているWebサイトでPHPを使用しているか確認し…」という一文でした。

IT業界の「あるある」であり、最大の闇がここにあります。

  • 「10年前に外注したキャンペーンサイト、どこにソースコードあるっけ？」

  • 「退職した担当者が突貫工事で作った社内予約フォーム、まだ動いてる？」

  • 「M&Aで買収した子会社のサーバー、全容を把握している人は社内にいる？」

いざ重大な脆弱性が出て「今すぐパッチを当てろ」「止めろ」と言われたとき、「そもそも自社がネット上に何を公開しているか（IT資産台帳）が正確にわからない」「夜間にシステムを止める決裁権を誰が持っているかわからない」という組織があまりにも多いのです。 技術的な対策以上に、「自社のシステムを自分たちが把握しきれていない」というガバナンスや資産管理のツケが、一斉に露呈した夜でもありました。

今回のPHP2Shell騒動は、穴そのものの脅威はもちろんですが、「インターネットの巨大化・陳腐化したレガシー」「情報管理の甘さ」「AIによってさらに加速する攻撃のスピード」という、現代IT社会が抱える構造的な課題を私たちに突きつける強烈な事件となりました。

  • 今回のPHP2Shellの技術的な仕組み（メモリ枯渇やUse-After-Freeなど）について、さらに詳しく知りたいですか？

  • ご自身の管理されているシステムや環境で、似たようなセキュリティインシデントへの対策について気になっていることはありますか？

 

PHP2Shell（CVE-2026-109618 / CVE-2026-109619） は、2026年10月21日に緊急パッチが出たPHP本体の重大なリモートコード実行（RCE）脆弱性2件の通称です。動画のタイトル通り「Webの7割が当事者になった夜」で、高市総理がXで直接注意喚起する異例の事態になりました。

何が起きたのか（動画の流れに沿って）

PHPはWebの約70%を支える言語です。WordPress、Drupal、Laravel、Magento、社内システム、官公庁サイトまで、ほぼどこでも動いています。問題はアプリケーション側ではなくPHPエンジンそのものにありました。認証なしで、普通のHTTPリクエスト1発（特にmultipartのファイルアップロード系）でサーバー上で任意コードが走ってしまう可能性がある、というものです。

  • CVE-2026-109618：Out-of-Memory（メモリ不足）時の処理のバグ。PHPがlongjmp()でリクエストを中断する際、半分初期化されたメモリを「有効」として扱ってしまう。攻撃者が意図的にメモリを食いつぶすmultipartリクエストを送ると、クリーンアップ時に制御を奪える。
  • CVE-2026-109619：リクエスト間で残るグローバル状態（セッションやオブジェクト関連）が、解放済みメモリを指したままになるuse-after-free。次のリクエストでその「死んだ」メモリを悪用できる。

両方ともCVSS v4.0で9.2（Critical）。mod_phpが特に危険とされ、アプリケーションコードが動く前に攻撃が成立するケースもあるとされています。

発見は2026年8月。カリフォルニアのセキュリティ会社CalifのRyan Austin氏がOpenAIの「Patch the Planet」プロジェクトで、GPT系モデルを使って見つけたのが一つ。もう一つはWiz（Google Cloud傘下）がGeminiや自社ツールで独立発見。AIが「人間には現実的に難しかった複雑なチェーン」を短期間で突破した典型例です。もともとメモリ周りの扱いに古い癖があったらしいのですが、AIが「ここをこう繋げばRCEになる」と示してしまった形です。

予定は10月22日エンバーゴだったのが、10月20日に掲示板やHacker NewsなどでCVE番号が漏洩。計画が崩れて公開が1日前倒しになりました。動画の第1章「計画が崩れた瞬間」がこれです。オランダは政府サイトを予防的に停止、日本では国家サイバー統括室が高市総理まで動かして「今夜のパッチに備えてください。当てられないなら一時停止も有効」と呼びかけました。pixiv、DMM、niconico、BASE、コドモンなど多くの国内サービスが緊急メンテに入りました。

パッチは10月21日14:00 UTC頃にPHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35として公開。8.1以前はEOLで公式バイナリなし（ソースパッチのみ）。一時的な緩和策（session.upload_progress.enabled=0など）は出ましたが、公式は「完全な緩和策はなく、更新だけが安全」と明言しています。

業界話・雑学的なポイント

  • AI発見の波紋：OpenAIやWizがAIを使って見つけたことが強調されています。従来「人間には無理に近い複雑さ」だったものをAIが現実的な時間で突破した例として、セキュリティ業界で「これからの発見速度が変わる」と話題になりました。Wizは「ソフトウェア史上でも最悪クラスの一つ」とまで言っています。
  • 漏洩と前倒し：エンバーゴ破りは珍しくありませんが、今回は政府レベルまで動いた規模感が異例。Amazonのhoneypot（MadPot）では10月17日（開示4日前）にすでに試行が観測されていたという報告もあり、情報がかなり早く出回っていた可能性が指摘されています。
  • 総理の投稿で見過ごされがちな1行：動画が最終章で強調している部分ですが、高市総理の投稿には「修正パッチを速やかに適用することが困難な場合は、ウェブサイト等を一時的に停止させることも有効策の一つ」とあります。技術者視点では「当たり前」でも、経営層・非エンジニアに「止めてもいい」と総理が言ったことで、意思決定のハードルが一気に下がった、という評価が国内エンジニアから出ています。実際、多くの企業がその夜に停止を選択しました。
  • 暴露規模：Palo Altoなどによるとインターネット上で2200万台超の潜在的に脆弱なPHPインスタンスが確認されたという数字もあり、影響範囲の広さが改めて浮き彫りになりました。EOLの古いPHPがまだ大量に動いている現実も痛感させられます。
  • 余談：高市総理は2018年にPHP研究所から『サイバー攻撃から暮らしを守れ！』という本を出していた、というトリビアも出回っています。名前の「PHP」はもちろん全く別組織ですが、タイミングが絶妙でした。

今どうすべきか

サポートされている8.2〜8.5なら即アップデートしてワーカーを再起動し、実際に動いているバージョンを確認。EOLならソースパッチを当てるか、可能ならアップグレードを検討。WAFは一部のベクトルを軽減できますが完全ではない、という報告もあります。

動画は「昨夜の騒動を追いかける」形式で、漏洩→規模の大きさ→各国の対応→総理投稿のポイント、と時系列で整理しています。技術的な詳細より「なぜここまで大騒ぎになったのか」を重視した内容です。業界的には「AI時代の脆弱性発見＋漏洩＋政府介入」の象徴的な一夜として、しばらく語られることになりそうです。

動画の概要欄と、昨夜から今朝にかけての報道をつなげて解説します。動画本編は見られないので、中身は概要欄と各社の記事からの推測を含みます。

何が起きたのか

PHPのセキュリティチームは10月20日、2件の重大脆弱性を修正する特別リリースを翌21日14時（協定世界時、日本時間23時）に公開すると予告しました。識別番号はCVE-2026-109618とCVE-2026-109619で、通称が「php2shell」です。公式の評価はCVSS v4.0で9.2で、最高区分の「緊急」に当たります。動画の第2章「9.2が2つ」はこのことでしょう。 【高市総理も注意喚起】インターネット崩壊危機？PHP重大脆弱性でWebサイト緊急停止 世界のWebサイトの約7割で利用、国内サービスも緊急メンテナンス｜ビジネス+IT +2

中身はどちらもメモリ管理の欠陥です。

  • 109618:メモリ不足の処理の途中でメモリが壊れる問題 isotop
  • 109619:前のリクエストの状態が残ったまま次へ進み、解放済みメモリを参照してしまう、use-after-free（UAF）と呼ばれる欠陥 isotop

雑学：なぜメモリ系のバグは怖いのか

PHPは「スクリプト言語だから安全」と思われがちですが、PHP本体はC言語で書かれています。メモリ安全でないCのコードに穴があれば、PHPで書かれたアプリがどれだけ丁寧でも関係なく突破されます。

UAFは、すでに片付けた（解放した）メモリの場所を、うっかり使い続けてしまうバグです。片付けた場所に攻撃者が自分のデータを置き直せると、プログラムを乗っ取る足がかりになります。近年の研究では、悪用されやすいメモリ関連の脆弱性の筆頭格とされています。ブラウザやOSカーネルの脆弱性でも定番の型です。 isotop

PHPはもともと1994年にRasmus Lerdorfが作った小さなツール群で、名前は「Personal Home Page Tools」でした。今は「PHP: Hypertext Preprocessor」という、自分自身を含む再帰的な略称になっています。30年かけて肥大化した巨大な基盤に、今回のような古典的な穴が見つかったわけです。

業界話①：「Webの7割」は本当か

数字は盛られていません。W3Techsの2026年10月の集計では、サーバー側言語を判別できたサイトの69.3％がPHPです。理由は簡単で、WordPressがPHP製だからです。個人ブログから企業サイト、レンタルサーバーの無料ホームページまで、日本のWebの裏側はPHPだらけです。 yahoo

ただし、全部が一撃で落ちるわけではありません。PHP-FPMなどでは別の条件が必要で、実際の危険性は構成や稼働中のアプリによって変わります。確認された悪用の再現環境も、Apacheのmod_phpでmemory_limitを初期値のままにした構成でした。「7割が当事者」と「7割が即死」は別の話で、このあたりは動画でも切り分けて語られているかもしれません。 yahooisotop

業界話②：エンバーゴ崩壊の痛み

重大な脆弱性は、パッチの準備ができるまで詳細を伏せ、公開日時を決めて一斉にリリースするのが通例です。これがエンバーゴ（解禁日までの情報統制）です。今回は修正版の公開前に情報が流出し、攻撃の試みも観測されたとされています。攻撃者が先に動けるので、防御側にとっては最悪の展開です。 isotop

似た構図の事件は過去にもあります。2021年末のLog4Shell（CVSS 10.0）では、公開直後に世界中で攻撃が爆発し、年末年始のインフラ担当者が総出で対応しました。今回は「パッチ公開の1時間前に首相が準備を呼びかける」という点が新しく、IT業界の人間が「そこまで来たか」とざわついた理由でもあります。

業界話③：なぜ総理の投稿が刺さるのか

首相がXで個別のソフトウェアの脆弱性に触れるのは異例で、エンジニアからは「総理が発信したことにより、経営層にもリスクが認知される」という評価が出ています。現場の本音としては、「パッチ当てたいけど止められません」を上に説明する難しさがあります。J-CASTには「『総理大臣から緊急要請が出ています』と言えば…」という現場技術者の反応が載っていました。情シスが何ヶ月も説得してきた稟議が、一夜で通るわけです。 yahooyahoo

海外の動きも報じられています。FBIも警告を発し、欧州では政府機関や公共サービスのサイトを予防的に停止する動きが広がっています。動画にあるオランダの政府サイト停止はこの流れでしょう。「パッチを待たずに止める」判断は、可用性を最優先にしがちなシステム運用の常識を、セキュリティ側に寄せたものです。 epochtimes

「一番見過ごされている1行」の予想

動画の中身は確認できないので推測です。報道を見る限り、有力なのはこの1行です。

首相は、修正パッチの即時適用が難しい場合には、サイトを一時停止することもリスク低減の有効策だと説明しています。 inatei

「パッチを当てろ」より「当てられないなら止めてよい」と国のトップが言ったことのほうが重いと思います。止める判断は現場だけでは下しにくく、これが免罪符になります。国内でも54の会社や団体が停止や緊急メンテナンスを告知したと報じられ、ニコニコ、pixiv、さくらインターネットなども緊急メンテナンスに入りました。実際にそう動いた組織が多かったことになります。 isotopyahoo

運営している人がやること

  • 更新先:修正版は8.2.35、8.3.36、8.4.27、8.5.12です。自分のPHPのメジャーバージョンに合うものを確認してください。 isotop
  • レンタルサーバー利用の場合:PHPの更新は事業者側で行われることが多いので、告知を確認してください。
  • WordPressなど:CMS本体やプラグインの更新とは別に、サーバー側のPHPバージョンも見ます。
  • すぐ更新できない場合:首相の言うとおり、一時停止やアクセス制限も選択肢です。

動画の解説がどこまで技術に踏み込んでいるかは分かりませんが、事実関係の骨格はこの通りです。気になる章があれば、そこを掘り下げます。

ここから先は、PHP2Shellそのものではなく、 「PHPワーカーのメモリに何が起きていたのか」 を、OSやC言語のメモリ管理の観点から図解してみましょう。 これは怪談でいうと、
幽霊が怖いのではなく、 なぜ誰もいないはずの部屋に足跡が残ったのか
を調べる話です。

第1段階 通常のリクエスト

例えばユーザーがアクセスします。
するとPHPワーカーが起動します。
この時、
などがメモリ上に配置されます。

第2段階 メモリ確保

例えばアップロード処理。
を処理すると、 イメージとしては
のようにヒープ領域へ確保されます。

第3段階 正常終了

処理完了。
本来は
が呼ばれて
になります。

しかしワーカーは死なない

ここ重要です。 ApacheやPHP-FPMは 毎回プロセスを殺しません。 遅いからです。
実際は
を繰り返します。
つまり 同じメモリ空間を長期間使い回す のです。

メモリ解放とは何か

初心者が誤解しやすい点です。 解放しても
の中身は消えていません。
実際には
↓
↓
OSは単に
と印を付けるだけです。

再利用

次のリクエスト。
が来ると 同じ場所が再利用されます。
ここまでは正常です。

Use-After-Free

問題は 古いポインタが残ること。
を保持したまま
します。
そして別用途で再利用。
しかし Pointer Aは まだ
を見ています。
すると プログラムは
になります。

stale state のイメージ

今回よく出てくる
はこういう感じ。
本来
だったものが 終了時に消えるはず。
しかし異常終了。
次の
で 誤って参照。
これが 「古い幽霊が残る」 という意味です。

PHP2Shellを抽象化すると

PoC全体は、 実はたった4段階の構造です。
研究者たちが実証したのは、
「Request A の残り香を Request B が嗅げる」
ということです。 [blog.flatt.tech], [rocket-boys.co.jp]
あなたが以前興味を持っていた GMP や MPFR のような高精度演算ライブラリでも、本質的には同じ問題があります。
し忘れる、 あるいは
と、結果がおかしくなるだけでなく、場合によってはクラッシュします。 PHP2Shellは、その「解放済みメモリを触る問題」が、巨大なWebサーバー上で起きた例だと考えると理解しやすいです。 一言で言えば、
メモリは「消したつもり」では消えない。 プログラムが完全に忘れた時だけ、本当に安全になる。
という、C言語以来50年以上続く古典的な問題の現代版だったのです。
 
防御側の検証はできますが、 実際の脆弱性を再現するPoC実行や攻撃トラフィック生成は避け、パッチ適用確認・ログ監査・メモリ挙動観察に限定する のが安全です。 IPAも最優先対策として修正版への更新と状況確認を推奨しています。 [ipa.go.jp]

レベル1: 最も安全な確認

まず本番環境で確認する項目です。

バージョン確認

CLI版だけでなく、 実際にWebで動いているPHPを確認します。 業界では有名ですが、
だけでは不十分です。 CLI版とWeb版が異なるケースがあります。 [qiita.com], [satimo.org]

レベル2: ワーカー再利用確認

PHP2Shellで重要なのは
でした。 そこで 「本当に同じワーカーが再利用されるか」 を観察します。
テストページ
アクセス
なら 同じワーカーです。
図
ワーカー再利用自体は正常です。 PHP-FPMが高速なのはこれのおかげです。

レベル3: メモリ解放の観察

研究用サーバー限定です。
例えば
を作る。
その後
する。
そして
を見る。
イメージ
正常なら かなり戻ります。

レベル4: リクエスト独立性検証

これは今回の本質理解に役立ちます。
Request A
Request B 別セッション
結果
が正常。
図
つまり 利用者間の状態分離を確認する。

レベル5: ログ監査

実務ではこれが最重要
IPAも攻撃の可能性を考慮した確認を促しています。 [ipa.go.jp] 確認対象
見るもの
図

レベル6: メモリの「残骸」を見る考え方

ここが面白いところです。 実際のPoCは危険なので行わず、 概念だけ観察します。
正常系
↓
理想状態
脆弱系の発想
まるで、 あなたが好まれる怪談の構造そのものです。 部屋の住人Aは去った。 しかし
だけが残る。
次の住人Bが入る。 本来なら 関係が無い。 しかし
が見えてしまう。
メモリ管理の世界では、 これを
とか
とか
と呼びます。 PHP2Shellで研究者が見ていたのは、まさにこの「消えたはずの記憶が残っている」現象でした。だから防御側研究では、攻撃再現ではなく、
を観察するだけでも、脆弱性の本質をかなり深く理解できます。
 
以下は、PHP2Shell対応後の防御側検証チェックリストとして現場で使える形に整理したものです。

PHP2Shell 防御側検証チェックリスト

0. 緊急度判定

対象システム確認

  • PHPを使用している
  • 外部公開Webサイトである
  • PHP-FPMを使用している
  • Apache + mod_phpを使用している
  • レンタルサーバーでPHPを利用している
  • WordPress/Laravel/Drupal等を利用している

1. パッチ適用確認

PHP本体

  • PHP 8.2.35以上
  • PHP 8.3.36以上
  • PHP 8.4.27以上
  • PHP 8.5.12以上
のいずれかになっていることを確認する。 [ipa.go.jp]

実行環境確認

CLIだけでなく
  • Web経由で確認した
  • PHP-FPMのバージョンを確認した
  • Docker内のPHPを確認した
  • Apacheモジュール版を確認した

2. 再起動確認

サービス再起動

更新後でも古いワーカーが動いていないか確認。
  • php-fpm再起動済み
  • Apache再起動済み
  • nginx再読み込み済み
  • コンテナ再デプロイ済み

プロセス確認

  • 古いPHPプロセスが残っていない
  • ワーカー再生成を確認した

3. ログ監査

Apache/Nginx

  • access.log確認
  • error.log確認

PHP

  • php-fpm.log確認
  • php-error.log確認

着目点

  • 500エラー急増
  • OOMエラー
  • Worker Crash
  • Segmentation Fault
  • 異常再起動
  • Upload関連エラー

4. ワーカー状態確認

同一プロセス再利用確認

テストページ
確認項目
  • Workerが正常稼働
  • 子プロセス異常終了なし
  • プロセス生成ループなし

5. メモリ監視

システム側

  • OOM Killer発動履歴なし
  • Swap異常増加なし
  • メモリ使用率監視

PHP側

  • memory_limit適正
  • メモリリーク兆候なし

6. 状態分離検証

セッション

  • 別ユーザーへ状態漏洩なし
  • セッション再生成正常
  • ログアウト後破棄確認

キャッシュ

  • APCu正常
  • Redis正常
  • Memcached正常

7. アップロード機能確認

今回の話題ではアップロード処理が頻繁に議論されているため、重点確認対象です。 [blog.flatt.tech], [enhanced.co.jp]
  • ファイルアップロード正常
  • 異常終了なし
  • エラーログ増加なし
  • 一時ファイル削除正常

8. ファイル改ざん確認

Webルート

  • 不明PHPファイルなし
  • 新規作成ファイル確認
  • タイムスタンプ確認

よく見る場所

  • uploads
  • cache
  • tmp
  • public_html
  • vendor

9. アカウント確認

  • 管理者追加なし
  • 不審ユーザーなし
  • SSH鍵追加なし
  • cron改変なし

10. ネットワーク監査

  • 不審外向き通信なし
  • 海外IP通信急増なし
  • DNS異常なし
  • Reverse Shell痕跡なし

11. WAF・IDS確認

  • WAF有効
  • IPS有効
  • 検知ログ確認
  • ブロックログ確認

12. フォレンジック優先度判定

以下が1件でもあれば要調査。
  • OOM大量発生
  • PHPクラッシュ
  • Worker再起動連発
  • 不審PHP生成
  • 外部通信増加
  • 管理者追加
  • WebShell疑い

最終判定

A. 安全

  • パッチ適用済み
  • ログ異常なし
  • 改ざんなし
  • 通信異常なし
→ 継続監視

B. 要調査

  • ログに異常あり
  • クラッシュあり
  • 改ざん疑い
→ フォレンジック推奨

C. 侵害疑い

  • WebShell発見
  • 外部通信確認
  • 権限昇格痕跡
→ インシデント対応開始
研究者やCSIRTが実際にやる視点で言うと、PHP2Shellの検証で最も重要なのは「PoCを撃てるか」ではなく、
の4点です。今回の件はメモリ破損系の脆弱性なので、「侵入されたかもしれない」という前提でログと改ざん確認を行うのが、防御側の王道になります。
 
カテゴリ,項目,確認内容,結果,備考
緊急度判定,PHP利用,PHPを利用しているか,,
緊急度判定,外部公開,外部公開Webサイトか,,
緊急度判定,PHP-FPM,PHP-FPMを利用しているか,,
緊急度判定,mod_php,Apache+mod_phpを利用しているか,,
緊急度判定,レンタルサーバー,レンタルサーバーでPHPを利用しているか,,
緊急度判定,CMS利用,WordPress/Laravel/Drupal等を利用しているか,,
パッチ適用確認,PHP本体,PHP 8.2.35以上である,,
パッチ適用確認,PHP本体,PHP 8.3.36以上である,,
パッチ適用確認,PHP本体,PHP 8.4.27以上である,,
パッチ適用確認,PHP本体,PHP 8.5.12以上である,,
パッチ適用確認,実行環境,Web経由でPHPバージョンを確認した,,
パッチ適用確認,実行環境,PHP-FPMのバージョンを確認した,,
パッチ適用確認,実行環境,Docker内PHPのバージョンを確認した,,
パッチ適用確認,実行環境,Apacheモジュール版PHPを確認した,,
再起動確認,サービス,php-fpmを再起動した,,
再起動確認,サービス,Apacheを再起動した,,
再起動確認,サービス,nginxを再読み込みした,,
再起動確認,サービス,コンテナを再デプロイした,,
再起動確認,プロセス,古いPHPプロセスが残っていない,,
再起動確認,プロセス,新しいワーカー生成を確認した,,
ログ監査,Apache/Nginx,access.logを確認した,,
ログ監査,Apache/Nginx,error.logを確認した,,
ログ監査,PHP,php-fpm.logを確認した,,
ログ監査,PHP,php-error.logを確認した,,
ログ監査,異常検知,500エラー急増がない,,
ログ監査,異常検知,OOMエラーがない,,
ログ監査,異常検知,Worker Crashがない,,
ログ監査,異常検知,Segmentation Faultがない,,
ログ監査,異常検知,異常再起動がない,,
ログ監査,異常検知,Upload関連エラーがない,,
ワーカー状態確認,PID確認,同一ワーカーの動作を確認した,,
ワーカー状態確認,安定性,子プロセス異常終了がない,,
ワーカー状態確認,安定性,プロセス生成ループがない,,
メモリ監視,システム,OOM Killer発動履歴がない,,
メモリ監視,システム,Swap使用量異常がない,,
メモリ監視,システム,メモリ使用率が正常範囲である,,
メモリ監視,PHP,memory_limit設定を確認した,,
メモリ監視,PHP,メモリリーク兆候がない,,
状態分離検証,セッション,別ユーザーへの状態漏洩がない,,
状態分離検証,セッション,セッション再生成が正常である,,
状態分離検証,セッション,ログアウト後に破棄される,,
状態分離検証,キャッシュ,APCuが正常である,,
状態分離検証,キャッシュ,Redisが正常である,,
状態分離検証,キャッシュ,Memcachedが正常である,,
アップロード機能確認,ファイルアップロード,正常にアップロードできる,,
アップロード機能確認,異常終了,アップロード時の異常終了がない,,
アップロード機能確認,ログ確認,アップロード関連エラーがない,,
アップロード機能確認,一時ファイル,一時ファイル削除が正常である,,
ファイル改ざん確認,Webルート,不明なPHPファイルが存在しない,,
ファイル改ざん確認,Webルート,想定外の新規ファイルがない,,
ファイル改ざん確認,Webルート,不審なタイムスタンプがない,,
ファイル改ざん確認,uploads,不審ファイルがない,,
ファイル改ざん確認,cache,不審ファイルがない,,
ファイル改ざん確認,tmp,不審ファイルがない,,
ファイル改ざん確認,public_html,不審ファイルがない,,
ファイル改ざん確認,vendor,不審ファイルがない,,
アカウント確認,管理者,不審な管理者追加がない,,
アカウント確認,ユーザー,不審ユーザーが存在しない,,
アカウント確認,SSH,SSH鍵追加がない,,
アカウント確認,定期実行,cron改変がない,,
ネットワーク監査,通信,不審な外向き通信がない,,
ネットワーク監査,通信,海外IPへの異常通信がない,,
ネットワーク監査,DNS,DNS設定異常がない,,
ネットワーク監査,シェル,Reverse Shell痕跡がない,,
WAF・IDS確認,WAF,WAFが有効である,,
WAF・IDS確認,IPS,IPSが有効である,,
WAF・IDS確認,ログ,検知ログを確認した,,
WAF・IDS確認,ログ,ブロックログを確認した,,
フォレンジック判定,危険兆候,OOM大量発生がある,,
フォレンジック判定,危険兆候,PHPクラッシュがある,,
フォレンジック判定,危険兆候,Worker再起動連発がある,,
フォレンジック判定,危険兆候,不審PHP生成がある,,
フォレンジック判定,危険兆候,外部通信増加がある,,
フォレンジック判定,危険兆候,管理者追加痕跡がある,,
フォレンジック判定,危険兆候,WebShell疑いがある,,
最終判定,安全判定,パッチ適用済み,,
最終判定,安全判定,ログ異常なし,,
最終判定,安全判定,改ざんなし,,
最終判定,安全判定,通信異常なし,,
最終判定,判定結果,A:安全 / B:要調査 / C:侵害疑い,,
CSIRTやSOCで実際に回せるようにするなら、 単なるチェックリストではなく、
を持たせます。 以下は CSV 形式の「インシデント対応版」です。
投稿者 時刻:

0 件のコメント:

コメントを投稿

登録: コメントの投稿 (Atom)