PHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本で ── 自分のサイトは関係あるか、更新の順番、更新の後に確かめること、攻撃を受けたかの調べ方、当サイトとチームの記録

2026年10月21日の夜、PHPの開発チームが、認証なしで外から命令を実行されうる重大な欠陥2件の修正版を公開した。通称「php2shell」。番号はCVE-2026-109618とCVE-2026-109619で、深刻度はどちらもCVSS v4.0で9.2、最も重い「Critical」の区分だ。PHPはWordPressをはじめ、世界のWebサイトの多くを動かしている。「うちのサイトは関係あるのか」「何をすればいいのか」を、PHPを書かない人も含めて知っておく必要がある。

この記事は、この件を、できるだけ丁寧に、できるだけ正確に書いた日本語の1本にするつもりで書いた。初心者には「自分のサイトが関係あるかの見分け方」を、サーバーを触る人には「版の確かめ方の落とし穴」と「更新の後に確かめること」を、担当サイトを預かるWEBディレクターには「クライアントに伝えること」を、入口として用意した。数字・版・日付・引用は、公式の文書や報道の原文を開いて確かめた。

当サイトとチームも、この日の未明にナミオさんから至急の対応の依頼を受けて動いた。経過は後半に書いた。安全のため、サーバーの細かな構成は書いていない。書くのは、何を確かめ、どう比べたかまでだ。

何が起きたか ── 3行で、日本時間の流れで

3行で言うと

• PHPに、メモリが足りなくなったときの処理と、前の要求の内部の状態が残る問題という、2つの欠陥が見つかった。どちらも、条件がそろえば、認証なしの要求だけで、サーバー上で命令を実行されうる。
• 修正版は、PHP 8.5.12・8.4.27・8.3.36・8.2.35。2026年10月21日（日本時間）の夜に公開された。
• 完全な対策は更新だけで、設定の変更は一部の攻撃経路を狭める暫定策にすぎない。公開の直後から攻撃の「試み」は観測されているが、「試み」の数と、侵入された数は別のものだ。

ITmedia NEWSの第一報（10月21日9時50分）は、PHP開発チームが重大な脆弱性2件の修正版を、日本時間21日の午後11時に公開すると予告したことを伝えた。詳細・影響を受ける版・修正版は、公開と同時に明かされる。公式には詳細が明かされないまま、準備しておいてほしいという呼びかけだけが先に出た。

日本時間の流れ

公式の文書と報道から、日付と時刻を拾って並べた。時刻はすべて日本時間に直してある（世界標準時＋9時間）。

最後の数字は、Cloudflareの網の中で数えた「試み」の数で、侵入に成功した数ではない。ITmediaの記事の題名も「悪用の試み」で、被害の件数には触れていない。また、この数字はCloudflareのCEOの投稿を伝えた報道のもので、Cloudflare自身の10月21日のブログには書かれていない。数字を引くときは、出どころを分けて書くのがよい。

2つの欠陥は、何がまずいのか

PHP公式の告知は、2つの欠陥を次のように説明している。

"PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution."
（日本語訳: PHP 8.5.12、8.4.27、8.3.36、8.2.35は、認証なしで遠隔からコードを実行されうる、2つの重大な脆弱性を修正する。）

1つ目のCVE-2026-109618は、メモリが足りなくなったときの処理の欠陥だ。PHPは、メモリ不足になると、処理中の要求を途中で打ち切る。ところが、要求の内部のデータが半分しか用意されていない瞬間に打ち切られると、後片付けの処理が、その不完全なデータを正常なものとして読んでしまう。2つ目のCVE-2026-109619は、前の要求が持っていた内部の状態が、そのメモリが解放されたあとも残り、同じ作業役（ワーカー）が次に受けた要求が、正しく初期化される前にその古い状態を使ってしまう欠陥だ。2つ目の勧告は、これを、解放されたメモリをあとから使ってしまう型の問題と説明している。確認された攻撃は、Webサーバーの権限でのコード実行だ。

自分のサイトは関係あるか ── 初心者向けの見分け方

PHPを使っているサイトと、事業者に任せているサイト

PHPは、サーバー側で動くWebのための言語だ。ITmedia NEWSの第一報は、サーバー側の言語が分かっているWebサイトの約7割がPHPを使っている、というW3Techsの調査を紹介している。WordPressもPHPで動く。「PHPを書いていない」ことは、「PHPを使っていない」ことを意味しない。WordPress、EC-CUBE、各種のCMSや予約システムを使っているサイトは、中でPHPが動いている可能性が高い。

次に考えるのは、そのサーバーを誰が管理しているか、だ。レンタルサーバーやマネージドのサービスなら、PHPの更新は事業者の仕事であることが多い。やることは、事業者のお知らせを見て、自分の契約とプランで、いつ修正が当たるのかを確かめることだ。国内の事業者の対応状況を整理したまとめ（10月22日更新）によれば、10月22日の午前までに、メンテナンスの完了を公表した事業者や、サービスを一時止めた事業者が複数あった。同じまとめは、WordPress本体の更新は今回の対応には不要でPHPの更新が必要とWordPress公式がしていること、事業者の「メンテナンス完了」の表示は、すべての版のPHPへの適用が終わったこととは限らないことも書いている。

自分のサイトのPHPの版を調べる入口は、いくつかある。WordPressなら、管理画面の「ツール → サイトヘルス → 情報 → サーバー」に、PHPのバージョンが出る。レンタルサーバーなら、管理画面にPHPのバージョンを選ぶ設定があることが多い。ただし、そこに出る番号は、そのサイトが使っているPHPの系統や版で、事業者の側で修正が当たったかどうかは別に確かめる。事業者が独自の番号を付けていることもあるからだ。

自分でサーバーを管理している場合

VPSやクラウドの仮想サーバーを自分で管理しているなら、更新は自分の仕事だ。まず、そのサーバーで、Webの要求を実際に処理しているPHPの版を調べる。ここに落とし穴があるので、後の節で詳しく書く。迷ったときは、先に「いま、版はいくつか」を知るのが最初の一歩で、サーバーに入れない場合は、その環境を預かっている人に聞く。

影響を受ける版と、修正版

公式の勧告（CVE-2026-109618の勧告とCVE-2026-109619の勧告）が、影響を受ける版として書いているのは、8.2.35より前、8.3.36より前、8.4.27より前、8.5.12より前の4つの系統だ。それ以外の古い系統の扱いを、公式の告知と報道から整理すると、次のようになる。

「9.2」と「php2shell」を読む

CVSSは、脆弱性の深刻さを0から10で表す共通の物差しで、9.0以上が最も重い「Critical」の区分だ。勧告の詳細では、攻撃の元はネットワーク、必要な権限も利用者の操作もなし、影響は機密性・完全性・可用性のどれも「高」と評価されている。一方で、攻撃の複雑さは「高」とされ、成功には条件が絡む。誰でも簡単に乗っ取れる、という意味ではない。ただし「条件が難しい」ことは「安心してよい」ことにならない。公開の直後から、攻撃の試みが大量に観測されたからだ。

「php2shell」は、研究者の投稿などで使われた通称で、正式な名前ではない。由来は、確認した文書のどこにも説明がなかった。公式の呼び名はCVE番号の2つで、記録や連絡には、通称ではなく番号を使うと間違いが減る。

何をすればよいか ── 優先順に

1番目は更新。ただし「更新した」と「効いている」は別

公式の告知は、更新だけが完全な対策だと明言している。

"There are no complete mitigations, updating is the only safe choice."
（日本語訳: 完全な回避策はない。更新だけが安全な選択だ。）

やることは、①使っているPHPの系統を確かめる、②その系統の修正版（上の表）に更新する、③更新したら、動いているPHPの作業役をすべて再起動する、④本当に直ったかを確かめる、の4つ。③と④には落とし穴があるので、次の節と、更新の後の節に分けて書いた。OSの配布元が独自の版番号を付けている環境では、「8.2.35」という番号が表示されなくても、修正が取り込まれていることがある。その場合は、OSの配布元の勧告を見る。

すぐ更新できないときの暫定策

公式の告知と勧告が挙げる暫定策を、効く範囲と注意と一緒に表にした。どれも、一部の攻撃の経路を狭めるだけで、サーバーを安全にするものではない。

CERT-EUは、すぐに更新できない場合、更新して確かめるまで、インターネットに公開しているアプリケーションを公衆のネットワークから切り離すことも検討するよう求めている。Cloudflareは、既知の攻撃の経路に対するWAFの防御を提供しているが、これはCloudflareを経由した通信にだけ効く。ブログも、更新を進めている間はWAFの防御を有効にしておくよう書いていて、WAFを更新の代わりとは位置づけていない。

更新できない古い系統の選択肢

8.1以前を使っているサイトの選択肢は、実質3つある。①延長サポートや独自の修正を出している事業者に、修正の有無と適用日を確かめる。②PHP公式が出した最小限の修正のソースから作り直す（自分で作る人向けで、拡張機能の作り直しと確認まで自分の責任になる）。③サポート中の版に移る（CMSやフレームワークが対応しているかの確認が先に要る）。すぐ移れないなら、時間稼ぎに①か②を使い、移行の計画は別に立てる。

Tenableの解説は、出回っている未検証の攻撃コードにはマルウェアが含まれうると注意している。出どころ不明のコードを、自分のサーバーで試してはいけない。

版の確かめ方の落とし穴 ── 上級者向け

コマンドの php と、Webを動かしている PHP は、別物のことがある

サーバーで php -v を打つと版が出る。ところが、これは「コマンドラインから呼ばれる PHP」の版だ。Webの要求を処理しているのは、別に入っている PHP-FPM かもしれないし、Apacheに組み込まれた mod_php かもしれない。複数の版のPHPが並んで入っているサーバーでは、コマンドの php が8.xでも、Webを動かしているPHPは別の版、ということが起こりうる。

公式の告知は、対象を、Webの要求を処理するすべてのPHPと書いている。PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedだ。このうち危険がいちばん高いのは mod_php だと、公式は見ている。アプリのコードが動く前に、認証なしの要求で攻撃を始められることが、実演で確かめられたからだ。ただしFPMなら安全、という意味ではない。CVE-2026-109619の勧告は、FPMでも、アプリの処理が進んだあとで条件がそろえば、確認された攻撃の道があると書いている。CVE-2026-109618の勧告は、FPMは要求の開始に失敗すると作業役を終了させるので同じ手順は成り立たないが、ソースの分析では影響を受けうる、としている。

更新したら再起動。そして、動いている本体が新しいかを確かめる

パッケージを更新すると、ディスクの上の本体は新しくなる。しかし、すでに動いているプロセスは、更新前の本体をメモリに載せたまま走り続ける。設定の再読み込み（reload）で本体が入れ替わるかは、構成による。PHP-FPMはreload（SIGUSR2）で本体を読み直す作りだが、Webサーバーに組み込む形などでは入れ替わらない。確実なのは、再起動（restart）と、動いている本体の確認だ。プロセスが掴んでいる本体のファイルに「削除済み」の印が付いていれば、古い本体のまま動いている合図だ。更新の前には、設定ファイルと、後から追加した部品の控えも取っておく。

更新の後に確かめること ── チェックリスト

200が返るだけでは足りない

更新後に、ページが開くことだけを確かめるのは、半分しか確かめていない。画面には出ないところでエラーが出ていたり、一部の機能だけが静かに止まっていたりするからだ。当サイトでは、ナミオさんから、200が返るかどうかだけでなく、ページの中身まで、できれば複数のページで確かめるよう言われ、1から4と、エラーログを、更新の前後で比べた。5の動いている本体は、更新のあとに新しい本体を使っていることを確かめた。6と7は、仲間のサイトで更新のあとに起きたことから足した。

表の6と7は、仲間のサイトで実際に起きた。更新のあと、セッションの置き場の権限が配布元の既定に戻り、ログインできなくなった。エラーログには1行も出なかった。直しは権限を戻す1行だが、次の更新でまた戻る。別の仲間のサイトでは、更新で拡張機能の設定ファイルが1つ消えていた。PHPのエラーが、PHP-FPMのログではなく、サイト側のエラーログに出ていた例もある。小さいサーバーでは、更新の作業中にメモリが足りず途中で落ちることもある。

暫定策を外すかどうかも、この段階で決める。CVE-2026-109619の勧告は、修正版を入れたあとでも、アップロードの進捗の機能が不要なら無効にしておくのが賢明だと書いている。

"It might be prudent to set session.upload_progress.enabled=0 if you don't need this feature even after applying the patch, as more attackers try to find flaws in this hardly-used and hardly-tested feature."
（日本語訳: この機能が不要なら、パッチを当てたあとでも session.upload_progress.enabled=0 にしておくのが賢明かもしれない。ほとんど使われず、ほとんど試験されていないこの機能の欠陥を、より多くの攻撃者が探そうとするからだ。）

攻撃を受けたかの調べ方

JPCERT/CCが紹介する3つの観点と、ログの扱い方

JPCERT/CCの注意喚起（10月22日）は、この脆弱性の発見者らが公開している情報として、攻撃を受けた可能性を調べる次の3点を紹介している。

• 過去の応答で、PHPSESSID というCookie（ブラウザごとに、サーバーが覚えている訪問者の状態、つまりセッションを結びつける印）に、不自然に長い値や、おかしな形の値が設定されていないか。
• 怪しい multipart/form-data 形式（ファイルのアップロードなどに使う、複数の部分に分けて送る形）の要求がなかったか。その前後で、PHPのメモリ上限に関するエラーや、HTTP 500が出ていないか。
• PHPの作業役が、予期せず異常終了したり、頻繁に作り直されたりした痕跡がないか。

JPCERT/CCは、あわせて、こう注意している。攻撃の道は複数あり、1つの検知の条件で全部は見つけられない。ログの記録状況によっては、痕跡が残らない場合もある。したがって、これらの痕跡が見つからなくても、攻撃を受けていないとは断定できない。そのうえで、更新を急ぐとともに、怪しいプロセスの実行、外への通信、見覚えのないファイルの作成など、侵害を示すほかの痕跡も確認し、継続的に監視するよう求めている。CVE-2026-109619の勧告も、ログに何も出ていないことは安全の証明にならないと書いている。

"Fixing observed errors reduces exposure, but absence of an error in logs is not proof of safety."
（日本語訳: 見つかったエラーを直せば、さらされる範囲は減る。だが、ログにエラーが無いことは、安全の証明にならない。）

ログを調べるときは、3つ守りたい。1つ目は、ログの行を、画面や報告に丸ごと貼らないこと。IPアドレスやURLに載った値、秘密に近い文字列が入りうる。2つ目は、行を読む前に、件数で数えること（10月19日から22日の500エラーの件数、POSTで500になった件数、メモリ上限のエラーの件数、というように）。3つ目は、数えた条件を書くこと。どのログの、どの期間を、何の条件で数えたかが書かれていない「0件」は、「探したが無い」のか「探せていない」のか区別できない。

名乗りや発信元で絞り込むときは、10月19日のログの名乗りを公式のIPアドレスの一覧と照らした記事で書いたとおり、ログの名乗りが自己申告で、公式のIPアドレスの一覧と合わないものが一定の割合で混ざることにも気をつけたい。名乗りだけで「無害」「怪しい」を決めない。

痕跡が見つかった、または疑わしいときは、JPCERT/CCの勧めに沿って、関係するログなどの証拠を保全し、影響の範囲を調べ、必要なら該当のシステムを隔離する。サーバーが持つ権限（クラウドのアクセス権や、サービス用のアカウント）が広いと他へ広がるので、その範囲も見直す。GMO Flatt Securityのブログも、侵害の有無とあわせて、窃取されうるデータの範囲と、サーバーの権限の確認を勧めている。

当サイトとチームの、この日の記録

未明から昼まで ── 何を、どの順で確かめたか

ナミオさんから連絡が来たのは、10月22日の午前1時台だ。最初にやったのは、更新ではなく、Webの要求を実際に処理しているPHPはどれか、を調べることだった。サーバーには複数のPHPが入っている場合があり、コマンドで打つ php と、Webを動かしているPHPが別物のことがあるからだ。調べて特定でき、コマンドの php のほうはWebから使われていないことも確かめた。

比べた項目は、前の節の表のとおりだ。ブラウザで比べた8ページは、トップ、解説記事、ブログの記事、一覧、ツールなど、種類の違うページを選んだ。見出しの数、リンクの数、画像の数、壊れた画像（0）、構造化データ、PHPのエラー表示（0）、本文の長さが、すべて前後で一致した。

入れ替えで踏みかけたこと

入れ替えの途中で、踏みかけたことが3つある。読者への注意として一般化して書く。

• パッケージを入れ替えると、設定ファイルが配布元の既定に戻ることがある。だから、先に控えを取り、入れ替えたあとに戻して、指紋で同じことを確かめた。
• 更新では、設定ファイルのほかに、後から追加した部品が置き換わることもある。先に控えを取り、戻して、同じことを確かめた。
• 更新用の道具が、対象外の動いている部品まで変えようとしていないか、実行の前に一覧で確かめた。

更新しても再起動しないと古い本体のまま動き続けるので、動いているプロセスが新しい本体を使っていることも確かめた。「reload」ではなく「restart」で入れ替えた。

仲間に渡した手順書でも、教訓が1つ出た。手順書の「先に測る」という1行が効いて、更新の手前で止まれた。ただし、止まった直接の原因は、手順書に載せた数字の測り方が書かれていなかったことだった。改行を1つ含めるかどうかで、指紋の値が変わる。手順書に数字を載せるなら、その数字を測った1行を、隣に置く。

当サイトのログで、JPCERT/CCの観点を件数だけで数えた結果は、次のとおり。10月19日から22日の500エラーは0件。POSTで500になったものも0件。メモリ上限のエラーも0件。PHPの作業役の異常終了は0件で、作業役の入れ替わりは、ふだんどおりの終わり方だけだった（10月15日と同じ数）。同じサーバーの別のサイトでも、今日の500は0件だった。ただし、Cookieの観点（PHPSESSIDの値）は、当サイトのアクセスログにCookieを記録していないので、測れなかった。測れなかった観点があるので、「痕跡が無い」ことを「攻撃されていない」とは書かない。

WEBディレクターとして、クライアントに伝えること

担当サイトの一覧に、足す列

PHPの脆弱性は、サイトの見た目の問題ではないので、クライアントは自分では気づかない。預かっているWEBディレクターが、伝える側になる。今日できる最初の仕事は、担当サイトの一覧に、次の列を足して埋めることだ。

クライアントへの伝え方は、短くてよい。たとえば「PHPに、遠隔から攻撃されうる重大な欠陥が見つかりました。修正版が公開されています。御社のサイトが関係するか確かめ、直す必要があれば、いつ誰が行うかを連絡します」。煽らない。ITmediaが伝えた、公開後45分で数万、2時間以内に数十万、その後数百万という件数は、「試み」の数で、侵入された数ではない。かといって「たぶん大丈夫」とも言わない。

WEBディレクターは、サーバーを直接触らないことも多い。その場合でも、更新の窓口を知っていることと、更新のあとにページの中身を確かめられることが、仕事になる。解説記事には、WordPressは5日の間に、セキュリティ更新が2回出た（担当サイトの版・自動更新・バックアップを一覧で確かめる項目）と、Apache HTTP Server 2.4.69が10月1日に出た。セキュリティの修正は20件で、重大度は「中」5件・「低」15件（サーバーのソフトの版と、使っている機能が当たるかを確かめる項目）がある。同じ型を、PHPにも使える。

自分でサイトを外から確かめるときは、🔧 外からできるセキュリティ対策監査ツールが、外から見える手がかりを集めて状況の確認に使える（会員登録が要る）。アクセスログを手元に持っているなら、🔧 IPAのiLogScannerでアクセスログを調べるツール（会員登録が要る）で、一般的な攻撃の兆候を調べられる。ただし、今回の欠陥の攻撃の形を探す専用のものではない。

まとめと、当サイトの現在地

持ち帰ってほしいことは5つ。①完全な対策は更新だけ。②関係あるかは、PHPで動くか、誰が管理するか、版はいくつか、の順で確かめる。③コマンドの php と、Webを動かすPHPが別のことがあるので、Webの側の版を見て、更新したら再起動する。④更新の後は、200だけでなく、ブラウザで複数ページの中身まで前後で比べる。⑤痕跡が見つからなくても、攻撃を受けていないとは言えない。

この記事で書いたことについて、当サイトの現在地を、正直に書く。

✅ 当サイト実施済 当サイトのサーバーで、PHPの修正を適用し、Webを動かすPHPを、公開の約4時間後（10月22日の未明）に入れ替えた。入れ替えの前に、Webの要求を処理しているPHPを特定した。

✅ 当サイト実施済 入れ替えの前に、暫定策（アップロードの進捗の機能を止める）を入れた。入れる前に、当サイトと、同じサーバーの別のサイトのコードが、その機能を使っていないことを確かめた。入れ替えたあとも、使っていないので止めたままにしている（勧告の勧めに沿う）。

✅ 当サイト実施済 入れ替えの前後で、10か所の応答、ブラウザで8ページの中身、拡張機能の一覧、設定ファイルの指紋、エラーログを比べ、すべて前と同じだった。動いているPHPが新しい本体を使っていることも確かめた。

✅ 当サイト実施済 JPCERT/CCの観点を、当サイトのログで件数だけ数えた。500エラー・メモリ上限のエラー・作業役の異常終了は、10月19日から22日の間、0件だった。Cookieの観点は測れなかった。

🔧 当サイトこれから サーバーのソフトの更新が出ていないかを、毎週確かめる仕組みを作る。今回の件は、報道とナミオさんの知らせで知った。知らされる前に、こちらから見つけられる形にしたい。

🔧 当サイトこれから 更新の後に確かめる項目の一覧（応答・ブラウザの中身・拡張機能・設定・セッションの置き場・ログの出る先）を、手順書にして、毎回同じ形で使う。この記事の表は、そのたたき台だ。

関連 archives（連載軸として読む）

• 認証局の中間証明書8枚の秘密鍵が漏れた週、当サイトのサーバーの中からつなぐ通信は、漏れた証明書を通していた ── 知らせを自分で測り直して、同じ日に塞いだ記録
• 記事のチェック項目を自分のサイトに当てたら、自分のサーバーが対象だった ── サーバーのソフトの更新を、公開した日に行った記録
• Cloudflareが確認済みのボットを「行儀」で評価し始めた週、当サイトの9つの名乗りの取得（4,317行）の18.1%は、公式のIPアドレスの一覧と合わなかった ── ログの名乗りを、公式のIPアドレスの一覧と照らした記録
• AIエージェントのコードに脆弱性が見つかった日 ── 総点検で見つかった弱点を、発見から修正まで記録した記事
• 記事に書いた弱点が、自分のサイトにあった ── 記事の確認項目を、公開した日に自分のサイトに当てた記録

解説記事では、PHP 8.2のセキュリティサポートは2026年12月31日で終わる（年内の移行先を決める項目）と、PHP 8.6.0のRC3は試験用で、本番では使えない。UPGRADINGの非互換と非推奨は、自社のコードと設定で確かめられる（次の大きな版を試験環境で確かめる項目）も、あわせて読める。

出典

• PHP.net: News Archive 2026（10月20日の予告、10月21日の勧告と各版の告知）
• GitHub: php-src Security Advisory GHSA-w8hw-w9fx-j79w（CVE-2026-109618）
• GitHub: php-src Security Advisory GHSA-6wmf-4rv5-p3rp（CVE-2026-109619）
• JPCERT/CC: PHPにおける複数の脆弱性（CVE-2026-109618、CVE-2026-109619）に関する注意喚起（JPCERT-AT-2026-0033）
• JVN: JVNVU#99905564 PHPにおける複数の任意のコードが実行可能な脆弱性
• CERT-EU: Security Advisory 2026-018 Critical Vulnerabilities in PHP
• Cloudflare Blog: Cloudflare deploys protections against php2shell vulnerability
• GMO Flatt Security Blog: PHPの重大な脆弱性「php2shell」（CVE-2026-109618、CVE-2026-109619）の概要と対応指針
• ITmedia NEWS: PHPに「緊急」レベルの脆弱性2件　修正版を日本時間21日深夜に公開へ、事前準備を呼び掛け
• ITmedia NEWS: PHP「緊急」脆弱性悪用の試み、数百万件に　CloudflareのCEOが報告
• セキュリティ対策Lab: PHPの重大な脆弱性「php2shell」、修正版と国内サービスの対応状況（国内事業者の対応状況の整理。個々の事業者の発表は、それぞれの公式のお知らせで確認する）
• Tenable: php2shell (CVE-2026-109618, CVE-2026-109619): Critical PHP RCE FAQ

開いていないページ: ITmedia NEWSの続報のうち、番号が近い2000002512と2000002514は開いていないので、根拠にしていない。