PHPの脆弱性「PHP2Shell」、レンタルサーバーのWordPressブログは何をすればいい？自動で直ったものと自分で確かめること

10月21日の夜、日本の役所や銀行、鉄道会社のサイトが次々に止まりました。原因は、Webサイトを動かすプログラミング言語「PHP」に見つかった重大な欠陥で、海外では「PHP2Shell」と呼ばれています。

ニュースでは国税庁やコドモン、pixivといった大きな名前ばかりが並びましたが、実はこの話は、レンタルサーバーでWordPressのブログを書いている個人にもそのまま関係します。WordPressはPHPで書かれているからです。

このブログ「日曜電遊劇場」も、エックスサーバーというレンタルサーバーの上で、WordPressを使って動いています。つまりPHPで動いているサイトのひとつです。

この記事では、同じようにレンタルサーバーでWordPressを使っている人に向けて、「サーバー会社が自動で直してくれたもの」と「自分で確かめたほうがいいもの」を分けて整理します。管理画面の操作は、エックスサーバーとWordPressの公式マニュアルで確認できた手順だけを書いています。

先に結論を書いておくと、次の5つです。

なお、PHP2Shellそのものの技術的な中身や、日本で何が止まったか、AIが欠陥を見つけるようになった背景などは、同じ時期に書いた関連記事で詳しく扱っています。この記事では、ブログを持っている人が「結局、自分は何をすればいいのか」に絞って書きます。

PHP2Shellとは何だったのか（ブログを持つ人向けの最小限）

まずは、何が起きたのかを最小限だけ押さえておきます。PHPは、Webサイトの裏側で動くプログラミング言語です。

ブラウザでページを開くと、サーバーの中でPHPのプログラムが動き、記事の本文やメニュー、コメント欄などを組み立ててから送り返します。WordPressはこのPHPで書かれたソフトなので、WordPressのブログを開くたびに、サーバーの中ではPHPが動いています。

今回問題になったのは、WordPressやプラグインのような「PHPで書かれたソフト」ではなく、PHPそのもの、つまりPHPのプログラムを読んで実行する土台の部分でした。この土台のことを「インタプリタ（プログラムを読みながら実行する本体）」と呼びます。

土台に穴があると、その上で動くWordPressをどれだけ最新にしていても、穴そのものは塞がりません。ここが今回の騒ぎを大きくした理由のひとつです。

見つかった欠陥は、まず2件です。どちらも「認証不要のリモートコード実行（RCE）」につながるとされました。

深刻さを表す点数（CVSS、0〜10で欠陥の深刻さを示す共通の物差し）は、資料によって数字が違います。CVE番号を割り当てた窓口（CNA）はCVSS v4.0で9.2、アメリカの脆弱性データベースNVDはv3.1で9.8、Red Hatはv3.1で8.1としています。

どれも「重大」の範囲で、物差しの版や評価する立場で数字が変わっている、と受け止めておけば十分です。

下の表は、10月24日時点でわかっている3件をまとめたものです。CVE番号は、世界共通で欠陥に振られる通し番号です。

表の「メモリ」は、サーバーが作業中のデータを一時的に置いておく机のような場所だと考えてください。1件目は、机の上が散らかったまま作業が中断され、片付け係がその散らかった状態を正しいものとして扱ってしまう欠陥です。

2件目は、前のお客さんのために使ってもう返却したはずの机のメモを、次のお客さんの作業でうっかり読んでしまう欠陥です。どちらも、攻撃者がこの「ずれ」を狙ってうまくデータを仕込むと、サーバーに命令を実行させられる可能性があるとされました。

影響を受けるのは、Webリクエストを処理するPHP全般です。PHPをWebサーバーにつなぐやり方にはいくつか種類があり、次のものなどが挙げられています。

• PHP-FPM（PHPを別の常駐プログラムとして動かす方式）
• mod_php（ApacheというWebサーバーの中にPHPを組み込む方式）
• php-cgi、FrankenPHP、LiteSpeedなど

このうちmod_phpが最もリスクが高いとされました。レンタルサーバーがどの方式を使っているかは会社ごとに違いますが、利用者が自分で選べることは少なく、ブログを書く側が気にする必要があるのは「自分の使っているサーバーが直したかどうか」です。

欠陥を見つけて報告したセキュリティ企業のWizは、WordPress・Drupal・Joomlaという代表的なCMS（記事を書いて公開するためのソフト）の最新版を入れた検証環境で、ログインなしにRCEが成立することを実証したと説明しています。また、RCEにまで至らなくても、サーバーのメモリから機密情報を読み取れる場合があることも示しました。WordPressのブログが「関係ない」とは言えない理由は、ここにあります。

規模の大きさも、騒ぎが広がった理由です。PHPは世界のWebサイトの約7割で使われているとされます。インターネット上の機器を調べるCensysの調査では、分析した約260万台のうち約150万台が、修正版の出ていない古いPHPのバージョンを名乗っていました。

もちろん、サーバー会社が独自に修正を当てている場合もあるので、この数字がそのまま「穴が開いているサーバーの数」ではありません。それでも、古いPHPがそれだけ広く使われ続けていることは確かです。

悪用は「試み」が多く、「侵入成功」の公式確認はまだ

ブログを持つ人がいちばん気になるのは、「もう攻撃されているのか」という点だと思います。ここは、「攻撃を試みた形跡が見つかった」という話と、「実際に侵入に成功したことが確認された」という話を分けて読む必要があります。

試みのほうは、たくさん報告されています。

• Amazonは、おとりのサーバー（ハニーポット）で、修正版が公開される4日前の10月17日には悪用の試みを観測していました。
• Cloudflareは、修正版の公開前に数千件、公開後には数百万件の試行を見たと報告しています。
• PatchstackやHadrianも、修正版の公開前から試行を観測したとしています。
• watchTowrは10月21日以降、自社のハニーポットで実際の悪用を観測したと説明しています。
• Hunt.ioは、Mirai型と呼ばれるIoT機器向けの乗っ取りプログラムが、この欠陥を広がる手段に加えたとみています。

一方で、アメリカの政府機関CISAが管理する「悪用が確認された脆弱性のカタログ（KEV）」には、10月24日14時時点で3件とも登録されていません。セキュリティの情報を発信するSANS ISCやSansecは、公開された攻撃コードには前提条件が多く、大量に悪用される状況にはなりにくいとみています。そして、どこかのサイトへの侵入成功を公式に確認したという報告は、今のところ見当たりません。

共用のレンタルサーバーでは、その「直す」作業の大部分をサーバー会社が引き受けてくれています。どこまでがサーバー会社の仕事なのかを、次に整理します。

WordPressのブログは、どこでPHPとつながっているのか

レンタルサーバーでWordPressを使っていると、PHPを意識する場面はほとんどありません。ドメインを取って、サーバー会社が用意しているインストール機能でWordPressを入れれば、あとは管理画面で記事を書くだけで済みます。

けれど、その裏では何層にも重なったソフトが動いています。どこまでをサーバー会社が面倒を見ていて、どこからが自分の持ち分なのかを知っておくと、今回のようなニュースを見たときに慌てずに済みます。

ざっくり分けると、レンタルサーバーのWordPressブログは次の4つの層でできています。

表のとおり、今回の欠陥があった「PHP本体」は、共用レンタルサーバーではサーバー会社が修正を当てる層です。利用者はサーバーの管理者権限を持っていないので、PHPのプログラムを自分で入れ替えることはそもそもできません。

そのかわり、サーバー会社が用意した複数のPHPバージョンの中から、どれを使うかを選ぶことはできます。エックスサーバーなら、サーバーパネル（契約しているサーバーの設定画面）で、ドメインごとにPHPのバージョンを切り替えられます。

ここで気をつけたいのは、「PHPのバージョンを選ぶ」のは利用者の仕事だという点です。サーバー会社は、利用者が選んでいる古いバージョンにも、できる範囲で修正を当ててくれます。ただし、古いバージョンほど開発元からの修正が出ないため、サーバー会社が自分たちで手当てをすることになり、そのぶん時間がかかったり、範囲が限られたりします。

今回のエックスサーバーの対応でも、新しいバージョンから順に修正が終わり、最も古いPHP 5.1〜5.5は10月23日の時点でも作業が続いていました。この話は次の節で詳しく見ます。

VPSや自分で建てたサーバーは、話が別

ここまでの話は、複数の利用者で1台のサーバーを分け合う「共用レンタルサーバー」の場合です。VPS（仮想専用サーバー。1台の物理サーバーを区切って、自分専用のサーバーのように使えるサービス）や、クラウドに自分で建てたサーバーでWordPressを動かしている場合は、PHP本体の更新も利用者の仕事になります。

実際、エックスサーバーは今回のお知らせで、レンタルサーバー（エックスサーバー、XServerビジネス、XServer for WordPress）については急いでPHPを変更する必要はないとしたうえで、XServer VPSについては、会社側でPHPへの修正を適用していないため、利用者自身でOSやPHPを確認し、修正版への更新などをするよう案内しています。同じ会社のサービスでも、共用サーバーかVPSかで、だれが直すかがはっきり分かれているわけです。

さくらインターネットも、予防のための緊急メンテナンスを行う一方で、さくらのVPSはサービスを提供する部分でPHPを使っていないため影響はないと案内していました。これは「VPSを提供する仕組みそのもの」の話で、利用者がVPSの中に自分で入れたPHPは、やはり利用者が更新する必要があります。

VPSでブログを動かしている人は、使っているOSの更新情報を見て、PHPが修正版（8.5.12 / 8.4.27 / 8.3.36 / 8.2.35、またはOSの配布元が出した修正入りのもの）になっているかを確かめてください。

WordPressの「中身」は、利用者の持ち分

反対に、WordPress本体やプラグイン、テーマは、共用レンタルサーバーでも利用者の持ち分です。サーバー会社がPHPを直してくれても、プラグインに別の欠陥が残っていれば、そこから入られる可能性は消えません。

今回の騒ぎはPHP本体の話でしたが、WordPressのサイトが乗っ取られるきっかけとしては、古いプラグインやテーマ、使い回したパスワードのほうがよほど身近です。

WordPressの公式ドキュメントでも、安全性を高める方法として、WordPress本体とプラグイン・テーマを最新に保つこと、使っていないプラグインやテーマを削除すること、強くて使い回さないパスワードを使うこと、二段階の認証を使うこと、定期的にバックアップを取ることが挙げられています。また、サーバー会社がどこまでのセキュリティ作業を引き受け、どこからが利用者の仕事なのかを確かめておくように、とも書かれています。今回の騒ぎは、まさにその「境目」を確かめるよい機会になりました。

この記事の後半では、利用者の持ち分であるPHPバージョンの選択、プラグインとテーマの更新、管理画面の守り、バックアップを順に見ていきます。その前に、サーバー会社が実際に何をしたのかを、エックスサーバーの公表内容で確認しておきます。

レンタルサーバーでは、何が自動で直ったのか

共用レンタルサーバーの利用者にとって、いちばん大事なのは「自分のサーバーにはもう修正が当たったのか」です。ここでは、このブログが使っているエックスサーバーの公式のお知らせをもとに、10月21日から23日までの動きを整理します。ほかのサーバー会社を使っている人も、自分の会社のお知らせを読むときの見方の参考にしてください。

エックスサーバーは、10月21日に修正版が公開される予定だったことを受けて、まず自社と利用者の環境に、不正アクセスのリスクを下げる緩和策（修正版が出るまでの間、攻撃を通りにくくする応急の設定）を当てました。そのうえで、予防のための安全対策として、公式サイトや管理画面などへのアクセスを止めています。

お知らせでは、この停止は不正アクセスが起きたための対応ではないこと、利用者のサーバーは動き続けていて、Webサイトの表示やメールの送受信には影響がないことが説明されていました。

お知らせに書かれていた時刻を、表にまとめます。時刻はすべて日本時間です。

表を見ると、新しいPHPから順に修正が終わっているのがわかります。PHP 8.2〜8.5は、PHPの開発元が出した修正版をそのまま使えるので、公開から数時間で適用が終わりました。

PHP 7.4〜8.1は、開発元からは最小限のソースの修正（プログラムの元になる文章の差分）しか出ていないため、それをサーバー会社が自分のPHPに組み込む手間がかかり、半日ほど遅れています。さらに古いPHP 5.6〜7.3や5.1〜5.5には開発元の修正そのものがないので、サーバー会社が独自に手当てをすることになり、いちばん後回しになりました。

この順番は、エックスサーバーに限らず、どのサーバー会社でも似たような形になると考えられます。古いPHPを使い続けていると、こうした緊急のときに「自分のサイトは最後まで直らない」側に回りやすい、ということです。ふだんは古いPHPでも何の問題もなく動いているので気づきにくいのですが、今回のような騒ぎのときに差が出ます。

利用者に求められていること

エックスサーバーは、レンタルサーバー（エックスサーバー、XServerビジネス、XServer for WordPress）の利用者に対して、現時点で急いでPHPを変更する必要はないと案内しています。ただし、利用状況によっては追加の対策をお願いする場合があり、その場合は改めて知らせる、としています。状況はお知らせのページと公式Xアカウントで随時更新されるとのことでした。

つまり、エックスサーバーの共用サーバーを使っている人が今やるべきことは、「お知らせを確認して、自分あての追加のお願いが来ていないかを見ておく」ことです。サーバー会社からの重要なお知らせは、契約時に登録したメールアドレスにも届くことが多いので、ふだん見ていないメールアドレスを登録している人は、この機会に受信箱を確かめておくとよいと思います。

停止していたサービスは、10月23日16時20分の時点で、サービスサイト、サポートサイト、アカウント管理画面、WEBメール、ファイルマネージャ、新規申込、契約更新や支払いの手続き、問い合わせフォームなどが再開していました。

一方で、サーバーパネルの一部の機能はメンテナンス中で、再開直後にアクセスが集中したため、サーバーパネルが表示されない、あるいは表示が遅い状態が続いているとも案内されていました。この記事で紹介する手順を試すときに画面が開きにくい場合は、少し時間を置いてから試してください。

ほかのサーバー会社の動き

ほかのサーバー会社も、多くが同じように予防のために管理画面などを止めました。piyologの集計では、国内で告知や報道により確認できた246組織がサービスの停止などを行い、その中にはエックスサーバーのほか、heteml、ムームードメイン、カラーミーショップ、ConoHa WINGなどのホスティング事業者も含まれていました。さくらインターネットは、21日22時30分から予防的な緊急メンテナンスに入り、22日8時15分から順次再開しています。

ここで注目したいのは、多くのサーバー会社が止めたのは「管理画面や申込画面などの、会社自身が運営するシステム」だった点です。会社のシステムもPHPで動いていることが多く、修正が終わるまでは、自分たちのシステムが攻撃の入り口にならないように止めた、という判断です。利用者のサイトの表示は止めずに動かし続けた会社が多く、エックスサーバーも、停止の間も利用者のサイトの表示やメールには影響がないと案内していました。

この「予防のために止める」という判断の意味や、止めた組織と止めなかった組織の違いについては、関連記事「日本で何が止まったか」で詳しく書いています。ブログを持つ人として押さえておきたいのは、管理画面に入れない時間があっても、それは多くの場合「サイトが攻撃された」という意味ではない、ということです。慌ててサイトを消したり、サーバーを解約したりする必要はありません。

表示されるバージョン番号だけでは、修正済みか判断できない

先ほど紹介したCensysの「約150万台が修正版のないバージョンを名乗っていた」という数字も、この点で注意が必要です。名乗っている番号が古くても、中身は直っているサーバーもあれば、本当に直っていないサーバーもあります。外から見るだけでは区別がつきません。

共用レンタルサーバーの利用者にとって確実なのは、番号を見て判断するのではなく、サーバー会社が出している「どのバージョンに修正を当て終えたか」のお知らせを確認することです。エックスサーバーの場合は、お知らせの中に、PHPのバージョンごとの適用状況の表が載っていました。

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

サーバー会社が修正を当ててくれたとしても、自分のサイトがどのPHPバージョンで動いているかは、一度確かめておく価値があります。理由は2つあります。

• 古いバージョンほど修正が遅れたり、そもそも開発元の修正がなかったりすること。
• PHPには「更新が続く期間」があり、それを過ぎたバージョンは、今後また別の欠陥が見つかったときに、ますます直りにくくなること。

確かめる方法は2つあります。サーバーの管理画面で見る方法と、WordPressの管理画面で見る方法です。どちらか片方で十分ですが、両方で同じ番号が出るかを見ておくと、設定の食い違いにも気づけます。

方法1：エックスサーバーのサーバーパネルで見る

エックスサーバーの公式マニュアルによると、PHPのバージョンの確認と切り替えは、サーバーパネルの「PHP Ver.切替」という項目で行います。現在の新しいサーバーパネルでの手順は、次のとおりです。

1. サーバーパネルにログインし、「PHP Ver.切替」をクリックします。
2. 確かめたいドメインの右側にある、ペンの形のアイコンをクリックして編集画面を開きます。
3. 画面に現在のバージョンが表示されるので、それを確認します。
4. 切り替えたい場合は、「変更後のバージョン」から希望のバージョンを選び、「設定する」をクリックします。

確認だけなら、3まで進んで画面を閉じれば大丈夫です。古いサーバーパネルを使っている場合は、ペンのアイコンを押す手順がなく、「PHP Ver.切替」を開いたあとに現在のバージョンを確かめ、「変更後のバージョン」を選んで「変更」をクリックする流れになると、マニュアルに書かれています。

設定はドメインごとなので、複数のドメインでブログを運営している人は、それぞれ確かめてください。

マニュアルには、選べるバージョンの一覧と、それぞれの説明も載っています。10月24日時点のマニュアルの主な説明は、次のとおりです。

• PHP 8.5.xに「WordPress推奨バージョン」という説明が付いていました。
• PHP 8.2.xは「旧バージョン」とされ、今後のバージョンアップ予定がないため新しく使うことは勧めない、という趣旨の注意書きがあります。
• PHP 5.4.x以下も旧バージョンとされ、影響の大きい脆弱性を中心に、OSの配布元のパッチによるセキュリティ修正だけが行われる、と説明されていました。
• どのバージョンでもFastCGI（PHPを効率よく動かす仕組み）とOPcache（PHPのプログラムを一時保存して速くする仕組み）が標準で有効になっている、とも書かれています。

方法2：WordPressの「サイトヘルス」で見る

サーバーパネルにログインするのが面倒な場合や、エックスサーバー以外のサーバーを使っている場合は、WordPressの管理画面からも確かめられます。WordPressには「サイトヘルス」という、サイトの健康診断のような画面があります。WordPressの公式ドキュメントでは、管理画面の「ツール」から「サイトヘルス」を開く場所が案内されています。

サイトヘルスには「ステータス」と「情報」の2つのタブがあります。

• 「ステータス」タブには、WordPressの構成について重要なことと、注意が必要な項目が、深刻さの順に「致命的な問題」「おすすめの改善」「問題のない項目」の3つに分けて表示されます。
• 「情報」タブは、サイトの技術的な情報を詳しく並べた画面です。WordPress、ディレクトリとサイズ、現在のテーマ、使用中のプラグイン、サーバー、データベースなどの欄に分かれていて、PHPのバージョンなどのサーバー設定に関する情報は「サーバー」の欄にまとめて表示されます。

PHPのバージョンが古すぎる場合は、「ステータス」タブに「更新が必要な古いバージョンのPHPで動いている」という趣旨の警告が出ることが、公式ドキュメントで紹介されています。この警告はセキュリティの分類に入れられているので、出ていたら優先して対応したい項目です。

「情報」タブの画面は表示専用で、ここから設定を変えることはできません。また、画面の情報をまとめてクリップボードにコピーする機能もあるので、サーバー会社に問い合わせるときに、この内容を貼り付けて送ると話が早く進みます（パスワードなどは含まれませんが、サーバーの場所などの情報は含まれるので、公開の場所には貼らないようにしてください）。

PHPのバージョンには「寿命」がある

確かめた番号が新しいのか古いのかは、PHPの開発元が公開している「サポートされているバージョン」の表で判断できます。PHPの各バージョンは、公開から2年間は不具合の修正も含めた通常の更新（アクティブサポート）、その後の2年間はセキュリティの修正だけ（セキュリティサポート）が行われ、合わせて4年で更新が終わる決まりになっています。10月24日時点の状況は次のとおりです。

表のとおり、PHP 8.1以前は、開発元からの更新がすでに終わっています。今回、PHPの開発元はPHP 8.2〜8.5向けには正式な修正版を出しましたが、PHP 7.4・8.0・8.1向けには最小限のソースの修正を出すにとどまり、それより古いバージョンには何も出していません。

PHPの公式サイトでも、PHP 8.1以前は開発元からの更新を受けられないので、利用している配布元や事業者に修正の提供を相談するように、と案内されています。共用レンタルサーバーで古いPHPを使っている人のサイトが直ったのは、サーバー会社がその手間を引き受けたからです。

WordPressの側も、公式の推奨環境としてPHP 8.3以上を挙げています。PHP 7.4以上でも動くとはしていますが、それらは更新が終わっていてサイトがセキュリティ上の欠陥にさらされる可能性があるので、上げることを強く勧める、という書き方です。エックスサーバーが8.5.xを「WordPress推奨」としているのも、こうした流れに沿ったものだと考えられます。

PHPを切り替える前に確かめること

では、古いPHPを使っていたら、すぐに切り替えればいいのかというと、そこは少し慎重になったほうが安全です。PHPのバージョンを上げると、古い書き方をしているプラグインやテーマが動かなくなったり、画面が真っ白になったりすることがあるからです。特に、何年も前に入れたまま更新されていないプラグインや、自分で手を加えたテーマを使っている場合は、注意が必要です。

切り替える前には、次の順番で準備しておくと、もしものときに戻しやすくなります。

1. WordPress本体、プラグイン、テーマを、先に最新の状態に更新しておきます。新しいPHPへの対応は、たいていプラグインやテーマの新しい版で行われています。
2. 使っていないプラグインやテーマは、この時点で削除しておきます。動作確認の手間が減り、穴の数も減ります。
3. バックアップを取っておきます（後半の節で、エックスサーバーの自動バックアップの使い方を紹介します）。
4. 人の少ない時間帯に切り替え、すぐにトップページ、記事ページ、管理画面、問い合わせフォームなどを一通り開いて確かめます。
5. 表示がおかしくなったら、同じ「PHP Ver.切替」の画面で元のバージョンに戻します。

エックスサーバーのPHPの切り替えはドメインごとに設定できるので、メインのブログとは別に、試し用のドメインやサブドメインを持っている人は、先にそちらで試すという手もあります。いずれにしても、今回エックスサーバーは「急いで変える必要はない」と案内しているので、今日あわてて切り替えるよりも、年内に落ち着いて準備をして上げる、くらいの計画で十分だと思います。

特にPHP 8.2を使っている人は、12月31日で開発元の更新が終わるので、年内に8.3以上へ上げる予定を立てておくとよいでしょう。

3件目の欠陥と「session.upload_progress.enabled」

10月23日、PHPの開発元は、3件目の欠陥（CVE-2026-115560）についての告知を出しました。修正版はまだなく、次の定例のバグ修正リリースで直す予定です。それまでの暫定策として示されたのが、PHPの設定ファイルに「session.upload_progress.enabled=0」と書くことでした。

ニュースやSNSでこの設定の名前を見て、「自分のブログでもやらなければいけないのか」と気になった人もいると思います。この節では、この設定が何なのか、共用レンタルサーバーの利用者はどうすればいいのかを整理します。

「セッション」と「アップロード進捗」とは

まず言葉の説明からです。「セッション」とは、Webサイトが訪問者ひとりひとりを見分けて、ページをまたいで情報を覚えておくための仕組みです。たとえば通販サイトで、別のページに移ってもカートの中身が消えないのは、セッションで「この人のカートにはこれが入っている」と覚えているからです。

「アップロード進捗」は、PHPのセッションに付いている機能のひとつです。大きなファイルをアップロードしているとき、その途中経過（何パーセント送ったか）をセッションに書き込んでおき、別のリクエストから進み具合を確かめられるようにするものです。

PHPの公式マニュアルによると、この機能を有効にするかどうかを決めるのが「session.upload_progress.enabled」という設定で、初期値は「1」（有効）です。「0」にすると、進み具合の記録が止まるだけで、ファイルのアップロード自体はふつうにできます。

3件目が当てはまるのは、限られた設定のとき

PHPの開発元の告知によると、3件目の欠陥でRCEにつながるのは、次の条件がそろったときです。

• アプリが、セッションのデータを保存するときの形式（シリアライズ方式。データを文字の並びに変えて保存するやり方）を、設定では「php_binary」か「php_serialize」にしておきながら、プログラムの実行中に「php」へ切り替えてからセッションを開始している。
• そのうえで、アップロード進捗の機能が有効のままになっている。

開発元は、実行中にこの保存形式を切り替えないアプリであれば、アップロード進捗の機能は有効のままでかまわない、としています。また、10月21日の告知で示されていた緩和策（2件目の欠陥向けにこの設定を0にするもの）をすでに当てている場合は、そのままにしておけば追加の対応は要らない、とも書かれていました。

WordPressの場合はどうでしょうか。WordPress本体は、PHPのセッションを使う前提では作られていません。

WordPressの公式ドキュメントによると、サイトヘルスの「ステータス」には、PHPのセッションが動いていることを見つけると「有効なPHPセッションが検出された」という趣旨の警告を出す項目があり、セッションが動いているとREST API（外部のアプリとWordPressがやり取りするための窓口）や、サイトが自分自身に送るリクエストの邪魔になる、と説明されています。

つまりWordPress本体だけなら、3件目の条件に当てはまる可能性は低いと考えられます。ただし、プラグインの中にはセッションを使うものもあり、それが保存形式を切り替えているかどうかは、ブログを書く側が中身を読んで判断するのは難しいところです。

共用サーバーの利用者が、自分で設定できるものではない

では、念のために自分で「0」にしておけばいいのかというと、共用レンタルサーバーではそう簡単ではありません。PHPの公式サイトの10月21日の告知では、この設定はphp.ini（PHP全体の設定ファイル）や、PHP-FPMのプール設定、Webサーバーの設定に書いたうえで、PHPの作業用のプログラムをすべて再起動するように、とされています。

そして、プログラムの中から設定を変えるやり方（ini_set）や、PHP-FPMで使われる「.user.ini」というファイルに頼ってはいけない、と書かれています。PHPのマニュアルでも、この設定は「INI_PERDIR」という種類、つまりプログラムの実行中には変えられない種類に分けられています。

エックスサーバーには、サーバーパネルに「php.ini設定」という機能があり、ドメインごとにPHPの設定を変えたり、「php.ini直接編集」から設定ファイルを直接書き換えたりできます。ただ、公式マニュアルの「php.ini設定で設定可能な項目」の一覧を見ると、セッション関係で変えられる項目は、session.use_cookies、session.name、session.cookie_lifetimeなど7つで、session.upload_progress.enabledは載っていません。

また、エックスサーバーの「Xアクセラレータ Ver.2」（サイトを速く安定させるための機能）を使っている場合は、ドメインのフォルダに「.user.ini」が作られてphp.iniの代わりに働く、とマニュアルで説明されています。PHPの開発元が「.user.iniに頼ってはいけない」としているのは、まさにこのファイルです。

中途半端に設定をいじって「対策したつもり」になるよりも、サーバー会社の案内を待つほうが確実です。エックスサーバーも、利用状況によっては追加の対策をお願いする場合がある、と案内しているので、もし必要になれば、そのときにやり方も含めて知らせてくれるはずです。

ブログを持つ人がやっておくこと

3件目について、共用レンタルサーバーでWordPressを使っている人がやっておくとよいことは、次の3つです。

• サーバー会社のお知らせと、登録メールアドレスに届く連絡を見ておく。3件目への対応や、利用者へのお願いがあれば、そこに出ます。
• 設定ファイルを自分で書き換える前に、サーバー会社のマニュアルで「その項目が変えられるか」「どこに書けば効くか」を確かめる。載っていない項目は、問い合わせてから触る。
• 次の定例リリースでPHPの修正版が出たら、サーバー会社がそれを当てたかどうかを、お知らせで確かめる。

一方、VPSや自分で建てたサーバーでWordPressを動かしている人は、PHPの開発元の案内どおり、php.iniなどに「session.upload_progress.enabled=0」を書いて、PHP-FPMやApacheを再起動するのが基本の対応になります。PHP 8.5を使っている場合は、10月21日の告知で、2件目の欠陥向けに「fatal_error_backtraces=0」も合わせて設定するように案内されていました。

この設定は、エラーが起きたときに詳しい経路を記録する機能を止めるもので、2件目の欠陥の確認された経路のひとつになっていました。なお、エラーを画面に表示しない設定（display_errorsなど）にしても、この欠陥の対策にはならないとされています。

どちらにしても、こうした設定はあくまで「修正版が出るまでのつなぎ」です。PHPの開発元も、2件目までについては修正版への更新だけが完全な対策で、緩和策は危険を減らすものの安全にするものではない、と書いています。最終的には、修正版を当てる（共用サーバーなら、サーバー会社に当ててもらう）ことが答えになります。

WordPress本体・プラグイン・テーマの更新

PHP本体の修正はサーバー会社に任せられても、WordPressの中身は利用者の持ち分です。今回の騒ぎのあと、PHP2Shellに便乗して古いプラグインの欠陥を狙う動きが出ないとも限りません。ここでは、WordPressの更新の仕組みを、公式ドキュメントで確かめられた範囲で整理します。

WordPress本体の小さな更新は、既定で自動

WordPressの公式ドキュメントによると、既存のサイトでは、WordPress本体の小さな更新（不具合の修正やセキュリティの修正のための「マイナー更新」、たとえば6.8.1から6.8.2への更新のようなもの）は、既定で自動的に当たるようになっています。大きな更新（「メジャー更新」、たとえば6.8から6.9への更新）は、WordPress 5.6以降に新しく入れたサイトでは既定で自動になっていますが、それより前から使っているサイトでは、管理者が設定しない限り、以前と同じ動き（自動では当たらない）のままです。

自分のサイトの本体がどうなっているかは、管理画面の「更新」画面で確かめられます。何年も前からブログを続けている人は、大きな更新が自動にならない設定のままになっている可能性があるので、一度「更新」画面を開いて、新しい版が出ていないかを見ておくとよいでしょう。

プラグインとテーマの自動更新は、自分でオンにする

プラグインとテーマの自動更新は、WordPress 5.5から使えるようになった機能で、管理者が自分でオンにする仕組みです。何もしなければ自動では更新されません。公式ドキュメントによると、設定の方法は次のとおりです。

• プラグイン：管理画面の「プラグイン」画面に「自動更新」という列があり、各プラグインの行にあるリンクで、自動更新を有効にしたり無効にしたりできます。複数のプラグインをまとめて設定したいときは、一覧の左端のチェックボックスで選び、一括操作から自動更新の有効化を選んで「適用」をクリックします。
• テーマ：管理画面の「テーマ」画面で、更新したいテーマの画像をクリックし、開いた画面の右側、テーマの作者名の下にある「自動更新を有効化」のリンクをクリックします。テーマは1つずつ設定する必要があります。

自動更新は、既定では1日に2回実行されます。自動更新が成功したとき、失敗したとき、一部だけ成功したときには、サイトの管理者のメールアドレスに通知が届きます。

もし自動更新のリンクが表示されない場合は、WordPressが5.5以上になっているか、サーバー会社や別のプラグインがこの機能を止めていないかを確かめるように、と公式ドキュメントに書かれています。また、自動更新はWordPressの予約実行の仕組み（WP-Cron）で動くので、サイトヘルスでエラーが出ていないかも合わせて見ておくとよいそうです。

自動更新にするか、手動で更新するか

自動更新をオンにすると、セキュリティの修正が出たときに自分が気づかなくても当たるので、更新を忘れがちな人には心強い仕組みです。一方で、更新でプラグイン同士の相性が悪くなり、表示が崩れることもまれにあります。公式ドキュメントでも、自動更新を有効にする前に、問題が起きたときに以前の版へ戻せるようバックアップを取っておくことが勧められています。

個人のブログであれば、次のような分け方が現実的だと思います。

表はあくまで目安です。手動で更新すると決めたものは、週に1回など決まった日に管理画面の「更新」画面を開く習慣をつけておくと、更新の溜め込みを防げます。

使っていないプラグインとテーマは削除する

WordPressの公式ドキュメントは、安全性を高める方法として、使っていないプラグインとテーマの削除をはっきり勧めています。サイトヘルスの「情報」タブにも、「停止中のテーマ」「停止中のプラグイン」の欄があり、使う予定がないなら停止中のテーマは削除するように、と案内されています。

ファイルが残っている以上、そこに欠陥があれば狙われる余地も残りますし、停止しているプラグインは目に入りにくいので、更新も忘れられがちです。公式ドキュメントが「使っていないものは削除する」と書いているのは、入っているものが1つ増えるごとに、攻撃の入り口になりうる場所も1つ増えるからです。使う予定がないものは、停止のあとに削除まで済ませておきましょう。

テーマについては、WordPressの標準テーマ（Twenty Twenty-Fiveのような名前のもの）を1つだけ残しておくと、使っているテーマに不具合が出たときの切り替え先になります。それ以外の、昔試しに入れたテーマなどは削除してかまいません。

サイトヘルスの「ステータス」を定期的に見る

サイトヘルスの「ステータス」タブは、更新の状態を確かめるのにも役立ちます。公式ドキュメントで紹介されている「致命的な問題」の例には、更新を待っているプラグインがあること、自動更新の設定がうまく働いていないこと、WordPress.orgのサーバーと通信できず更新の確認ができないこと、古いPHPで動いていることなどが含まれています。また、デバッグの設定（不具合を調べるための詳しい表示）が有効のままで、エラーがサイトの訪問者に見えてしまう状態になっていると、それも警告されます。

月に1回くらい、サイトヘルスの「ステータス」を開いて「致命的な問題」が出ていないかを見るだけでも、ブログの健康状態はずいぶん把握しやすくなります。今回のような騒ぎのあとは、特に一度開いてみることをおすすめします。

管理画面の守りを固める

PHP2Shellは、ログインなしにサーバーへ手を出せる種類の欠陥でした。けれど、WordPressのサイトが乗っ取られるきっかけとしては、管理画面へのログインを破られるほうが、ずっとよくある話です。

ログイン画面のパスワードを何千通りも試す「総当たり攻撃（ブルートフォース）」や、ほかのサービスから漏れたIDとパスワードの組み合わせをそのまま試す「リスト型攻撃」は、どのブログにも毎日のように届いています。今回の騒ぎをきっかけに、管理画面の守りも見直しておきましょう。

エックスサーバーの「WordPressセキュリティ設定」

エックスサーバーには、サーバーパネルに「WordPressセキュリティ設定」という機能があります。公式マニュアルでは、国外からの接続を制限したり、総当たり攻撃による不正ログインを防いだりするための機能と説明されています。新しいサーバーパネルでの主な項目と初期値は、次のとおりです。

表のとおり、国外からのログイン画面への接続の制限と、ログイン試行回数の制限は、初期状態でONになっています。特に何も変えていなければ、ある程度の守りはすでに効いているということです。

一度サーバーパネルの「WordPressセキュリティ設定」を開いて、これらがOFFになっていないかを確かめておくと安心です。設定はドメインごとなので、複数のブログがある人はそれぞれ見てください。

「国外からのコメント・トラックバック制限」は初期値がOFFですが、マニュアルでは、国外からのコメントが不要であれば有効にすることが勧められています。日本語のブログで、海外の読者からのコメントを想定していないなら、ONにしておくとスパムのコメントを減らせます。

注意点もあります。

• マニュアルによると、CloudflareなどのCDN（世界中にサイトの複製を置いて表示を速くするサービス）や、海外のクラウドサーバーを経由した接続は、国外からの接続と判断されて誤って制限されることがあります。
• 国外からWordPress 5.0以降の管理画面を使う場合は、REST APIの制限もOFFにする必要があるとされています。

旅行先などの海外から記事を書く予定がある人は、出発前に設定を見直しておくとよいでしょう。

「IPアドレス制限設定」は、自宅のIPアドレスが変わらない環境であれば強力な守りになりますが、初期値はOFFで、ホワイトリスト（入ってよいIPアドレスの一覧）を登録しないとONにできません。また、IPアドレス制限をONにすると、一覧にないところからの接続は国内外を問わず遮断されるため、国外アクセス制限の設定は実質的に働かなくなる、とマニュアルに書かれています。スマホのモバイル回線から記事を直したい人などは、自分が締め出されないように注意が必要です。

パスワードと二段階認証

サーバー側の制限に加えて、WordPressのアカウントそのものも強くしておきます。WordPressの公式ドキュメントは、名前や辞書に載っている単語、短いものや数字だけ・英字だけのものを避けた、強くて使い回さないパスワードを使うように勧めています。パスワードを自分で考えるのが難しければ、パスワードを自動で作ってくれる機能（パスワード管理アプリやブラウザに付いているもの）を使うと楽です。

同じ公式ドキュメントは、二段階の認証（パスワードに加えて、スマホのアプリなどに表示される番号も入力しないとログインできない仕組み）を使うことも勧めています。WordPress本体には二段階認証の機能は入っていませんが、WordPress.orgのプラグイン置き場には「Two Factor」というプラグインがあり、コミュニティによって開発・サポートされています。

プラグインの公式ページによると、認証アプリ（Google AuthenticatorやAuthy、1Passwordなど）で番号を表示する方式と、非常用のバックアップコードが推奨の方式とされていて、ほかにメールで番号を受け取る方式も選べます。設定は、ユーザーのプロフィール画面に加わる二段階認証の欄から行います。

二段階認証を入れるときは、バックアップコードを必ず控えておきましょう。スマホをなくしたり機種変更したりしたときに、管理画面に入れなくなるのを防ぐためです。控えは、パソコンの中だけでなく、紙に書いて保管しておくなど、ブログのサーバーとは別の場所に置くのが安全です。

ユーザーと権限を整理する

管理画面の「ユーザー」の一覧も、この機会に見ておきます。昔、記事の寄稿をお願いした人や、作業を頼んだ人のアカウントが「管理者」の権限のまま残っていないでしょうか。

必要以上の権限を渡さないのが、守りの基本です。もう使わないアカウントは削除し、記事を書くだけの人には「投稿者」や「編集者」など、必要な範囲の権限だけを渡すようにしましょう。

また、見覚えのない管理者アカウントが増えていたら、それは乗っ取られたサインかもしれません。その場合は、自分だけで判断せず、サーバー会社のサポートに相談してください。後で紹介するバックアップから、乗っ取られる前の状態に戻すことも選択肢になります。

「サーバー会社を名乗る連絡」にも気をつける

大きな騒ぎのあとには、その話題に乗じたニセのメールが出回りやすくなります。たとえば「脆弱性の対応のため、こちらからログインしてください」といった、サーバー会社や大手サービスを名乗るメールです。

同じブログの既存記事「情報漏洩が10月だけで13件、6日間で約1450万件」でも、漏洩のあとに増えるのはニセの連絡だと書きました。今回の件で利用者に何かをお願いする場合も、エックスサーバーは公式のお知らせやXアカウントで知らせるとしています。メールのリンクから管理画面に入るのではなく、自分でブックマークしたサーバーパネルのページを開いて確かめる習慣をつけておくと安心です。

バックアップは、サーバーの中と手元の両方に

最後は、バックアップです。今回のPHP2Shellでは、侵入の成功が公式に確認された報告は今のところ見当たりません。

けれど、もし自分のサイトが乗っ取られたり、更新の失敗で表示が壊れたりしたとき、最後に頼れるのはバックアップです。WordPressの公式ドキュメントも、データベースを含めて定期的にバックアップを取ること、日付ごとの複製を残して、乗っ取られる前のきれいな状態に戻れるようにしておくことを勧めています。

エックスサーバーの自動バックアップ

エックスサーバーでは、全プランの標準機能として「自動バックアップ」があり、サーバーのデータを毎日自動で保存しています。公式の案内によると、Web・メールのデータとMySQLのデータベースが、通常は14日分保存されています。一部の古いサーバーでは保存期間が7日間なので、正確な日数はサーバーパネルで確かめるように、とマニュアルに書かれています。

この自動バックアップからは、2つのことができます。ひとつは、サーバーの上でそのまま元に戻す「復元」、もうひとつは、バックアップのデータを取り出して自分のパソコンに保存する「取得」です。

復元は、新しいサーバーパネルでは、自動バックアップの取得・復元のメニューから「自動バックアップデータから復元」を選び、戻したい日付のデータと復元のしかたを選んで「実行する」をクリックし、注意事項を確かめたうえで「注意事項を確認した上で実行する」をクリックする流れです。「対象を指定して復元」を選ぶと、ドメインごとに、Web領域（public_html）やメール領域などを選んで戻せます。WordPressのデータベースは、別の「MySQLバックアップ取得・復元」から、対象のデータベースと日付を選んで戻します。

バックアップを手元に取り出す

サーバーの中の自動バックアップは便利ですが、保存されているのはあくまで同じ会社のサーバーの中で、期間も14日分（一部の古いサーバーは7日分）です。乗っ取られたことに気づくのが2週間以上あとだった場合、きれいな状態のバックアップがもう残っていない、ということもありえます。そこで、ときどき手元にも取り出しておくことをおすすめします。

エックスサーバーのマニュアルによると、自動バックアップのデータは、サーバーパネルから「自動バックアップデータの取得」を選び、データと取り出し方を選んで「実行する」を押し、注意事項を確かめて「注意事項を確認した上で実行する」をクリックすると、サーバー内の「/userbackup」というフォルダに置かれます。そこから、FTPソフト（サーバーとファイルをやり取りするソフト）やファイルマネージャで自分のパソコンにダウンロードします。

取り出したデータは24時間後に自動で削除されるので、置かれたらその日のうちにダウンロードを済ませてください。データベースのバックアップも、「MySQLバックアップ取得・復元」で取得を申請し、「履歴」で出力先を確かめてから、同じようにファイルマネージャやFTPソフトでダウンロードできます。

ダウンロードしたバックアップは、パソコンの中に置いたままにせず、外付けの記録装置にも移しておくと、パソコンが壊れたときにも残ります。目安としては、月に1回、または大きな更新（PHPの切り替えやテーマの変更）の前に取り出しておくと、もしものときに戻れる地点を手元に確保できます。

手元のバックアップ用に：Samsung ポータブルSSD T7

手元のバックアップの置き場所としては、小さくて持ち運べる外付けSSD（記録装置の一種で、昔のハードディスクより速く、衝撃にも強いもの）が便利です。ここではSamsungのポータブルSSD T7の1TBモデル（国内正規保証品、型番MU-PC1T0T-IT/A）を紹介します。Samsungの公式の製品情報から確かめられる特徴は次のとおりです。

• 読み込みは最大毎秒1,050MB、書き込みは最大毎秒1,000MB（USB 3.2 Gen 2に対応した機器とケーブルで使った場合。使う環境によって変わります）。ブログのバックアップのように、画像がたくさん入ったデータでも短い時間でコピーできます。
• AES 256ビットのハードウェア暗号化に対応し、付属の専用ソフトでパスワードによる保護を設定できます。バックアップにはデータベースの中身なども含まれるので、なくしたときに中を見られにくいのは安心です。
• 重さ約58g、大きさ85×57×8.0mmと小さく、アルミニウムの一体型の外装です。メーカーの社内試験では、最大2mからの落下に耐えたとされています。
• USB Type-C同士のケーブルと、Type-CからType-Aへのケーブルが付属していて、パソコンのほか、Macやスマホ（Android）にもつなげられます（機器によってはフォーマットのやり直しが必要です）。

保証の内容は国内正規品と海外品で異なることがあるので、購入前に販売ページの保証の説明を確かめてください。

Samsung ポータブルSSD T7 1TBをAmazonで見る

バックアップ用の外付けSSDは、ふだんはパソコンにつなぎっぱなしにせず、取り出すときだけつなぐようにすると、パソコンがウイルスなどに感染したときに巻き込まれにくくなります。保管場所も、パソコンのすぐ横ではなく、引き出しの中など少し離れた場所にしておくとよいでしょう。

今回の騒ぎから、ブログを持つ人が覚えておきたいこと

最後に、今回の騒ぎから見えてきたことを、ブログを持つ人の目線で3つにまとめておきます。

1. 共用レンタルサーバーは「土台を直してくれる」のが強み

今回、エックスサーバーは修正版の公開前に緩和策を当て、公開からおよそ15時間で、PHP 5.6〜8.5の対象サーバーへの修正を終えました。個人で同じことをしようとすると、修正版の公開を夜中に待ち、自分でPHPを入れ替え、古いバージョンなら修正の差分を自分で組み込む、という作業が必要になります。共用レンタルサーバーを使う意味のひとつは、こうした土台の手当てを任せられることにある、と改めて感じた人も多いと思います。

一方で、VPSや自分で建てたサーバーを使っている場合は、その作業をすべて自分で引き受けることになります。自由度の高さと引き換えの責任なので、緊急の更新に対応する時間が取れるかどうかも含めて、自分のブログをどこに置くかを考える材料にしてみてください。

2. 「古いまま」が、いざというときの差になる

エックスサーバーの修正は、新しいPHPから順に終わり、最も古いPHP 5.1〜5.5は翌日の夕方でも作業が続いていました。ふだんは古いPHPでも問題なく動いていても、緊急時には直るのがいちばん遅くなります。PHPのバージョン、WordPress本体、プラグインとテーマを新しく保っておくことは、こうしたときに「早く直る側」にいるための準備です。

3. こうした騒ぎは、これからも起きうる

今回の欠陥は、AIを道具として使ったセキュリティ企業や研究者によって見つかったとされています（AIが自力で見つけたのか、人がAIを使って見つけたのかには議論があります）。今後についての見方は、次のように伝えられています。

• 報告者のひとつであるOpenAIは、今後数カ月で同じような発見が大きく増えると予測しています。
• CloudflareのCEOマシュー・プリンス氏も、インターネットの土台を支える別の重要なソフトに複数の深刻な欠陥を把握していると話し、今後数年は「毎週のように危機が訪れる」時期になりうると述べたと、ロイター通信が伝えています。
• 共同通信がMITREのデータを集計したところでは、今年見つかった脆弱性は10月21日までで約8万5千件と、過去最多だった前年同期の2.2倍になっていました。

ただし、見つかる数が増えることと、実際の被害が増えることは同じではありません。curlの開発者ダニエル・ステンバーグ氏らは、AIが見つける欠陥の中には、攻撃に使うのが難しいものもあると指摘しています。

ブログを持つ人に必要なのは、ニュースのたびに慌てることではなく、「サーバー会社のお知らせを見る」「自分の持ち分を新しく保つ」「戻れる地点を用意しておく」という基本を続けることだと思います。AIと脆弱性の発見の話は関連記事「AIが脆弱性を見つける時代」で、10月中旬から続いた一連の事件は関連記事「Black Octoberの10日間」で詳しく書いています。

まとめ

PHP2Shellは、WordPressを含むPHPで動くサイト全般に関わる重大な欠陥でした。ただ、エックスサーバーのような共用レンタルサーバーでは、PHP本体の修正はサーバー会社が当てており、エックスサーバーは10月22日中にPHP 5.6〜8.5の対象サーバーへの修正適用を終え、利用者が急いでPHPを切り替える必要はないと案内しています。PHP 5.1〜5.5は10月23日時点で対象サーバーの過半数まで適用が進んでいました。

10月23日に告知された3件目の欠陥の暫定策「session.upload_progress.enabled=0」は、PHPの開発元が「.user.iniやini_setに頼らないように」としている設定で、エックスサーバーの「php.ini設定で設定可能な項目」にも載っていません。共用サーバーの利用者は、自分で設定をいじるよりも、サーバー会社の案内を待つのが確実です。VPSや自分のサーバーの場合は、開発元の案内どおりに設定し、修正版が出たら更新してください。

ブログを持つ人が、この週末にやっておくとよいことは次のとおりです。

• サーバー会社のお知らせと、登録メールアドレスへの連絡を確かめる
• サーバーパネルの「PHP Ver.切替」か、WordPressの「サイトヘルス」でPHPのバージョンを確かめる。8.2以前なら、年内に8.3以上へ上げる準備をする
• WordPress本体、プラグイン、テーマを更新し、使っていないものは削除する
• 「WordPressセキュリティ設定」がOFFになっていないかを確かめ、パスワードの見直しと二段階認証を検討する
• 自動バックアップの保存期間を確かめ、手元にもバックアップを取り出しておく

どれも一度やってしまえば、次に同じような騒ぎが起きたときにも役に立ちます。自分のブログがどの層でだれに守られているのかを知っておくことが、いちばんの備えになると思います。

出典

• エックスサーバー 予防的な安全対策に伴う公式サイト・管理画面等の一時停止のお知らせ
• エックスサーバー マニュアル PHPのバージョン切り替え
• エックスサーバー マニュアル php.ini設定について
• エックスサーバー マニュアル php.ini設定で設定可能な項目について
• エックスサーバー マニュアル Xアクセラレータ利用時に無効となるphp.ini設定
• エックスサーバー マニュアル WordPressセキュリティ設定
• エックスサーバー マニュアル 自動バックアップデータからの復元
• エックスサーバー マニュアル 自動バックアップデータの取得
• エックスサーバー マニュアル MySQLバックアップのダウンロード
• エックスサーバー 自動バックアップ機能
• PHP公式サイト（2026年10月20日〜23日のセキュリティ告知）
• PHP Supported Versions
• PHP Manual Session Runtime Configuration
• PHP Manual Session Upload Progress
• WordPress サイトヘルス画面
• WordPress Site Health screen
• WordPress プラグイン・テーマの自動更新
• WordPress Advanced Administration Upgrading WordPress
• WordPress Advanced Administration Hardening WordPress
• WordPress 要件
• WordPress.org Two Factor プラグイン
• Samsung Portable SSD T7 1TB 製品情報
• piyolog（2026年10月21日の記事）
• gihyo.jp PHPの緊急セキュリティリリースに関する記事
• Help Net Security PHP2Shell vulnerabilities patched
• watchTowr PHP CVE-2026-109618 FAQ
• Rapid7 CVE-2026-109618 and CVE-2026-109619
• mizuho-factory PHP脆弱性への対応に関する記事
• セキュリティ対策Lab Cloudflare CEOの発言に関する記事
• 南日本新聞（共同通信配信、2026年10月24日）

※この記事の内容は、2026年10月24日時点で公表されている情報をもとにしています。