2026年10月21日、Webサイトの約7割で使われているプログラム言語「PHP」に、ログインなしでサーバを乗っ取られるおそれのある重大な欠陥（通称「php2shell」）が2件公表されました。修正版の公開前に情報が流出したため、日本ではpixiv、ニコニコ、BASE、銀行、省庁、レンタルサーバ各社などが予防的にサービスを止め、首相がXで対応を呼びかける事態になりました。

※時刻はすべて日本時間です。2026年10月23日時点の情報をもとにしています。

どんな脆弱性だったのか

phpファイルが動作する環境であれば、パスワードなしでサイトの管理者として操作が可能になります。（サイト乗っ取り）

見つかった欠陥は2件で、深刻度はどちらも10点満点中9.2点（最も深刻な「緊急」レベル）です。

• 1件目（CVE-2026-109618）：サーバのメモリが足りなくなったとき、PHPが「作りかけのデータ」を残したまま処理を中断し、後片付けの段階でそれを正しいデータとして扱ってしまう問題。
• 2件目（CVE-2026-109619）：前の閲覧者（リクエスト）が使い終えて片付けたはずの情報が残り、次の閲覧者の処理で誤って使われてしまう問題。

片づけるデータ側に攻撃用のコードを仕込んで、何度も試行することで、うまくいった場合にサーバを乗っ取ることができるというものです。

PHPとは

サイト上で動作するプログラム言語です。世界のサイトの約7割が使っているとされるもので、WordPressなどの動作に必要不可欠のものになります。

事実上、これなしではスタンダードなWebサイトのほとんどは動作しません。

弊社の管理する全てのWebサーバに導入しているものです。

影響を受けたバージョン

PHP全てのバージョンで、21日22時52分に修正された安全なバージョンは PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 です。

8.1以前には正式な修正版が出ていませんが、弊社で最も標準的に使用しているさくらインターネットでは、修正済みバージョンをバックポートして古いバージョンにも適用しているため、弊社管理の全てのサーバで脆弱性は解消しています。

お客様側でサーバを管理している一部のサーバについては問題が残っているものがあります。（WebARENAサーバ停止中）

時系列

日時（日本時間）	出来事
2026年8月	2件の脆弱性がPHP開発チームに報告される。発見にはAIを使った調査が関わったと報じられている
10月17日（米国時間）	Amazonのおとりサーバが、公表4日前に悪用の試みを記録
10月20日	PHP開発チームが「重大な脆弱性2件の緊急更新」を予告。欧州のCERT-EUが更新準備を呼びかけ
10月21日 未明	情報の一部が流出。公開予定を22日から21日23時へ1日前倒し
21日 11時半ごろ	流出した資料が出回り始め、攻撃が現実的になる
21日 12時ごろ	Cloudflareが攻撃遮断ルール（WAF）を全プランに配備。初期の攻撃を観測と発表
21日 午後〜夜	IPA・国家サイバー統括室が注意喚起。欧州ではオランダ・フィンランド・デンマーク・フランスなどの政府機関がサイトを停止
21日 夜	首相がXで修正適用の準備を呼びかけ。財務省、銀行、航空会社、ゲーム各社も停止。ロリポップ！・ヘテムルも順次停止
21日 22時52分	PHP修正版（8.5.12 / 8.4.27 / 8.3.36 / 8.2.35）公開
21日 23時〜	さくらがPHP更新作業を開始。各レンタルサーバで夜通しの適用作業
22日 6時半ごろ	さくらが修正適用完了を告知
22日 18時	NTTのWebアリーナがメンテナンス入りでサーバ停止。復旧未定

実際にはどこまで危険だったのか

攻撃の試行

攻撃の試行は世界中で大規模に確認されています。Amazonのおとりサーバは公表4日前の10月17日に最初の試行を記録しており、22日には米国のIT企業が数百万件の試行を検知したと発表しました。

攻撃が現実的になったのは、流出した資料が出回り始めた10月21日11時半ごろからです。弊社では、SSHで調査できる弊社管理のサーバについて、10月15日〜23日のアクセスログとファイルを調査しました。

その結果、php2shellを狙った可能性のある大量アクセスを2件確認しています。いずれも10月21日の夕方から夜（17時56分〜20時22分）、つまり情報流出後で修正版の公開前に集中しています。1件は約1時間40分で3,855件、もう1件は約1時間50分で2,661件のアクセスでした。2件は同じ手口だったことから、同一の攻撃ツールによるものとみられます。

なお、サーバへの攻撃自体は珍しいものではなく、無差別な攻撃（設定ファイルの探索、ログイン画面へのパスワード総当たりなど）は普段から日常的に届いています。

実際の被害はどの程度あったのか

調査したすべてのサーバで、侵入に成功した痕跡は見つかりませんでした。具体的には、次の5点をすべて確認しています。

• 不正なプログラム（Webシェル）の設置
• 画像などのアップロード用フォルダへの不審なプログラムの混入
• 不審な定期実行処理の登録
• 攻撃元からの管理画面へのログイン
• 攻撃に伴うサーバの異常終了

大量アクセスを受けた2件についても、サーバは通常どおりの応答を返しており、エラーや異常終了は記録されていませんでした。

世界的にも、乗っ取りに成功したと確認された例はごく少数です。一般的なサーバには防御機能（ASLR）があり、出回った攻撃コードの大半はこれを突破できませんでした。ただし、公表翌日にはこの防御を回避する手法が研究者によって作られているため、初日に修正できていない場合はまずいことになっていると思います。

サイトを閉鎖してメンテナンス表示に切り替えるべきだったのか

結果として、弊社管理のサーバでは被害は確認されていませんが、攻撃は「修正版がまだない時間帯」に、実際に弊社管理のサーバにも届いていました。

PHP開発チーム自身が「完全な回避策はない」としていた状況を考えると、個人情報を扱うサイトや、お問い合わせフォームを持つサイトでは、一時停止も十分に合理的な選択肢だったと考えています。

弊社が停止に踏み切れなかった理由

事態の深刻さが広まったのは夕方以降でした。情報の一部は21日未明に流出し、11時半ごろには流出した資料も出回り始めていましたが、実際に悪用されているという報告が出たのは16時半ごろです。大手レンタルサーバが管理画面を止め始めたのも16時前後でしたがPHPによるものとの明言がなく、一般には別の大きな脆弱性（CVE-2026-99999、深刻度9.3）の対応とみられていました。国内で深刻さが広く認識されたのは夕方以降でした。

私個人には19時台に、他社のサーバ管理者から、とりあえず22時から海外からのアクセスを全部切ることが決まったという話を聞き、21時台からサービス自体をメンテナンスにして閉じるというのが聞こえてきたという状態でした。

こういった状態を認識したものの、顧客のサイトを危険だから勝手に閉じるという手段に出るわけにもいかず、協議が必要な状態だったものの、修正版の公開（23時）まで数時間しかない中で、一社ずつ停止を協議したとしても時間的に不可能だった可能性があります。

また、公開するという情報は出回っていたものの、何をしたら防げるかの情報が公開されていなかったので、PHPが導入されているレンタルサーバならPHPプログラムをすべて消したら防げる脆弱性なのか、それともPHP自体をアンインストールしないと止められないタイプのなのか分かっていませんでした。

今後に向けて

今回の経験から、同様の事態では承認を待たずに一時停止できる取り決めが必要だと考えています。

【停止の条件】

• サイトの一時停止を決める段階で、技術的にどうやって一時停止すれば安全かが判明していること
• 協議の時間すらないと判断できる時間であること（夜公開であれば定時過ぎているタイミングで）

などが考えられますが、定例会などでお話しできればと思います。