DevNJ Make your business ease
コラム /

PHP2Shell(CVE-2026-109618/109619)その後の経過|運営者が確かめる点(10月30日更新)

コラム › サイト運用

PHP2Shell(CVE-2026-109618/109619)その後の経過|運営者が確かめる点(10月30日更新)

2026年10月21日の昼過ぎ、オランダで DigiD(ディヒデー、行政手続き用のログインID)と MijnOverheid(マイン・オーフェルヘイト、行政からの通知を受け取る個人ポータル)が、相次いで見られなくなりました。下院(Tweede Kamer、トヴェーデ・カーメル)のサイトや、国のサイバーセキュリティ機関 NCSC(Nationaal Cyber Security Centre)自身のサイトも止まりました。

原因は攻撃ではなく、攻撃を受ける前に止めるという予防措置です。世界中のWebサイトで使われているプログラミング言語 PHP に、深刻な脆弱性が2つ見つかり、修正版が出るまでの数時間、多くの組織がサイトを閉じる判断をしました。

この記事では、10月21日〜22日に公開された一次情報(NCSC、PHP 公式、英国 NCSC、日本の IPA と JPCERT/CC)と在住者向けの報道を突き合わせ、確定していることと、まだ分からないことを分けて整理します。前半は在住者の暮らしへの影響と、いまやること。後半は、自社や取引先のサイトを運営している人向けの実務チェックリストです。悪用の手口の詳細には触れません。10月30日に、その後の経過を「10月22日以降に分かったこと」にまとめて足しました。

この記事が主に根拠にした情報

  • オランダ政府(Rijksoverheid)の NCSC 警告「Ernstige kwetsbaarheden in PHP」(2026年10月21日 13時59分公開)と、NCSC Community の時系列まとめ
  • PHP 公式サイトのリリース告知とサポート期間の表、GitHub 上の2件のセキュリティアドバイザリ
  • 英国 NCSC「Critical security issue affecting PHP」(2026年10月21日)
  • IPA の注意喚起(10月21日の事前告知、22日の本告知)と JPCERT/CC の注意喚起 JPCERT-AT-2026-0033(10月22日)
  • NOS のライブブログ、NL Times(10月21日の2本)、DutchNews.nl、Dutch IT Leaders
この記事で分かること 答えの要点
10月21日に何が起きたか 11時台の警告から、夜の DigiD 復旧までの時系列(第1章)
どこまでが確定した事実か CVE番号・修正版は確定。悪用状況と影響範囲には幅がある(第2章)
10月22日以降に何が変わったか CISA KEV への掲載、追加の修正版の有無、復旧状況(「10月22日以降に分かったこと」)
在住者はいま何をすればよいか 個人の端末は対応不要。詐欺メールに注意(第5〜6章)
自分のサイトは大丈夫か 管理画面かサイトヘルスで版を確認し、修正版か確かめる(第7〜9章)
古い版で動いているサイトは 8.1以前は移行が前提。8.2も年末で終了(第10章)
今後どう備えるか 台帳・監視・検証・適用の4段の更新体制(第14章)

更新履歴

初出は10月22日です。10月30日に、その後の経過と製品ごとの対応状況を足し、タイトルと冒頭の結論を直しました。

日付 内容
2026年10月22日 初出(速報)
2026年10月30日 CVE 番号を CVE Program の記録と php-src の GitHub アドバイザリで照合し、「10月22日以降に分かったこと」と「製品ごとの対応状況」を追加。FAQ の悪用状況と復旧状況を更新

CVE-2026-109618 と CVE-2026-109619 は、CVE Program の記録(どちらも2026年10月21日公開、CVSS v4.0 で 9.2)と、PHP の GitHub アドバイザリ(109618 は GHSA-w8hw-w9fx-j79w)の双方で確認できました。NVD のページは、確認した10月30日には本文を読めなかったため、番号の照合には使っていません。

10月22日以降に分かったこと(10月30日時点)

ここでは、初出の後に動いた点を、NCSC・PHP 公式・CISA の一次情報と報道で確かめて並べます。確かめられなかった点は「確認できなかった」と書きます。いずれも10月30日に確認しました。

悪用の状況:CISA が KEV に加えた

次の表は、悪用に関する動きを日付順にまとめたものです。一次情報と報道を分けて書いています。

日付 内容 出典の種類
10月17日ごろ Amazon が、修正版の4日前に悪用の試みを観測したと報告 報道(Drupal Association のブログが引用)
10月23日 PHP が、CVE-2026-115560 に関する注意(後述)を公開 一次情報(PHP 公式)
10月24日 Perplexity の研究者が、ハニーポット(おとりのサーバー)で実際にシェルが動いたと報告 報道(BleepingComputer)
10月26日 米CISAが、両方の CVE を KEV に追加。連邦機関の対応期限は10月29日 一次情報(CISA KEV)
10月27日 Wiz は、自社の観測では最後の段階まで成功した例を確認していないと説明 研究者の発表(Wiz)

この表から言えるのは、「悪用は未確認」の段階は終わったことです。10月24日の例は、研究者が「条件の良い単一ワーカーの mod_php」と説明した環境でのものです。一方で、実在の企業や行政のサイトが侵害されたという当局の発表は、確認できませんでした。NCSC Community のページにも、悪用を観測したという更新は載っていませんでした(10月30日確認)。

復旧の状況:overheid.nl の復旧日は確認できなかった

DigiD と MijnOverheid が21日夜に復旧したことは、初出のとおりです。Binnenlands Bestuur は21日付で、自治体のサイトや MijnOverheid などが数時間で戻ったと伝えています。

overheid.nl については、NOS の記事が22日6時53分に更新された時点で停止が続き、内務省は再開時期を示していませんでした。その後の復旧日は、公的な発表も報道も確認できませんでした。NotuBiz も22日朝の復旧見込みと報じられたところまでで、復旧の確認は取れていません。

自治体サイトの古い PHP についても報じられています。Binnenlands Bestuur は10月23日、BNR が約900の自治体サイトを調べ、50超が古い PHP のままの可能性があると伝えました。多くはトップページではなく、庇護や観光などの個別ページです。BNR は NCSC と VNG にアドレスを伝え、公開はしていません。専門家は、スキャナーの結果は古い情報に基づき、実際には脆弱でないサイトを拾うことがあると注意しています。26日には同誌が MindYourPass の調査を報じ、PHP と確認できた60,362件のうち28,615件(47%)が、古い版・サポート切れ・影響を受ける版でした。新しい脆弱性そのものは調べておらず、標本も全体を代表しません。NOS の該当記事は見つかりませんでした。

追加の修正版:8.5.12 などの後の新版は確認できなかった

10月30日時点の php.net には、10月21日の 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 より新しい版は見当たりませんでした。10月26日には Windows 向けのビルドが、Brotli ライブラリの修正(CVE-2026-111497)を含めて作り直されました。版番号の末尾に「-1」が付く再ビルドで、PHP 本体の版は変わっていません。

もう1つ、10月23日に PHP が出した注意があります。セッションのアップロード進捗の機能が有効で、特定の設定の組み合わせがあると、リモートでコードを実行される恐れがある、という CVE-2026-115560 です。PHP は「起きにくい」としつつ、次の定期リリースまで session.upload_progress.enabled=0 にするよう勧めています。この問題の修正版はまだ出ていません。

製品の一覧:NCSC が追跡している数

NCSC オランダの GitHub は、PHP を内蔵する製品の対応状況の一覧を更新しています。10月30日9時14分(中央ヨーロッパ時間)の更新で、追跡中の929製品のうち、脆弱が217、修正済みが165、調査中が345、影響なしが201でした(うち1件は状態が未記入です)。調査中が最も多く、「まだ分かっていない製品が多い」のが現状です。

製品ごとの対応状況(10月30日時点)

PHP で動く代表的な製品について、ベンダー自身の告知が確認できたものだけを表にしました。告知が確認できないものは「未発表」と書き、NCSC の一覧での扱いを備考に添えています。NCSC の一覧は第三者の評価で、ベンダーの告知ではありません。

製品 ベンダーの告知 対応状況
WordPress.com・WordPress VIP・Pressable など Automattic(10月21日) 保護済み。利用者の作業は不要
WordPress(自分で運用) Automattic(同上) WordPress・テーマ・プラグインの更新では直らない。PHP を修正版に
WP Engine 10月22日 全顧客サイトが修正済みの PHP。作業は不要
Drupal Drupal Association(10月22日) 欠陥は PHP 側。PHP を更新する。Drupal 本体の更新で直すとは書かれていない
Nextcloud All-in-One 14.4.1 のリリース(10月21日) 修正済み。PHP の依存を更新した版
Nextcloud(自前の運用) 未発表(確認できなかった) NCSC の一覧では「脆弱」。修正済みの PHP が前提
Zabbix のフロントエンド 未発表(確認できなかった) NCSC の一覧では「脆弱」。ベンダーの告知ではなく評価
Joomla 未発表(確認できなかった) NCSC の一覧では「脆弱」。同上

表の読み方は共通で、製品のバージョンを上げるだけでは足りず、動いている PHP を修正版にする必要があります。ホスティング側で PHP を管理している場合は、業者の告知で更新を確かめます。この表に載せていない製品は、本稿では確認していません。

1. 10月21日に何が起きたか

警告から復旧までの約10時間

NCSC Community の時系列まとめによると、NCSC が PHP の2つの深刻な脆弱性を最初に伝えたのは、10月21日の11時3分(オランダ時間)でした。その時点では修正版はまだなく、NCSC は「16時に予定されている PHP の修正に備えること」を呼びかけました。

政府の公式ニュースサイトに警告が載ったのは13時59分です。警告文は、公開済みの実証コード(PoC、Proof of Concept)がある一方で積極的な悪用はまだ見ていないこと、インターネットに公開されている PHP のシステムは修正まで「おそらく脆弱」とみなすこと、場合によっては停止を検討すること、の3点が柱でした。

次の図は、NOS のライブブログと NCSC Community の記録から、主な出来事を時刻順に並べたものです。

11時3分にNCSCが警告、12時52分に下院サイトが停止、14時46分にフランダース政府のサイトも停止、15時43分にPHPが修正版を公開、18時11分にMijnOverheidが復旧、20時27分にDigiDのサイトが復旧。22日になってもoverheid.nlは停止が続いた。 11:03 NCSCが警告を発表 16時の修正に備えるよう要請 12:52 下院のサイトが停止 予防措置。以後、報道・病院なども 14:46 フランダース政府も停止 仏・独・フィンランドにも波及 15:43 PHPが修正版を公開 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 18:11 MijnOverheid が復旧 NOSの記録による 20:27 DigiD のサイトが復旧 NCSCの判断ツールも20:40に再開 22日 overheid.nl は停止が続く 再開の時期は未定と内務省
図1:2026年10月21日(オランダ時間)の主な出来事。点線の円は未確定(出典:NOS ライブブログ、NCSC Community、2026年10月22日確認)

修正版の公開時刻には小さな幅がある

修正版の公開時刻は、資料によって少しずれています。NOS は15時43分、NCSC Community は15時50分の更新で「パッチが出た」と記録し、NL Times は「16時ごろ」と書いています。予定の16時より少し早く出た、という点ではどれも一致しています。

時刻(オランダ時間) 出来事 主な出典
21日 11:03 NCSC が2件の深刻な脆弱性を報告 NCSC Community
21日 13:59 政府サイトに NCSC の警告が掲載 Rijksoverheid
21日 15:43〜16:00ごろ PHP が修正版を公開 NOS / NCSC / NL Times
21日 18:11 MijnOverheid が復旧 NOS
21日 20:27 DigiD のサイトが復旧 NOS
22日 overheid.nl・NotuBiz の一部が未復旧 NOS

この表から分かるのは、修正版が出てから復旧までに、組織によって数時間〜1日以上の差が出たということです。NL Times によると、NCSC の副所長は記者会見で「スイッチを切り替えるだけで済むサイトもあれば、使っている版によってはもっと時間がかかる」と説明しました。

2. 脆弱性の中身:確定していること、まだ分からないこと

2つのCVEと「PHP2Shell」という呼び名

今回の脆弱性は、CVE-2026-109618 と CVE-2026-109619 の2件です。CVE は脆弱性に振られる世界共通の識別番号で、NCSC オランダが GitHub に置いたまとめによると、番号は EU の CERT-EU が採番しました。

PHP 公式のアドバイザリによれば、1件目はメモリ不足(OOM)を処理する途中の不整合、2件目は前のリクエストの内部状態が次のリクエストに残ってしまう問題です。どちらも、条件がそろうとログインなしで外からサーバー上のコードを実行される(リモートコード実行、RCE)恐れがあります。

「PHP2Shell」は、発見に関わった Wiz 社のブログと、日本の IPA の注意喚起で使われている通称です。オランダ政府の警告文や PHP 公式のトップページには、この呼び名は出てきません。

確定・未確定を分けた一覧

報道は数時間ごとに更新され、同じ点について違うことを書いている記事もあります。次の表は、10月22日の時点で一次情報どうしが一致していることと、幅があることを分けたものです。

項目 確定していること 幅がある・未確定のこと
脆弱性の数と番号 2件。CVE-2026-109618 / 109619 なし
修正版 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 追加の修正が出る可能性あり(NCSC)
影響する版 8.2〜8.5の修正前の版は影響あり 古い版の範囲:NCSCは「5以降」、Wizは「5.4以降」
悪用の状況 公開済みのPoCがある。10月26日に CISA が KEV に追加 実在サイトの侵害は当局の発表を確認できず(10月30日時点)
発見の経緯 2026年8月に発見、AIを使った調査 発見日と発見者の記述が媒体で異なる
影響の大きさ 多くの組織が予防的に停止 「Webサイトの約70%」はWizの推計

この表の右の列は、今後の発表で変わる可能性があります。記事や社内連絡で数字を引用するときは、出典と確認日を一緒に書くのが安全です。

悪用の状況:「未確認」と「狙われている」は両立する

この節は10月22日時点の記述です。その後、10月26日に CISA が KEV に加えました。最新は「10月22日以降に分かったこと」を見てください。

NCSC、PHP Foundation、米国の CISA は、10月22日時点で積極的な悪用(実際の侵入被害)を確認していないと伝えています。オランダのファン・ヴェール法務・安全保障相の報道官も「現時点で悪用の兆候はない」と述べました。

一方で DutchNews.nl は、Cloudflare が脆弱性を探したり攻撃したりする通信を観測し、防御していると伝えています。NOS も、修正版の告知の後に攻撃者のあいだで情報が共有されたと報じています。NL Times によれば、詳細の一部は修正版より先に漏れていたと NCSC は説明しました。

この2つは矛盾しません。「侵入が確認された被害はまだない」ことと、「狙う動きがある」ことは同時に成り立ちます。運営者としては、後者を前提に動くのが妥当です。

発見の経緯:日付の記述が食い違っている

発見の経緯は、媒体によって書き方が違います。NOS は PHP Foundation の話として「1件目は8月11日に Calif と OpenAI が、2件目は8月24日に Wiz が見つけた」と伝えています。Wiz 自身のブログは「8月19日に最初の欠陥を見つけ、8月24日に PHP に報告した」としています。

DutchNews.nl は「8月に OpenAI と Google の AI モデルを使って見つかった」と書いています(Wiz は Google の傘下です)。8月に AI を使った調査で見つかったという点は一致していますが、日付と発見者の組み合わせは確定できません。この記事では、どれか1つに寄せずに併記します。

3. 修正版と、PHPのサポート期間

修正版の一覧

PHP 公式サイトは10月21日に、サポート中の4つの系列すべてに修正版を出しました。次の表は、系列ごとの修正版と、PHP 公式のサポート期間の表から取った期限です。

系列 修正版 通常サポートの終了 セキュリティ修正の終了
8.5 8.5.12 2027年12月31日 2029年12月31日
8.4 8.4.27 2026年12月31日 2028年12月31日
8.3 8.3.36 2025年12月31日(終了) 2027年12月31日
8.2 8.2.35 2024年12月31日(終了) 2026年12月31日
8.1以前 正式な修正版なし 終了 終了

この表のうち、8.2は2か月あまりでセキュリティ修正も終わります。いま8.2.35に上げて終わりにすると、年明けには同じ判断をもう一度迫られます。上げるなら8.3以上を選ぶほうが、作業を1回で済ませられます。

2026年初めを起点に、セキュリティ修正の終了時期を横棒で示す。8.2は2026年末、8.3は2027年末、8.4は2028年末、8.5は2029年末まで。8.1以前はすでに終了している。 PHP 8.5 2029年末 PHP 8.4 2028年末 PHP 8.3 2027年末 PHP 8.2 2026年末 8.1以前 終了済み(正式な修正なし) 2026 2027 2028 2029 2030
図2:系列ごとのセキュリティ修正の期限(出典:PHP Supported Versions、2026年10月22日確認)

8.1以前の扱い:最小限の修正は出たが、根本策ではない

オランダ政府の最初の警告文は、「分かっている限り、修正は PHP 8 にだけ適用される」と書いていました。その後 NCSC Community は更新で、7.4・8.0・8.1向けに最小限のソース修正(バックポート)が公開されたと伝え、前の記述より新しい情報として扱うよう注記しています。

ただし、この最小限の修正は、自分でソースから PHP を組み立てる人向けのものです。PHP 公式も JPCERT/CC も、サポート中の版への移行を推奨しています。Linux ディストリビューションや長期サポート(LTS)を提供する事業者が、独自に修正済みのパッケージを出す場合もあります。

4. 止まったサイト、止まらなかったもの

オランダ国内で止まった主なサイト

予防的にサイトを止めた組織は、政府に限りませんでした。次の表は、NOS・DutchNews.nl・NL Times・Dutch IT Leaders が伝えた主な例を分野別にまとめたものです。

分野 報じられた主な例 出典
行政 DigiD、MijnOverheid、下院、NCSC、overheid.nl、水管理委員会の連合会 NOS / DutchNews / Rijksoverheid
行政の業務 UWV の病欠届けツール、自治体会議文書の NotuBiz NOS / DutchNews
教育・研究 SURF の共有ITネットワークの一部 NL Times / Dutch IT Leaders
報道・放送 RTL のサイトとアプリ、NPO の配信入稿、NL Times、DutchNews NOS / NL Times / DutchNews
医療・慈善 複数の病院、KWF、Hartstichting、Amnesty NOS / DutchNews
生活 Schiphol アプリの運航情報、KNVB とサッカークラブ NOS

表から分かるとおり、影響は「政府のサイト」に限られません。在住者が日常的に使うサービスの裏側でも、PHP が広く使われていることが見えた1日でした。

個人データ保護当局(AP)について

一部では、個人データ保護当局 AP(Autoriteit Persoonsgegevens、アウトリテイト・ペルソーンスヘヘーフェンス)のサイトも止まったと伝えられていました。ただ、この記事のために確認した NOS・DutchNews.nl・NL Times・Dutch IT Leaders の記事と NCSC の発表には、AP の名前は見当たりませんでした。AP のサイトが止まったかどうかは、この記事では確認できていません。

国外への広がり

DutchNews.nl と NOS は、ベルギーのフランダース政府、ドイツ、フランス、フィンランドの政府サイトも一時的に止まったと伝えています。フランスは内務省が県庁(préfecture)のサイトを止めました。NOS によると、22日の時点でベルギーとフランスにはまだ影響が残っていました。

英国の NCSC も同じ21日に注意を出し、PHP のインストールをすべて洗い出すこと、外部に公開されたものを優先することを求めました。日本でも、22日に IPA と JPCERT/CC が注意喚起を出しています(第13章)。

5. 在住者の暮らしへの影響と、いまやること

個人の端末には何もしなくてよい

PHP は、Webサイトを表示するサーバーの側で動くプログラミング言語です。利用者のスマホやパソコン、ブラウザに更新を入れる必要はありません。「PHPの脆弱性の修正のため、このアプリを入れてください」といった案内が来たら、それ自体が詐欺を疑う理由になります。

今回、利用者にとっての実害は「一部のサイトが数時間使えなかった」ことでした。NOS によると、DigiD のサイトが止まっていたあいだも、DigiD を使って他の機関のサービスにログインすることはできていたといいます。

止まったサービスごとの対処

次の表は、止まったと報じられたサービスについて、困ったときの考え方をまとめたものです。復旧状況は時間とともに変わるので、最新の状況は各機関の公式サイトで確かめてください。

困ったこと 状況(10月22日時点の報道) 考え方
DigiD でログインできない 21日20時27分にサイト復旧 時間をおいて、公式サイトに自分で入り直す
MijnOverheid の通知が見られない 21日18時11分に復旧 期限のある通知は、郵便や担当機関でも確認できる
overheid.nl が開かない 22日も停止、再開時期未定 法令・手続きの情報は各省庁のサイトで探す
自治体の会議資料が見られない NotuBiz の一部が未復旧(デン・ハーグ含む) 22日朝の復旧見込みと報道。急ぎなら自治体に問い合わせる
UWV の病欠届けができない ツールを一時停止 雇用主か UWV に電話で連絡する

期限が迫った手続きがあり、サイトの停止で間に合わなかった場合は、停止していた日時を記録しておくと、後で担当機関に事情を説明しやすくなります。報道記事のURLやスクリーンショットでも構いません。

デン・ハーグ在住者に関係する点

NOS によると、自治体や州が会議文書の管理に使う NotuBiz では、デン・ハーグ、アルメレ、ブレダ、ハールレム、デン・ボス、デルフトなどの公式文書が一時的に見られなくなりました。NotuBiz は22日朝までの復旧を見込んでいると伝えられています。市議会の議題や資料を確認したい人は、この点を頭に入れておくと混乱せずに済みます。

6. 詐欺メール・偽サイトへの注意

騒ぎは詐欺の口実になりやすい

10月22日の時点で、今回の件に便乗した詐欺について、NCSC や DigiD からの具体的な警告は確認できませんでした。ただ、DigiD が止まったことは広く報じられており、「DigiD の再認証が必要です」「セキュリティ更新のため情報を確認してください」といった口実の詐欺が出てきやすい状況です。

消費者番組 Radar や Kassa の報道によれば、DigiD はメールや SMS でリンクや QR コードを送らないと案内しています。

怪しいサイン 例 取るべき行動
リンクや QR コードがある 「再有効化はこちら」 開かない。DigiD はリンクを送らない
急がせる 「24時間以内に確認」 手を止め、公式サイトに自分で入る
銀行の情報を求める 「返金のためログイン」 入力しない。銀行に連絡する
送信元が見慣れない 似た綴りのドメイン 削除し、Fraudehelpdesk に相談する
アプリの導入を求める 「修正アプリを入れて」 入れない。PHP の対応に利用者の作業は不要

この表の行動はどれも、連絡に含まれるリンクを使わず、自分で公式の入り口に行くという1つの原則に集約できます。ブックマークを使うか、検索して公式ドメイン(digid.nl、mijn.overheid.nl)を確かめてから入ってください。

もし入力してしまったら

DigiD の情報を入力してしまった場合は、DigiD の公式サイトから不正利用の窓口に連絡し、パスワードを変えます。銀行の情報を入力した場合は、すぐに銀行に電話します。被害の相談は、オランダの詐欺相談窓口 Fraudehelpdesk(フラウデヘルプデスク)でも受け付けています。

7. 自分のサイトのPHPバージョンを確かめる方法

方法の一覧

ここからは、自社や取引先のサイトを運営している人向けです。最初にやることは、サイトがどの版の PHP で動いているかを知ることです。次の表は、確かめ方を手軽な順に並べたものです。

方法 向いている人 注意点
レンタルサーバーの管理画面 共有サーバーの利用者 「設定した版」と「実際に動く版」が違う場合がある
WordPress のサイトヘルス WordPress の利用者 管理者権限が必要
他の CMS の管理画面 Drupal・Joomla など 「システム情報」に版が出ることが多い
制作会社・保守会社に聞く 運用を任せている人 「何系の何番か」まで聞く
サーバーでコマンドを打つ VPS・自前サーバー CLI と Web で版が違うことがある

表のどの方法でも、「8.3」のような系列だけでなく、「8.3.36」のように最後の番号まで確かめてください。修正済みかどうかは最後の番号で決まります。

レンタルサーバーの管理画面で見る

多くの共有レンタルサーバーでは、管理画面に「PHP バージョン設定」「PHP 設定」といった項目があります。ここで表示されるのは「8.3」のような系列だけのことが多く、細かい番号はホスティング会社の告知やサポートで確かめる必要があります。

また、ドメインやディレクトリごとに別の版を選べるサーバーでは、サイトごとに設定が違うことがあります。複数のサイトやサブドメインを持っている場合は、1つずつ確認します。

CMS の管理画面で見る

WordPress なら、管理画面の「ツール → サイトヘルス → 情報」を開き、「サーバー」の項目を見ると、実際に動いている PHP の版が表示されます。Web 経由で動いている版がそのまま出るので、最も確実な方法の1つです。

Drupal は「レポート → ステータスレポート」、Joomla は「システム → システム情報」で PHP の版を確認できます。どれも管理者の権限が必要です。

phpinfo() を公開したままにしない

PHP の設定をすべて表示する phpinfo() を書いたファイルを置けば、版はすぐに分かります。ただし、このページにはサーバーの構成や拡張機能、パスなど、攻撃の下調べに役立つ情報がそろっています。

使う場合は、推測されにくいファイル名にし、確認が終わったらすぐに削除してください。過去に置いたまま忘れている info.php や phpinfo.php がないかも、この機会に探しておくと安心です。同じ理由で、HTTP の応答ヘッダーに PHP の版を出す設定(expose_php)は、オフにしておくのが一般的です。

コマンドラインと Web の版の違い

VPS や自前のサーバーで php -v を打つと、コマンドライン用の PHP の版が表示されます。ところが、Web サーバーが使う PHP(PHP-FPM や Apache のモジュール)は、別のパッケージで、別の版のことがあります。

更新の後は、コマンドラインだけでなく、Web 経由で動いている版も確認し、PHP-FPM などの常駐プロセスを再起動したかどうかも確かめます。PHP の公式アドバイザリは、Apache に組み込む方式(mod_php)を最もリスクが高い構成として挙げています。

composer の platform 設定は「本番に合わせる」もの

composer(PHP の依存関係を管理する道具)には、config.platform.php という設定があります。これは、開発機の PHP の版に関係なく、「本番はこの版で動く」という前提で依存パッケージを選ぶための値です。

この値は、サーバーの PHP を更新するものではありません。サーバーを更新した後に、この値を本番の版に合わせておくと、開発環境と本番の食い違いを防げます。デプロイ先で composer check-platform-reqs を実行すると、本番の PHP が依存パッケージの要件を満たしているかを確かめられます。

DevNJ でも、10月22日に自社サイトのサーバーが 8.3.36 に更新されたことを確認し、composer の固定値を同じ版に合わせました。

8. WordPress などCMSを使っている場合

CMS の更新と PHP の更新は別のもの

WordPress のように PHP で書かれた CMS を使っている場合、注意したいのは、CMS 本体を最新にしても、今回の脆弱性は直らないという点です。今回の欠陥は PHP そのものにあり、直すには PHP を修正版に上げる必要があります。

NCSC オランダと veiliginternetten.nl(オランダ政府の安全なネット利用の啓発サイト)は、影響を受け得る製品の例として、WordPress、Joomla、Drupal、Zabbix、Roundcube を挙げています。Wiz のブログも、検証で Drupal と WordPress への攻撃が成立したと書いています。

確認すること どこで 目安
PHP の版 サイトヘルス、管理画面 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 以上
CMS 本体の版 管理画面のダッシュボード 最新の安定版
プラグイン・テーマ プラグイン一覧 更新があれば適用。使っていないものは削除
新しい PHP への対応 各プラグインの説明 8.3以上に対応しているか
バックアップ ホスティングの管理画面 更新の直前に取得できているか

この表のうち、PHP の版を上げるときに問題になりやすいのは、古いプラグインやテーマが新しい PHP で動かないケースです。更新の前にバックアップを取り、できれば検証用の環境で試してから本番に適用します。

PHP を上げる前の手順

  1. サイト全体(ファイルとデータベース)のバックアップを取る
  2. WordPress 本体、プラグイン、テーマを最新にする
  3. 長く更新されていないプラグインを洗い出し、代わりを探すか削除する
  4. 可能なら検証用のコピーで PHP を上げ、主要なページと問い合わせフォームを確かめる
  5. 本番の PHP を上げ、同じ確認を繰り返す
  6. サイトヘルスで、Web で動く版が修正版になったことを確かめる

9. ホスティングの形で変わる「誰が直すか」

責任の分かれ目

PHP を誰が更新するかは、サイトをどこに置いているかで変わります。共有レンタルサーバーなら、PHP 本体はホスティング会社が管理するのが一般的です。VPS や自前のサーバーなら、すべて自社(または委託先)の仕事です。

次の図は、代表的な3つの形について、層ごとの担当を整理したものです。実際の分担は契約で決まるので、自社の契約書やサービスの説明で確かめてください。

共有レンタルサーバーでは、PHP本体は業者、CMS本体と独自コードは自社が担当する。マネージドWordPressでは、PHP本体は業者、CMS本体は契約次第、独自コードは自社。VPSや自前サーバーでは、すべて自社が担当する。 共有レンタル マネージド VPS・自前 PHP本体 業者 業者 自社 CMS本体 自社 契約次第 自社 独自コード 自社 自社 自社 色つき=業者、灰色=自社(委託先含む)、点線=契約次第
図3:ホスティングの形ごとの一般的な担当の分かれ方。実際の分担は契約による(DevNJ 作成、2026年10月22日)

共有レンタルサーバーの場合

共有レンタルサーバーでは、利用者が PHP 本体を直接更新することはできません。やることは、ホスティング会社の告知(お知らせ、ステータスページ、メール)で、修正版に更新したかどうかを確かめることです。

告知が見当たらない場合は、サポートに「CVE-2026-109618 / 109619 の修正版(例:8.3.36)への更新は済んでいますか」と、番号を添えて問い合わせると話が早く進みます。veiliginternetten.nl も、ホスティング会社に PHP を更新するかどうかを尋ねるよう勧めています。

また、管理画面で選べる PHP の系列が古いまま(例:7.4 や 8.1)になっている場合、ホスティング側が修正しても、その系列には修正版が存在しないことがあります。系列を8.3以上に切り替えることが、利用者側でできる対策です。

ホスティングの形 自社でやること 確かめる先
共有レンタルサーバー 系列を新しくする、CMS を更新する 業者の告知・サポート
マネージド WordPress プラグイン・テーマの更新、動作確認 業者の告知、契約内容
VPS・クラウドのサーバー PHP の更新、常駐プロセスの再起動 OS のセキュリティ情報、PHP 公式
コンテナ・イメージ 土台のイメージを更新して作り直す イメージの提供元の告知
PHP を内蔵した機器 メーカーの更新を当てる メーカーの告知、NCSC の製品一覧

最後の行は見落とされがちです。NCSC オランダは、ネットワーク機器や業務用機器、IoT のダッシュボードなど、管理画面に PHP を使っている製品も影響を受け得るとして、該当製品の洗い出しを進めています。

10. サポート切れのバージョンからの移行

なぜ今回、古い版が問題になるのか

PHP の各系列は、公開から通常2年の通常サポートと、その後2年のセキュリティ修正の期間があります。期間が終わった系列には、今回のような深刻な欠陥が見つかっても、公式の修正版は出ません。

IPA の注意喚起は、サポート切れの版について、移行に加えて「そのシステムが本当に必要か、保守を続けられるか」まで見直すよう勧めています。今回の件は、サイトの棚卸しをする良い機会でもあります。

移行の進め方

段階 やること 目安の期間
1. 洗い出し サイト・サーバーごとに PHP の版を一覧にする 1日
2. 影響の確認 CMS・プラグイン・独自コードの対応状況を調べる 数日
3. 検証 検証用の環境で新しい版に上げて動作確認する 数日〜2週間
4. 本番の更新 バックアップを取り、作業時間を決めて切り替える 半日
5. 監視 エラーログと問い合わせを数日見守る 1週間

この表の期間は、小〜中規模の企業サイトを想定した目安です。独自に作り込んだシステムや、長く手が入っていないサイトでは、検証の段階が大きく延びることがあります。

なお、PHP 8.2 は php.net の Supported Versions によると2026年12月31日でセキュリティ修正が終わります(10月30日確認)。8.2 に上げて終わりにせず、8.3以上を移行先に選ぶのが現実的です。洗い出しや検証を外部に任せたい場合は、サービスの内容を見たうえで、サイトの数と PHP の版の一覧を添えてお問い合わせください。

移行までのあいだの暫定策

PHP 公式は、すぐに更新できない場合の暫定策を公開しています。セッションのアップロード進捗の機能を無効にする、メモリやPOSTの上限の設定を見直す、といった内容です。

ただし、PHP 公式も NCSC も、暫定策は特定の攻撃経路を狭めるだけで、完全な対策ではないと明言しています。NCSC は、暫定策を悪用されるとサービス停止(DoS)につながる恐れがあるとも書いています。暫定策は「移行までの時間を稼ぐもの」と位置づけ、移行の計画とセットで使ってください。

11. 侵害の兆候を確かめる

「更新したから終わり」ではない理由

NL Times によると、NCSC の副所長は、この欠陥が「ずっと前から」存在していた可能性に触れています。DutchNews.nl も、脆弱性は10年以上前から存在していたと伝えています。修正版を当てる前に何かが起きていなかったかは、別に確かめる必要があります。

英国 NCSC は、更新も停止もできない場合は、まず侵害やバックドアの痕跡を確認するよう求めています。JPCERT/CC の注意喚起も、更新とあわせて侵害の有無を調べることを推奨しています。

確認する項目

次の表は、JPCERT/CC と Wiz が挙げている兆候を、運営者が確かめやすい形に言い換えたものです。手口の詳細には触れず、ログやファイルで何を見るかだけを書きます。

見る場所 兆候 備考
Web サーバーのログ 不自然なファイル送信の直後に HTTP 500 が続く 単独では断定できない
PHP のエラーログ メモリ上限のエラーが急に増えた 正常な負荷でも起きる
セッションの Cookie 異常に長い、形の崩れた値が記録されている 記録していない環境も多い
プロセス PHP のワーカーが頻繁に落ちる・再起動する 監視の記録で確かめる
ファイル 見覚えのない PHP ファイル、更新日時の不自然な変化 アップロード用フォルダを重点的に
通信 サーバーから見覚えのない宛先への通信 ホスティング会社に相談

JPCERT/CC は、攻撃の経路が複数あるため1つの検知ルールでは捉えきれないこと、ログの残し方によっては痕跡が残らないこと、兆候が見つからなくても攻撃を受けていないとは断定できないことを注記しています。

疑わしいときの動き方

疑わしい兆候が見つかったら、ログやファイルを消したり上書きしたりせず、まず証拠を保全します。そのうえで、影響の範囲を調べ、必要ならサイトを一時的に外部から切り離します。共有レンタルサーバーの場合は、ホスティング会社のサポートに連絡するのが最初の一歩です。

個人情報を扱うサイトで、漏えいの恐れがある場合は、GDPR にもとづく報告の要否も検討が必要です。オランダでは、個人データの漏えいは原則として把握から72時間以内に AP へ報告する決まりがあります。判断に迷う場合は、専門家に相談してください。

12. 「止める」という判断をどう考えるか

政府が先に止めた理由

今回、オランダ政府は、攻撃を確認する前に自らのサイトを止めました。NCSC の警告文は、修正までのあいだ、インターネットに公開された PHP のシステムごとにリスクを評価し、必要なら停止を含む追加の措置を検討するよう求めています。

NL Times によれば、NCSC の副所長は「リスクを評価し、必要ならシステムを止めるのは各組織の判断だ」と述べ、オランダ国内に混乱(パニック)はないとも話しました。止めるかどうかは、被害が出たときの影響の大きさと、止めたときの不便さを比べて決めるものです。

サイトの性格 止める判断の重み 考え方の例
ログイン・個人情報を扱う 重い 修正までは止めるか、外部からの接続を絞る
問い合わせフォームがある 中くらい 修正の目処が数時間なら一時停止も選択肢
会社案内だけの静的に近いサイト 比較的軽い 業者の更新を待ちつつ監視する
業務システムの管理画面 重い 社外からの接続を遮断する

この表は考え方の例で、正解は組織ごとに違います。大事なのは、「止める」「止めない」を誰がどう決めるかを、事前に決めておくことです。次の章で、そのための更新体制を考えます。

13. 日本の発信と欧州の発信を比べる

IPA と JPCERT/CC の注意喚起

日本では、IPA が10月21日に事前準備を求める予告を出し、22日に本告知を公開しました。JPCERT/CC も22日に注意喚起(JPCERT-AT-2026-0033)を出し、侵害の兆候の確認項目を具体的に挙げています。

英国 NCSC は21日の修正版の後に通知を出し、全版が対象の可能性があるとして洗い出しから侵害確認までの手順を示しました。オランダ NCSC は修正版の前から、停止を含む準備を求めた点が目立ちます。

どの国の機関も「更新が唯一の根本策」「古い版は移行」という点では一致しています。日本と欧州の両方にサイトがある事業者は、どちらの情報を見ても、やることは同じです。違いが出るのはホスティング会社の更新の速さなので、拠点ごとに、どのサーバーで何の版が動いているかを一覧にしておくとよいでしょう。

14. 今後の更新体制をつくる

4段の仕組み

今回、数時間で復旧できた組織と、翌日まで止まった組織の差は、「どこで何が動いているかを把握していたか」と「更新の手順が決まっていたか」で生まれました。次の図は、小さな組織でも回せる更新体制を4段で示したものです。

1.把握でサイトとPHPの版を台帳にし、2.監視で公式の告知を受け取り、3.検証で検証環境で試し、4.適用で本番に当てて記録する。 1. 把握 台帳をつくる 2. 監視 告知を受け取る 3. 検証 検証環境で試す 4. 適用 当てて記録 緊急時は3を短くし、1と4の記録を残す
図4:小さな組織でも回せる更新体制の4段(DevNJ 作成、2026年10月22日)

段ごとにやること

段 やること 道具の例
1. 把握 サイト・サーバー・CMS・PHP の版・担当者を1枚の表にする 表計算シート
2. 監視 PHP 公式、NCSC、IPA/JPCERT、業者の告知を受け取る RSS、メール通知
3. 検証 本番のコピーで更新を試し、主要な画面を確認する 検証用サーバー
4. 適用 作業時間を決めて本番に当て、日時と版を記録する 作業記録
判断 緊急時に止めるかどうかを誰が決めるかを決めておく 連絡網

この表の「判断」の行が、今回いちばん差が出た部分です。止める判断をする人と連絡手段を決めておけば、警告が出たその日に動けます。

制作会社・保守会社との契約で確かめること

サイトの運用を外部に任せている場合は、契約に次の点が含まれているかを確かめます。

  • PHP や CMS のセキュリティ更新を、誰が、どのくらいの期間内に行うか
  • 緊急の脆弱性が出たときの連絡手段と、連絡の目安の時間
  • サイトを一時停止する判断を、誰がどの条件で下すか
  • サポート切れの版を使い続けている場合の、移行の提案と費用の扱い

15. ケースで考える(架空の例)

ここでは、立場ごとの考え方を3つの架空のケースで示します。実在の人物や企業ではありません。

ケース(架空) 状況 まずやること
デン・ハーグの日本食店 A さん 共有レンタルサーバーで WordPress、予約フォームあり サイトヘルスで版を確認し、業者の告知を見る
日本の部品メーカー B 社 欧州向けの英語サイトを制作会社に委託 制作会社に版と更新の予定を書面で聞く
アムステルダムの IT 企業 C 社 自前の VPS で独自システム、PHP 8.1 暫定策を当てつつ、8.3以上への移行計画を作る

A さんは PHP 本体が業者の担当なので、版の確認と、更新が確認できるまで予約フォームだけ止める選択肢を考えます。B 社はサイトの責任が自社にあるため、制作会社に「どの版で動き、いつ修正版にしたか」を聞いて記録に残します。C 社は 8.1 に正式な修正版がないので、暫定策で時間を稼ぎながら移行を急ぎ、公開している画面は接続元を絞ります。

16. やってはいけないこと

やってはいけないこと 理由
CMS を更新しただけで安心する 欠陥は PHP 本体にある。PHP の版を確かめる
phpinfo() のページを置いたままにする 攻撃の下調べに使われる情報がそろっている
暫定策だけで済ませる 公式が「完全な対策ではない」と明言している
8.2.35 に上げて終わりにする 8.2は2026年末でセキュリティ修正も終わる
コマンドラインの版だけ確かめる Web で動く PHP は別の版のことがある
痕跡が見つからないので安全と判断する ログが残らない場合もあり、断定はできない
便乗メールのリンクから確認する 公式の入り口に自分でアクセスする

この表のうち、上の3つは今回の件で特に起きやすい誤解です。「CMS は最新だから大丈夫」という判断は、今回に限っては当てはまりません。

17. チェックリスト

在住者として

  • DigiD・MijnOverheid には、ブックマークか検索から公式ドメインで入っている
  • DigiD を名乗るメールや SMS のリンクを開いていない
  • 期限のある手続きがサイトの停止で遅れた場合、日時を記録した
  • 「修正のためのアプリ」を入れるよう求める連絡を無視した

サイトの運営者として

  • 自社のすべてのサイトについて、PHP の版を最後の番号まで確かめた
  • 修正版(8.5.12 / 8.4.27 / 8.3.36 / 8.2.35)以上になっている
  • 共有サーバーの場合、業者の告知で更新を確かめた
  • 管理画面で選べる系列が8.3以上になっている
  • Web で動く版を、サイトヘルスなどで確かめた
  • phpinfo() のファイルが残っていない
  • 8.1以前のサイトについて、移行の計画と期限を決めた
  • ログで侵害の兆候を確かめた
  • PHP を内蔵した機器(ルーター、NAS など)のメーカーの告知を確かめた
  • 緊急時にサイトを止める判断を誰がするかを決めた
  • 制作会社・保守会社との契約で、更新の担当と期限を確かめた
  • サイト・サーバー・版・担当者の台帳をつくった

18. まとめ

  • 2026年10月21日、NCSC が PHP の深刻な脆弱性2件(CVE-2026-109618 / 109619)を警告し、DigiD・MijnOverheid・下院などのサイトが予防的に止まりました。DigiD と MijnOverheid は同日夜に復旧したと報じられています。
  • 修正版は PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 です。8.1以前には正式な修正版がなく、8.2も2026年12月31日でサポートが終わります。
  • 10月22日時点で積極的な悪用は確認されていませんが、公開済みの実証コードがあり、探索の通信も報じられています。影響する古い版の範囲や発見の経緯には、資料によって幅があります。
  • 在住者が個人として端末に何かをする必要はありません。注意すべきは、便乗した詐欺メールや偽サイトです。
  • サイトを持っている人は、管理画面やサイトヘルスで PHP の版を最後の番号まで確かめ、共有サーバーなら業者の更新状況を確認します。
  • 更新の後も、ログで侵害の兆候を確かめ、台帳・監視・検証・適用の更新体制を整えておくと、次の警告のときに数時間で動けます。

参考にした情報源

一次情報(当局・開発元)

10月30日の更新で追加した情報源

発見者・技術情報

報道

初出の情報源は2026年10月22日に、「10月30日の更新で追加した情報源」は2026年10月30日に確認したものです。IamExpat・DutchReview・Expatica でもこの件の記事を探しましたが、確認の時点では見つかりませんでした。状況は日々更新されるため、対応の前に各機関の最新の発表を確かめてください。

よくある質問

PHP2Shellとは何ですか?
2026年10月21日に修正版が公開された、PHPの2つの深刻な脆弱性(CVE-2026-109618とCVE-2026-109619)の通称です。悪用されると、ログインなしの外部からの要求でWebサーバー上の任意のコードを実行される恐れがあります。修正版は PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 です。
DigiDやMijnOverheidは今使えますか?
NOSの報道では、MijnOverheid は10月21日18時11分、DigiD のサイトは20時27分に復旧しました。overheid.nl は22日朝の更新時点でも停止中とされ、その後の復旧日は10月30日時点で確認できませんでした。使えないときは公式サイトに自分で入り、急ぎの手続きは担当機関に電話してください。
この件で、在住者が個人として何かする必要はありますか?
PHPはサーバー側の技術なので、パソコンやスマホに更新を入れる必要はありません。気をつけたいのは、騒ぎに便乗した詐欺メールやSMSです。DigiDを名乗る連絡に含まれるリンクは開かず、ブックマークか検索から公式サイトに入ってください。
自分のサイトのPHPバージョンはどう確かめればよいですか?
レンタルサーバーの管理画面のPHP設定、WordPressなら「ツール → サイトヘルス → 情報 → サーバー」で確認できます。コマンドラインの php -v はWebで動く版と違うことがあるので注意してください。phpinfo() を置いて確かめた場合は、確認後すぐに削除します。
PHP 8.1以前を使っているサイトはどうすればよいですか?
PHP 8.1以前は公式サポートが終わっており、今回の正式な修正版は出ていません。7.4・8.0・8.1向けに最小限のソース修正は公開されましたが、根本策はサポート中の版(8.2以上、できれば8.3以上)への移行です。8.2も2026年12月31日でサポートが終わります。
攻撃はもう起きていますか?
はい、悪用の動きが確認されています。10月26日に米CISAが両CVEを悪用確認済みの脆弱性(KEV)に加え、24日にはハニーポットで実際にシェルが動いたと研究者が報告しました。一方、実在サイトが侵害されたという当局の発表は確認できませんでした。更新を急いでください。

日本と欧州の両方で機能するサイトをお考えですか?

無料で相談する

目次