WordPressのセキュリティ対策を、PHP、更新、パスキーの順に中島さんの13項目で追う

出典: これだけはやっておきたいWordPressセキュリティ対策

あなたのWordPressの裏で、いま動いているPHPの版をご存知ですか？ 中島さんが最初に挙げるのは、ここです。

WordPressの裏ではPHPが動いていて、サポートの終わった版には穴をふさぐ修正が出ない。中島さんはこう話します。

動画では（3:09〜）

基本的にはサポート対象、え、外のものに関してはセキュリティパッチみたいなものが作られないので、ま、そういう脆弱性が放置になっちまうんで危ないよねということです

サポートが終わった版には修正が出ないので、穴が開いたままになる、という意味です。

脆弱性はプログラムの欠陥なので、攻撃されるとサーバーに侵入されたり、ハッキングされたりする。そうならないようにセキュリティパッチが出される、と中島さんは説明しています。

きっかけは、10月21日頃に話題になったPHP2Shellという脆弱性です。スライドに出ていた番号は、CVE-2026-109618と109619。

中島さんによると、今のサポート対象はPHP 8.2〜8.5です。

修正版は、8.2.35、8.3.36、8.4.27、8.5.12。

スコアは9.2と高く、レンタルサーバー各社が独自に対応した、とも話していました。

さらに、8.2は年内でサポートが終わるので8.3以上へ。版は勝手には上がらず、上げるとプラグインやテーマが動かなくなる恐れもある、と中島さんは続けます。確かめる場所として案内されるのは、管理画面の「サイトヘルス」→「情報」です。

PHPの版については、私の記事『PHPとWordPressと1Passwordのセキュリティ、KEITOさんの動画15分を6章で整理』に、こう書きました。

私の記事より（PHPとWordPressと1Passwordのセキュリティ、KEITOさんの動画15分を6章で整理・パスキーと2段階認証は、お金に関わる所から）

直す所は二つに分けて見る、と私は考えています。一方はサーバーの提供元の手を借りる PHP の版で、一方はパソコンの更新や鍵の置き場、ログインのように手元で完結する所。手元の側なら、提供元からの返事を待たずに、自分の都合で一つずつ進められますよね？

だから、先に手を付けるのは手元の側から。固められる所を先に固めておけば、提供元とのやり取りが残っていても、慌てずに落ち着いて待てるんです！

上の記事では、先に手を付けるのは手元の側から、と書きました。中島さんは、PHPの版の期限を先頭に置いています。期限がある分、今回は版から先に見たいんです。

中島さんは設定の手順を省いて、「気をつけること」だけを話しています。だから真似る時は、手順を別に調べるか、AIに聞く。そこは分けて考えたいところです。

ここで私が目を留めたのは、期限です。8.2は年内に終わる、という話には日付があります。

期限のある守り。私はこれを「思い出したらやる」ものにはしません。

私ならこうします。版の終わりまで運んでくれる持ち主に渡して、上げてよいか、止まる物があるか、その判断だけを返してもらう。

委ねたいのは作業だけではないんですよ。約束を覚えて、期限まで運び、本当に必要な判断だけを返す責任まで含めて渡す。進み具合を私が思い出して聞きに行った瞬間、次に動く番は私の手に戻ってきます。

版の確認は、期限まで運ぶ持ち主を決めるところから始まる。私はそう見ています。

中島さんは、プラグインを作って公開している側として、脆弱性の大半はプラグインとテーマから入る、と話します。

公表された穴は、攻撃する側にも丸わかり。更新で画面が真っ白になる怖さは中島さん自身も経験したそうですが、放置はもっと危ない、と続けます。手動が面倒なら自動更新をオンに、という話でした。

続けて、使っていない物の話。管理画面で無効にしただけでは、ファイルは残ったままです。中島さんはこう言います。

動画では（7:58〜）

それが残っているだけで攻撃の対象になることがあるので、なので使ってないテーマプラグインに関してはもう削除してやった方が、え、安全ですね。

無効化と削除は、別の作業。また使う時は入れ直せばいい、と中島さんは説明しています。

スライドの締めは、無効化したら削除までをセットにする、という一文でした。削除は管理画面から行うだけで、手間はほとんどかからない、とも出ます。

使っていないプラグインを、一覧に置いたままにする。これは、手放せないまま積み上がっている状態なんです。

抱え込みが腐り始めるのは、量が多いからではありません。持ち抱えたまま手放せず、積み上がっていく所からです。プラグインの一覧も、同じ形をしています。

その自動更新のオンを、私は、更新の実行を仕組みに渡す話として受け取っています。私の手元に残るのは、何を残して何を消すかの線引きです。

残すか消すかの線は、今使っているかどうか。迷って手が止まる物ほど、実は入れ直せる物なんですよね。消してから必要になったら、その時に入れ直せばいい。中島さんの話も、その向きでした。

最後にいつ使ったか言えない物から、手放す候補に入れていく。それが私の見方です。

管理者のログインは、IDとパスワードだけで守っていますか？ 長いパスワードでも、フィッシングや総当たり（ブルートフォース）には弱い、と中島さんは話します。

だから、IDとパスワードのほかに、別の要素をひとつ足す。これが二要素認証です。その中で中島さんが推すのが、総当たりが原理的にできず、フィッシングにも強いパスキー。

動画では（9:35〜）

パスキーめちゃくちゃ強いのでなので、ま、パスキー入れてあげるだけで安全なので、ま、この辺っていうのはプラグインとか入れて対応してあげるといいかなと思います。

WordPress本体がいつ対応するかは分からないので、まずはプラグインで、というのが中島さんの話です。挙がるのはWordfenceなどで、中島さん自身も使っていると話します。

ただし、プラグイン自体にも穴のリスクはある、と中島さんは添えていました。

続けて挙がるのが、ユーザー名にadminを使わないこと。admin で入っている人は結構いて、ユーザー名が丸分かりになる、と中島さんは話します。あとはパスワードを当てるだけでログインできてしまうので、推測されにくい名前にする、という話でした。

入口の話を聞いて、私が考えたのは固める順番です。

私なら、先に名前を見ます。admin のままだと、相手に残るのはパスワードを当てることだけになるので。名前を推測されにくくしてから、パスキーで鍵を足す。この順番で固めていきます。

第3章でログインの入口を固めたら、次はサーバーの中のファイルです。wp-config.php には、データベースのユーザー名とパスワードが書かれている、と中島さんは説明しています。

そのファイルが外から読まれたらどうなるのか。中島さんはこう話します。

動画では（13:46〜）

だからそれを見られるとですね、え、そのまんまあのデータベースに入られることになるので、

だから、置き場所を変える。ドキュメントルート（public_html など、外から見える一番上の置き場）の中は、外から一応アクセスできる場所です。そこから1つ上の階層へ移して、権限は 600（持ち主だけが読み書きできる設定）にする、という話です。

スライドには、最初の置き場所は安全よりも分かりやすさを優先したもの、と出ます。移すとほかの設定も変わるので、やり方は調べるか AI に聞いてほしい、と中島さん。

2つ目は uploads フォルダ。画像などの本体が置かれる場所です。ここで PHP を動かさない。PHP2Shell は外からコードを動かせる RCE（外から勝手にプログラムを動かされること）だった、と中島さんは振り返ります。

.htaccess に1〜2行書いて uploads に置く、というのが中島さんのやり方です。エックスサーバーと ConoHa WING は Apache と nginx が両方動いているので使える、と説明しています。使っているサーバーで効くかは各自で確かめてほしい、とも添えていました。

3つ目は、session.upload_progress.enabled を Off にすること。ファイルを上げる時の進み具合を出す機能で、PHP2Shell の片方の穴はこの機能を悪用したもの、と中島さんは話します。

パッチが出ても、似た穴があるかもしれない。だから使わない機能は止める。影響は PHP 5.4〜8.5 と言われていた、と中島さんは添えていました。

調べるか AI に聞いて、と中島さんが話したのは、wp-config.php の移し方です。uploads のほうは、.htaccess に1〜2行、と中身まで話していました。

私なら、置き場所を変える前に、自分のサーバーでほかに何が一緒に変わるかを先に AI に聞きます。そこから動く、という見方です。

次は、外から WordPress を操作する道の話です。

REST API と xmlrpc.php は、どちらも外から WordPress を操作するための仕組み、と中島さんは話します。xmlrpc.php は昔の仕組みで、最初から無効になっている所が多いそうです。

REST API のほうは、中島さん自身が使っている道でした。Claude Code などに REST API を使わせて、外から AI にブログの更新をさせることがある、と中島さんは話しています。そのうえで、使わないなら制限して、一度設定を見直してほしい、と。

続けて、入口を外側で絞る話が3つ。日本向けのサイトなら、海外の IP を止める。攻撃する側は日本のサーバーを経由することもあるけれど、海外から来ることが多いので、それなりに効く、と中島さん。サーバーのコンパネで設定でき、最初からオンの所もあるそうです。

1人で運用しているなら、管理画面に入れるのは自分だけでいい。そう中島さんは話します。そのための手段として中島さんが挙げるのが、管理画面への IP 制限と、入口に ID とパスワードを1枚足す Basic 認証です。

この章は、私には人ごとではありません。私は AI に WordPress の下書き投稿を頼んで、確認用のプレビューURLを返してもらっています。

その時に AI が通っているのが REST API。外から操作する道を通って、記事を下書きとして保存しています。

私は、AIが使う所に鍵を預ける側でもあります。

つまり私は、中島さんの言う、外から AI にブログを更新させる側にいるんですよ。

中島さんは、第6章で触れる WAF について、基本は使えるだけ使うけれど、API を使う時に切ることもある、と話しています。守りの設定と、外から使う API の道。その間には、ちょっとした緊張があるんです。

中島さんの「使わないなら制限」を、AIに下書きを頼む私の側から見るとどうなるか。私なら、AIが通る道は残して、それ以外は閉じる向きで考えます。開ける幅は、AIに渡す実行の範囲に合わせる。推測: 設定によっては、AI が下書きを入れる道まで止まることもありそうです。

手放すのは、実行と量産。魂は渡しません。下書きを入れるのは AI でも、何を出すかの判断は私の手元に残す。道の開け方も、その線に合わせて決めます！

最後の束は、サーバーの外側の守りとバックアップです。WAF（Web アプリケーションファイアウォール）は SQL インジェクションや XSS などを防ぐもので、レンタルサーバーの機能でオンにできる、と中島さんは話します。API を使う時に切ることもあるけれど、基本は使えるだけ使う。Cloudflare などの CDN を挟むのも守りになる、とも。

そして13項目の最後が、バックアップ。中島さんはこう言います。

動画では（30:36〜）

バックアップは、えっと、その同じサーバーに取ってると意味がないので、え、別サーバーに、別サーバーってか、別の場所に逃すようにしてください。

同じサーバーの中だと、書き換えやランサムウェアの暗号化で一緒にやられる、という理由です。逃がす先は、S3・Google ドライブ・Dropbox・OneDrive などのクラウドか、手元のローカル。

あわせて大事なのが、そのバックアップから本当に戻せるか、一度テストすること。置いただけでは、守りは半分なんですよね。

まとめで中島さんは、AI を使った攻撃は本当に当たり前になってきている、と話します。運用が大変なら、運営会社が管理してくれる note などのブログサービスを使うのも1つ。Cloudflare EmDash に移っても、今日の話はなくならない、とも言います。理由はこうです。

動画では（33:40〜）

結局クラウドフレアもそうですけどサーバーみたいなものを持つっていうことになるんでそれの管理をしていかなければいけない

サーバーを持つ以上、管理は残る。器を替えても、守る仕事は一緒についてくる。

中島さんは、そのかわり、学べば手元で扱える資産になる、とも話しています。

この向きは、私の記事『EmDash（Cloudflare製CMS）へのWordPress移行をKEITOさんが実演』に書いた事とも重なります。

私の記事より（EmDash（Cloudflare製CMS）へのWordPress移行をKEITOさんが実演・01「WordPress から EmDash への引っ越し。前と後で、何が替わり何が同じか」と02「更新し続ける負担。PHP の脆弱性は最後の一押しだった」）

バックアップを先に取る。失敗したときに戻れないのが怖いから。流れの一番前に、守りの作業を置いています。

AIで運用を管理すれば、保守はほぼ要らなくなる。そう話したうえで、KEITOさんは、セキュリティの保守だけは残した方がいい、と1つだけ念を押します。

引っ越しの実演でも、バックアップは流れの一番前にありました。AI で管理しても、セキュリティの保守は残す。中島さんの話と同じ向きですよね。

戻せるかを一度試す、と中島さんは話していました。

EmDash に移っても、この確かめの仕事は消えません。逃がす先を決めて、戻せるかを確かめる。ここは器を替えても残る作業です。

ウェブ職TVの中島さんの13項目を、PHPの版、更新と削除、ログインの入口、設定ファイルと書き込み場所、外から操作する道、外側の守りとバックアップの6つの束で追いました。

どの束も、一度設定して終わりではなく、確かめ続ける守りの作業です。

私なら、守りの作業を思い出したらやるものにせず、期限まで運ぶ持ち主を1人決めて渡します。AIに渡すのは実行で、何を出すかは私が持ちます！