最終更新：10 月 27 日 18:03（日本時間）
WordPress や PHP の大きなセキュリティの出来事があれば追記します。
すぐ見る：よくある疑問 ／ 判断の早見表 ／ ほかの作り方との比較 ／ AI で作るとき ／ 最低限やること ／ 技術的な詳細
ひとことで言うと
危ないのは WordPress そのものより、更新されないまま放っておかれたサイト
- 「システムの弱点（脆弱性）が多い」と言われるのは、使っているサイトがとても多く、あとから足す機能（プラグイン）の数も多いから。2025 年に見つかった弱点の大半はプラグインとテーマで、本体の分はわずかだった（セキュリティ会社 Patchstack の集計）。知識がなくても作れてしまうので、基本的な対策をしないまま公開されたサイトが多いと考えられることも、そう言われる一因（この記事での整理）
- 本体には専門のチームがいて、小さな修正は自動で入る仕組みがある。ただし 2026 年は本体にも重大な弱点（wp2shell）が見つかっていて、無縁ではない。10 月の PHP2Shell は WordPress ではなく、土台の PHP の弱点
- 更新する人がいない会社は、WordPress でもほかの作り方でも危ない。どれが合うかは、更新を誰がするか・予算・必要な機能で決まる
どうすればいい？
よくある疑問と答え
-
WordPress は危ない？やめた方がいい？
更新を続けられるなら、WordPress だから危ないということはありません。更新する人がいない、機能をほとんど使わない会社には、ほかの作り方が向くこともあります。
→ 自社に合う作り方の早見表 -
なぜ「脆弱性が多い」と言われるの？
使っているサイトが多いので狙われやすく、プラグインの数も多いからです。本体の弱点は、報告全体のごく一部です。また、知識がなくても作れてしまうので、基本的な対策をしないまま公開されたサイトが多いと考えられることも、そう言われる一因です（この記事での整理）。
→ 多いと言われる理由と数字 -
PHP の脆弱性（PHP2Shell）は WordPress のせい？
いいえ。WordPress を動かす土台のプログラム「PHP」の弱点です。WordPress の更新は要りませんが、サーバーの PHP の更新は要ります。
→ PHP の件と WordPress の関係 -
Wix や Studio なら安全？
本体の更新は運営会社がしてくれます。そのかわり、運営会社で事故が起きると、使っている会社がまとめて影響を受けることがあります。
→ 作り方ごとの比較 -
AI にホームページを作ってもらえば大丈夫？
動くものはすぐできます。ただ、AI に手伝わせると安全でないコードが増えたという研究があり、「動く」と「安全」は別です。
→ AI で作るときの注意と点検表 -
WordPress のデメリットは？
プラグインの品質がばらばら、更新を止めると一気に危ない、サーバーの PHP の管理も要る、ログイン画面が狙われやすい、などです。
→ デメリットの一覧 -
今すぐ何をすればいい？
本体・プラグイン・テーマ・PHP を新しくし、使っていないプラグインを消し、管理者のログインに 2 段階認証を入れます。
→ 最低限やることのチェックリスト
詳しくは：判断の早見表 ／ 最低限やること ／ 技術的な詳細（担当者向け）
この記事は、WordPress でホームページを持っている、またはこれから作る中小企業の経営者・Web 担当者に向けたものです。「WordPress は脆弱性が多い」「WordPress はやめた方がいい」と聞いて乗り換えを迷っている方や、生成 AI・ノーコードで自分で作ろうとしている方も対象です。WordPress の危険性とデメリット、ほかの CMS（ホームページを更新する仕組み）とのセキュリティの比較を、公式の資料・公的機関の注意喚起・論文・セキュリティ会社の報告の原文で確かめた範囲で整理し、自社に合う作り方を選べるようにします。
おことわり
この記事を書いている SITE PICK の立場
SITE PICK は、納品後にお客さまが WordPress で編集できるホームページを販売し、WordPress の保守の相談も受けています。つまり、WordPress が選ばれるほうが得をする立場です。そのため、この記事では WordPress のデメリットと、WordPress を選ばないほうがよい場合も具体的に書きます。事実には出典を付け、出典の無い判断や表には「この記事での整理」と書いています。
SITE PICK が納品するサイトに行う設定と、約束しないことは 「SITE PICK のセキュリティ対策」 に書いています。
「WordPress は脆弱性が多い」と言われる理由
理由は大きく 3 つです。使っているサイトの数、プラグインの数、そして知識がなくても作れてしまうことです。
使っているサイトが多い
数字から見ていきます。W3Techs は、世界のウェブサイトで使われている技術を調べ、毎日統計を公開している調査サービスです。W3Techs によると、2026 年 10 月 27 日の時点で、WordPress は世界のウェブサイトのおよそ 4 割で使われています。CMS を使っているサイトだけで見ると、6 割近くが WordPress です。次に多い Shopify と Wix は、どちらも CMS の中で 1 割に届きません。
使う人が多いソフトは、1 つの弱点で多くのサイトを狙えるので、攻撃する側に選ばれやすくなります。弱点を探して報告する人も多いので、報告の数も増えます（この記事での整理）。
弱点の大半はプラグインとテーマ
WordPress のプラグインやテーマの脆弱性の情報を集めて公開し、サイトを守るサービスを提供している Patchstack という会社が、毎年、集計を出しています。Patchstack によると、2025 年に WordPress の周りで新しく見つかった脆弱性は 11,334 件でした（2026 年 2 月 25 日に更新された報告）。その 9 割余りがプラグイン、残りがテーマで、WordPress 本体の報告は 6 件、どれも優先度の低いものだったとしています。
| 場所 | 2025 年に見つかった脆弱性 | 直すのは |
|---|---|---|
| プラグイン | 全体の 9 割余り | それぞれのプラグインの作者（会社や個人） |
| テーマ | 全体の 1 割弱 | それぞれのテーマの作者 |
| WordPress 本体 | 6 件（どれも優先度の低いもの） | WordPress のセキュリティチーム |
同じ報告は、2025 年にいちばん多く狙われた 10 個の脆弱性のうち、2025 年に公表されたものは 4 つだけだったとも書いています。攻撃は、新しい弱点だけでなく、何年も前の弱点を放っておいたサイトにも向かいます。
知識がなくても作れてしまう
WordPress は、レンタルサーバーの管理画面から数回のクリックで入れられ、プログラムを書かなくても、テーマとプラグインを選ぶだけでサイトができます。そのため、セキュリティの基本を学ぶ前の人がサイトを作り、そのまま公開して使い続けている例も多いと考えられます（この記事での整理）。始めやすさは WordPress の長所ですが、守りの知識がないまま作られたサイトが多いことも、「WordPress は危ない」と言われる原因の 1 つです。
狙われる場所は、公式の資料にはっきり書かれています。WordPress 開発者向けハンドブック「Hardening WordPress」によると、WordPress のサイトへのよくある攻撃は、大きく 2 つに分かれます。古いプラグインやソフトウェアの弱点を突く攻撃と、パスワードを総当たりで当ててログインしようとする攻撃です。どちらも、更新を続けることと、ログインまわりの基本的な設定で、多くを防げる種類の攻撃です（この記事での整理）。
知識がないまま作られたサイトでよく見かけるのは、次のような状態です（この記事での整理）。
- 管理者のパスワードが短い・ほかのサービスと同じ。ログイン ID が「admin」や会社名のまま
- 入れたプラグインを更新しないまま放っている。使わなくなったものも消していない
- 表示が崩れるのが怖くて、本体やプラグインの更新を止めている
- 配布元の分からないテーマやプラグイン（有料のものを無料で配っているものなど）を入れている
- バックアップを取っていない。サーバーの PHP の版を確かめたことがない
だからこそ、仕事で使うサイトは、基本的なセキュリティ対策を実施できるエンジニアや制作会社に作ってもらい、公開前の設定まで済ませておくことが大切です。依頼するときは、この記事の「最低限やること」の中身を、作る人が自分の言葉で説明でき、実際に設定できるかを目安にしてください（この記事での整理）。
ただし、ホームページを作って売っている SITE PICK にとって、この主張は有利なものです。エンジニアが作ったサイトでも、公開後に更新が止まれば同じように危なくなります。反対に、自分で作る場合でも、「最低限やること」を押さえ、分からないところだけ専門家に見てもらう方法があります。
詳しくは：WordPress を使うなら最低限やること ／ AI や、知識のないまま自分で作るときの危険
数え方にも注意
この数は、Patchstack が受け付けた報告をもとにしたものです。同じ報告書は、有料のプラグイン・テーマは研究者がコードを見にくいため、弱点が見つかりにくいとも書いています。報告が多いことは、調べる人が多いことの裏返しでもあり、報告の少ない仕組みが安全だとも言い切れません（この記事での整理）。
PHP の脆弱性（PHP2Shell）との関係
2026 年 10 月 21 日、PHP の開発元は、2 つの重大な脆弱性（CVE-2026-109618・CVE-2026-109619。まとめて PHP2Shell と呼ばれる）を直した PHP 8.5.12・8.4.27・8.3.36・8.2.35 を公開しました。PHP は、WordPress を動かしている土台のプログラム（プログラミング言語とその実行環境）です。PHP 公式は、Web のリクエストを受けるすべての PHP が危険にさらされるとしています。
WordPress.org は同じ日のお知らせで、今回の脆弱性は WordPress に固有のものではなく、WordPress を更新する必要はないと書いています。PHP は WordPress 以外の多くの仕組みでも使われていて、Movable Type の開発元のシックス・アパートも、PHP を使う機能があるとして、クラウド版の緊急メンテナンスと、ソフトウェア版での PHP の更新を案内しました。
つまり PHP2Shell は「WordPress の弱点」ではありません。それでも WordPress のサイトの持ち主には関係があります。WordPress は PHP の上で動くので、サーバーの PHP が古いままだと、WordPress をいくら新しくしても危ないからです。JPCERT/CC（国内のサイバー攻撃の被害の報告を受け、注意を呼びかける組織）は 10 月 26 日、悪用できると主張する実証コードが多く公開され、悪用を試みる通信の観測の報告も相次いでいるとして、注意喚起を更新しました。IPA も 10 月 27 日、米国 CISA（サイバーセキュリティ・インフラストラクチャセキュリティ庁）の「悪用が確認された脆弱性」の一覧に載ったと追記しています。
本体も無縁ではない
一方で、WordPress 本体に弱点が無いわけではありません。2026 年 7 月には、本体の 2 つの脆弱性を組み合わせた「wp2shell」が見つかりました。IPA の注意喚起では、標準の構成で、管理者の権限がなくても外からプログラムを動かされるおそれがあるとされています。WordPress.org は 7 月 17 日に修正版の 7.0.2 などを出し、深刻さを考えて、影響を受ける版のサイトに自動更新の仕組みで強制的に更新をかけました。9 月 22 日の 7.1.2 でも、条件がそろうとログインなしで外からプログラムを動かされるおそれのある重大な脆弱性（CVE-2026-87902）を直しています。
| 例 | 弱点の場所 | 修正を出す・入れる人 | サイトの持ち主がやること |
|---|---|---|---|
| PHP2Shell（2026 年 10 月） | PHP（土台のプログラム） | PHP の開発元が修正版を出す。サーバーに入れるのは、レンタルサーバー会社かサーバーの管理者 | サーバーの PHP の版を確かめる。サーバー会社の案内を見て、古ければ切り替える |
| wp2shell（2026 年 7 月） | WordPress 本体 | WordPress.org が修正版を出し、影響を受ける版には自動更新で強制的に配った | 管理画面で版を確かめる。自動更新が止まっていないかを確かめる |
| プラグイン・テーマの脆弱性 | プラグイン・テーマ | 作者が修正版を出す。入れるのはサイトの管理者（自動更新をオンにしていれば自動） | 更新する。修正版が出ないもの・更新が止まったものは、消すか別のものに替える |
次に読む：PHP2Shell の修正版とサーバー各社の対応 ／ PHP のバージョンの確かめ方と上げ方 ／ wp2shell の影響する版と確かめること
むしろ守りが整っているところ
WordPress は狙われやすい一方で、使う人が多いぶん、守りの仕組みも長い時間をかけて整えられてきました。WordPress.org の公式の資料で確かめられるものを並べます。
| 仕組み | 中身 |
|---|---|
| 本体のセキュリティチーム | 主な開発者やセキュリティの研究者など 50 人を超える専門家が、本体の弱点を見つけて直す。大手のレンタルサーバー会社とも直接連携し、修正の配り方の調整や、WAF（攻撃の通信を止める仕組み）向けの対策も作る |
| 本体の自動更新（バックグラウンド更新） | バージョン 3.7（2013 年 10 月）から、保守とセキュリティの小さな更新（マイナーリリース）が、管理者が何もしなくても自動で入る。5.6 以降に新しく入れたサイトは、大きな更新（メジャーリリース）も初期設定で自動になる |
| 古い版への修正 | 公式に支えるのは最新版だけだが、セキュリティの修正は古い系列にも配り、自動更新で届ける。9 月の 7.1.2 の修正は 4.7 系まで配られた |
| プラグイン・テーマの自動更新 | 5.5（2020 年 8 月）から、プラグインとテーマごとに自動更新をオンにできる。初期設定では 1 日 2 回動き、結果をメールで知らせる。重大な脆弱性のときは、セキュリティチームの判断でプラグインに自動更新がかかることもある |
| 公式の配布場所の見張り | 公式ディレクトリのプラグインに安全上の問題が見つかると、配布を止め（閉鎖）、ページに表示する。最近の 3 つの大きな版に対応していないプラグインには注意書きが出る |
wp2shell のときも、修正版の公開とあわせて、影響を受ける版のサイトに強制的に更新をかけています。自動更新が効いているサイトなら、持ち主が何もしなくても本体の修正が入ります（この記事での整理）。
これに対して、プラグインは作者ごとに対応の早さがちがいます。Patchstack の報告では、2025 年に見つかった脆弱性の半分近くが、公表の時点で作者の修正が出ていませんでした。本体は「修正が早く、自動で入る」、プラグインは「作者しだい」と分けて考えるのが、実態に近い見方です（この記事での整理）。
WordPress のデメリット（弱いところ）
守りの仕組みがあっても、WordPress には弱いところがあります。選ぶ前に知っておきたい点です。
- プラグインの品質がばらばら 公式ディレクトリだけで 7 万 6,000 を超える無料のプラグインがあり、作者は会社も個人もいます。更新が止まったものや、弱点が直らないままのものも混じります。
- 更新を止めると一気に危ない WordPress の公式ハンドブックは、修正版が出た時点で、弱点を突くのに必要な情報はほぼ確実に公開されていると書いています。Patchstack の集計でも、特に多く狙われた弱点は、公表から数時間のうちに攻撃が始まるのがふつうでした。
- PHP・サーバーの管理も要る WordPress は PHP 8.3 以上を勧めています。古い PHP でも動きますが、公式は、サポートの終わった版はサイトを脆弱性にさらすおそれがあるとしています。サーバーを誰が見るかも決めておく必要があります。
- ログイン画面が狙われやすい 管理画面のログインは、パスワードを総当たりで試す攻撃の的になります。本体には 2 段階認証（2FA）の機能が入っておらず、プラグインなどで足す必要があります（WordPress 公式のハンドブック）。
- 自動更新が止まっていることがある 設定ファイル、サーバー、プラグインによっては、自動更新が動きません。IPA も wp2shell のときに、環境や設定によっては自動更新が効いていない・失敗している可能性があるとして、版を確かめるよう呼びかけました。
- 作り込みすぎると更新できなくなる 本体やプラグインのファイルを直接書き換えたり、古い PHP にしか合わない作りにしたりすると、更新のたびに作業と確認が要り、やがて更新が止まります（この記事での整理）。IPA も PHP の注意喚起で、長く更新していないシステムは、改修や動作確認の手間、資料や担当者の不足などで、対策が難しくなっている場合があると書いています。
- 入り込まれても気づきにくい Patchstack の報告は、「Japanese SEO」などと呼ばれる手口で、検索エンジンにだけ語句を詰め込んだスパムを見せ、持ち主や点検の道具には普通のページを見せる例が多いと書いています。
どれも WordPress だけの問題ではありません。それでも、WordPress を選ぶなら「誰が更新を続けるか」を先に決めておく理由はここにあります（この記事での整理）。
ほかの CMS・作り方とのセキュリティの比較
WordPress を使わない場合の選択肢は、大きく 3 つです。サーバーに入れて使うほかの CMS、Wix や Studio のような SaaS 型（ネット上のサービスとして借りる形）のサイト作成サービス、HTML だけで作る静的なサイトです。セキュリティの面でのちがいは、「誰が土台を更新するか」と「事故が起きたときにどこまで影響するか」に出ます。
| 作り方 | 土台を更新するのは | 事故が起きたとき | 向いている会社 |
|---|---|---|---|
| WordPress（自社で契約したサーバー） | 本体の小さな更新は自動。大きな更新・プラグイン・テーマ・PHP は、自社か制作会社・保守の担当 | 影響は主に自社のサイト。共用のレンタルサーバーでは、ほかのサイトに及ぶこともある（WordPress 公式の「ハッキングされたとき」の案内） | お知らせ・ブログ・採用情報を社内で書き足したい。機能を足していきたい。保守を頼める先がある |
| サーバーに入れて使うほかの CMS（Movable Type・Drupal など） | ソフトウェア版は自社か制作会社。Movable Type のクラウド版は、初期設定で開発元が自動で更新する | WordPress と同じく自社のサイト。2026 年 10 月には Movable Type にも重大な脆弱性があり、サポートの終わった版も影響を受けた | 社内に担当がいるか、長く付き合う制作会社がいる。決まった仕組みで大きめのサイトを運用したい |
| SaaS 型のサイト作成サービス（Wix・Studio など） | 運営会社。使う側は本体を更新しなくてよい | 運営会社で事故が起きると、使っている会社がまとめて影響を受けることがある。Studio は 2026 年 10 月、登録しているすべての利用者の情報が流出した可能性があると発表した。使う側では直せない | 更新の担当がいない。用意された機能とデザインの範囲で足りる |
| 静的なサイト（HTML だけ） | 動くプログラムが少なく、更新するものも少ない。ページを直すには HTML を書ける人が要る | 狙われる入口が少ない。フォームや予約は外部のサービスに頼るので、そのサービスの事故の影響は受ける | ページをほとんど変えない。会社案内として最低限あればよい |
どれを選んでも、管理画面のパスワード、使っている外部サービスの事故への備え、バックアップは残ります。「WordPress をやめれば安全」なのではなく、「土台の更新を運営会社に任せるか、自社の側で持つか」の選択です（この記事での整理）。
次に読む：SaaS 型のサービスで起きた事故の例（Studio への不正アクセス） ／ Movable Type の 2026 年 10 月の脆弱性と回避策
判断の早見表：WordPress を続ける・選ぶ・やめる
自社の体制から、向いている作り方を選ぶための表です（この記事での整理）。上から順に、当てはまる行を探してください。
| 自社の状況 | 向いている作り方 | 理由・注意 |
|---|---|---|
| 更新を任せる人がいない（社内にも外部にも） | SaaS 型か、静的なサイト | 土台の更新を自社でしなくてよい。WordPress を放っておくより安全。そのかわり、機能やデザインの自由は小さくなる |
| お知らせ・ブログ・採用情報を社内で書き足したい。保守を頼める | WordPress | 更新の担当がいれば、自由度と、本体の守りの仕組みの両方を使える |
| 社内で書き足したいが、保守にお金をかけられない | SaaS 型、または WordPress を最小限の構成で | WordPress にするなら、自動更新をすべてオンにする・プラグインを最小限にする・月に 1 回は管理画面を開く、を続けられるかで決める |
| 予約・会員・ネットショップなど、個人情報やお金を扱う | その用途の専門のサービス。WordPress なら保守つきで | 入力を受ける部分は狙われやすい。自作のコードや、更新の止まったプラグインに任せない |
| AI やノーコードで、自分で作りたい | ノーコードなら SaaS 型。AI にコードを書かせるなら静的なサイトまで | フォーム・ログイン・データベースのような入力を受ける仕組みを、AI のコードで自作しない |
| すでに WordPress で、長く更新していない | まず今の版を確かめて更新する。上げられないほど古ければ、作り直しや移行を考える | 乗り換えには時間がかかり、そのあいだも古いサイトは公開されたまま。先に更新できるものを更新する |
WordPress を選ばないほうがよいのは、主に 1 行目と 5 行目に当てはまる会社です。IPA も PHP の注意喚起で、更新したあとも維持する体制を確保する見通しが立たないなら、保守を受けられる製品・サービスへの移行や、公開の終了も含めて考えるよう呼びかけています。逆に、更新を担う人がいて機能を足していきたい会社には、WordPress の守りの仕組みが役に立ちます。
AI や、知識のないまま自分で作るときの危険
生成 AI に頼めば、ホームページのコードはすぐに出てきます。AI でホームページを作成する機能を持つサービスも増えました。ただ、「動く」ことと「安全」なことは別です。研究と報告で分かっていることを並べます。
- AI を使うと安全でないコードが増え、本人は安全だと思いやすい スタンフォード大学の研究者らが、47 人に暗号化やデータベースなど安全に関わる 5 つのプログラミングの課題を解いてもらった実験です（2023 年の国際会議 CCS で発表）。AI の手伝いを受けた人は、受けなかった人より、5 つのうち 4 つの課題で安全でないコードを書くことが多く、しかも自分のコードは安全だと思いやすかったと報告しています。データベースに書き込む課題では、AI が返した、文字列をつなげて命令を組み立てるコード（SQL インジェクションという攻撃を受ける書き方）を、そのまま使った例も紹介されています。論文は 2022 年に最初に公開されたもので、使われた AI は当時のモデル（codex-davinci-002）です。
- 新しく大きな AI でも、安全になるとは限らない アプリケーションの脆弱性を検査するサービスを提供する Veracode は、100 を超える大規模言語モデルに Java・JavaScript・Python・C# のコードを書かせて調べ、テストの半分近くで危険な弱点が入ったと報告しています。新しく大きなモデルほど安全になる、という結果も出なかったとしています。
- 確かめるための物差しはある IPA の「安全なウェブサイトの作り方」は、SQL インジェクションやクロスサイト・スクリプティングなど 11 種類の脆弱性について、起きうる被害と、原因そのものをなくす対策をまとめた、開発者・運営者向けの資料です。AI の書いたコードを見てもらうときの物差しにもなります（この記事での整理）。
この記事での整理です。AI で作ったサイトが危ないのは、コードの弱点だけが理由ではありません。作った人がコードの中身を説明できないと、使った部品に弱点が見つかっても直せず、更新も止まります。WordPress のサイトに、AI が出したコードを貼り付けて機能を足す場合も同じです。「作れる」ことより、「公開したあと誰が直すか」を先に決めてください。
AI・ノーコードで作る前の点検表（この記事での整理）
- お問い合わせ・ログイン・ファイルの受け取り・データベースへの書き込みを、AI のコードで自作していない（既製のサービスや、更新が続いている仕組みを使う）
- パスワードや API キーなどの秘密の値を、公開するファイルに書いていない
- 使った部品（ライブラリ・プラグイン）を書き出し、その更新を誰が見るかを決めた
- AI が出したコードを、分かる人に一度見てもらった
- 公開後に弱点が見つかったとき、直せる人（社内か外部）がいる
WordPress を使うなら最低限やること
WordPress を続ける・選ぶと決めたら、次のことを決めておくと、「脆弱性が多い」と言われる理由の大半に手が打てます（この記事での整理。手順の根拠は WordPress 公式のハンドブック）。経営者は担当と分担を、担当者は中身を確かめてください。
- 本体・プラグイン・テーマの更新を、誰が・どのくらいの間隔で見るかを決めた（自動更新を使うなら、止まっていないかを確かめる人も）
- 使っていないプラグインとテーマを消した（止めただけでは、ファイルはサーバーに残る）
- プラグイン・テーマは、公式ディレクトリか、よく知られた会社のものだけを入れている
- 管理者のアカウント全員に 2 段階認証を入れ、ログインを試せる回数を制限した
- 管理者は必要な人だけにし、使い回しでない長いパスワードにした
- サーバーの PHP が、WordPress の勧める 8.3 以上で、サポート期間内の版になっている
- バックアップを自動で取り、そこから戻せることを一度試した
- 更新や改ざんの確認を頼める先（社内か外部の保守）を決めた
技術的な詳細（サイト・サーバーの担当者向け）
ここからは、WordPress のサイトを運用する担当者・エンジニア向けです。WordPress.org の開発者向けハンドブック、PHP 公式、JPCERT/CC の資料にある設定と確かめる点を、用語はそのまま並べます。
自動更新の設定（Configuring Automatic Background Updates）
| 設定 | 動き |
|---|---|
| 何も定義しない（既定） | 既存のサイトは、本体のマイナーリリースと翻訳ファイルを自動更新。5.6 以降の新規インストールは、メジャーリリースも自動（バージョン管理のチェックアウトを検出したときを除く） |
| WP_AUTO_UPDATE_CORE | wp-config.php で true なら開発版・マイナー・メジャーをすべて自動、false ならすべて止める、minor ならマイナーだけ。管理画面「更新」の設定より優先される |
| AUTOMATIC_UPDATER_DISABLED | true にすると、本体以外も含めてすべての自動更新が止まる。公式は、マイナーリリースと翻訳の自動更新を止めることを強く勧めないとしている。更新が止まっているサイトでは、この定数が入っていないかを見る（この記事での整理） |
| auto_update_plugin・auto_update_theme フィルター | プラグイン・テーマの自動更新を、まとめて、または個別に制御する。何もしなければ、プラグイン・テーマの自動更新は、管理画面で個別にオンにしたものと、セキュリティチームが重大な脆弱性の修正のために決めた特別な場合だけ |
| WP-Cron | プラグイン・テーマの自動更新は WP-Cron の予定のタスクで動く。動いていないと自動更新も止まるので、「ツール」→「サイトヘルス」でエラーを確かめる |
管理画面とファイルの守り（Hardening WordPress・Brute Force Attacks）
| 項目 | 中身 |
|---|---|
| DISALLOW_FILE_EDIT | wp-config.php で true にすると、管理画面からプラグイン・テーマの PHP ファイルを編集する機能が止まる。ログインを奪われたとき、攻撃者が最初に使う道具になりやすいため |
| ファイルの権限 | /wp-content/plugins/ のファイルは、自分のユーザーアカウントだけが書き込めるようにする |
| データベースのユーザーの権限 | 通常の運用で要るのは SELECT・INSERT・UPDATE・DELETE。ただし、プラグインや大きな更新で表の構造を変えることがあり、権限を外すなら確かなバックアップの計画が前提 |
| 2FA・パスキー | 管理者と権限の強いユーザー全員に入れる。本体には入っていないので、プラグインか ID 基盤（SSO）で足す |
| ログイン試行の制限 | WAF・CDN のような手前の層か、Web サーバーで回数を制限する |
| xmlrpc.php | 総当たりの的になりやすい（特に system.multicall）。使っていなければ無効にし、使うなら WAF のルールで制限して回数も絞る |
PHP2Shell で確かめること
| 項目 | 中身 |
|---|---|
| 修正版 | PHP 8.5.12・8.4.27・8.3.36・8.2.35。8.1 以前は PHP の開発元からの更新が無い（Linux ディストリビューションや LTS の提供元が修正を出している場合はある） |
| 版の確かめ方 | WordPress の「ツール」→「サイトヘルス」→「情報」→「サーバー」。レンタルサーバーの管理画面でも見られることが多い |
| 更新できないあいだ | PHP 公式の緩和策（session.upload_progress.enabled を 0 にしてワーカーを再起動する、memory_limit・post_max_size を見直す、など）は特定の攻撃の経路を減らすだけで、安全にはならないとしている |
| 入り込まれていないかの調べ方 | 不自然に長い・形の崩れた PHPSESSID の Cookie を返していないか。怪しい multipart/form-data のリクエストと、その前後のメモリ上限のエラーや HTTP 500 がないか。PHP のワーカーが予期せず終了したり、頻繁に再起動したりしていないか（JPCERT/CC） |
本体の wp2shell（CVE-2026-63030・CVE-2026-60137）は、6.9.0〜6.9.4 と 7.0.0〜7.0.1 が影響を受け、7.0.2・6.9.5 で直りました（6.8 系は SQL インジェクションの CVE-2026-60137 だけが影響し、6.8.6 で修正）。9 月の CVE-2026-87902 の修正は、4.7 系までの古い系列にも配られています。系列ごとの版は、上で紹介した wp2shell の記事にまとめています。
この記事での整理です。担当者が見る順番は、(1) 自動更新が本当に動いているか（版と更新の記録）、(2) 使っていないプラグインと、更新の止まったプラグインが無いか、(3) サーバーの PHP の版、(4) 管理者の数と 2FA、(5) バックアップから戻せるか、です。
作り方は 3 つ｜完成済み・自作・オーダーメイド
作り方はどれでも選べます。優劣ではなく、向いているケースが違います。
- オーダーメイドで作る（制作会社に依頼） 要件を渡せば設計から任せられます。自社に合わせて一から作りたい場合や、撮影・原稿まで任せたい場合に向きます。SITE PICK でもオーダーメイド制作の相談を受け付けています。
- 自分で作る（自作） 費用は抑えられます。そのかわり、WordPress や PHP の更新、使う部品の脆弱性の情報の確認を、公開後もずっと自分で続けることになります。
- 完成済みのサイトから選ぶ（完成済み） 構成・更新の仕組み・入口が組まれた状態を実物で確かめ、社名・写真・文章を差し替えて公開します。完成形を先に確認してから決めたい場合に向きます。この記事の集計は、その実際のサイトのデータです。
