WordPressの脆弱性に関する情報として、wp2shell という呼び方を見かけた方もいるかもしれません。
2026年7月17日に、WordPress 7.0.2 がセキュリティリリースとして公開されました。あわせて、WordPress 6.9 系と 6.8 系にも修正版が用意されています。
今回の件で大事なのは、攻撃手法の細部を追うことではなく、自分のサイトが影響を受けるバージョンかどうかを確認し、必要な更新と点検を早めに済ませることです。
まず結論。該当バージョンならすぐ更新を
今回確認すべき更新先は、利用しているWordPressの系統によって変わります。
| 利用中の系統 | 影響を受けるバージョン | 更新先 |
|---|---|---|
| WordPress 7.0系 | 7.0.0 – 7.0.1 | 7.0.2 |
| WordPress 6.9系 | 6.9.0 – 6.9.4 | 6.9.5 |
| WordPress 6.8系 | 6.8.0 – 6.8.5 | 6.8.6 |
WordPress公式リリースでは、WordPress 6.9 は2つの脆弱性の影響を受け、WordPress 6.8 はそのうち1つの影響を受けると説明されています。6.8より前のバージョンは、今回の2件については影響を受けないとされています。
ただし、古いWordPressを使い続けること自体が安全という意味ではありません。今回の件に該当しない場合でも、保守されていないコア、プラグイン、テーマが残っていれば別のリスクになります。
wp2shellとは何を指しているのか
wp2shell は、少なくともWordPress公式リリース本文で使われている正式名称ではありません。
今回のWordPress 7.0.2セキュリティリリースで修正された問題は、公式には次のように説明されています。
WP_Queryのauthor__not_inパラメータに関するSQLインジェクション- REST API batch-route confusion とSQLインジェクションが組み合わさることで、WordPress 6.9以降ではリモートコード実行につながる問題
GitHub Security Advisoryでは、後者はCriticalとして扱われています。つまり、WordPress 6.9.0以降または7.0.0以降を使っているサイトでは、単なる注意喚起ではなく、優先度の高い更新対象として見るべき内容です。
ここでは攻撃コードや再現手順には触れません。サイト運用者に必要なのは、「どう攻撃するか」ではなく、「自分のサイトが対象か」「更新できているか」「更新後に何を確認するか」です。
自分のWordPressバージョンを確認する
管理画面から確認する場合は、WordPress管理画面の「ダッシュボード」または「更新」画面で現在のバージョンを確認します。
SSHとWP-CLIが使える場合は、次のコマンドで確認できます。
wp core version
wp core check-update該当バージョンだった場合は、バックアップを取った上で、コア更新を進めます。
wp core update
wp core version複数サイトを管理している場合は、1サイトずつ結果を記録しながら進めることをおすすめします。自動更新が有効でも、「自動更新されているはず」で止めず、実際のバージョンを確認するところまでを1セットにします。
更新前にバックアップを取る
緊急度の高いセキュリティ更新でも、バックアップなしで本番サイトを触るのは避けたいところです。
最低限、次の2つは残してから更新します。
- データベースのバックアップ
wp-content配下のバックアップ、またはサーバー側の復元ポイント
WP-CLIでデータベースを書き出すなら、公開ディレクトリから直接アクセスできない場所に保存します。
mkdir -p ~/wp-backups
wp db export ~/wp-backups/site-before-core-update.sqlバックアップファイルをWordPressルート直下やuploads配下に置きっぱなしにすると、別の事故につながることがあります。ダウンロード後に削除する、公開されないディレクトリへ置く、アクセス制限をかけるなど、保管場所にも注意が必要です。
更新後に確認したいこと
コアを更新したら、バージョン確認だけで終わらせず、サイトの状態も見ます。
まずは基本的な表示確認です。
- トップページが表示されるか
- 主要な固定ページが表示されるか
- 問い合わせフォームが動くか
- 管理画面にログインできるか
- キャッシュプラグインやサーバーキャッシュを使っている場合、古い表示が残っていないか
次に、改ざんや不審な変更がないかを確認します。
wp core verify-checksums
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp plugin list --status=activewp core verify-checksums は、WordPressコアファイルが公式配布物と一致するかを確認するためのコマンドです。日本語ファイルや一部環境では注意が必要な場面もありますが、コア改ざんの初期確認として役立ちます。
管理者ユーザーの一覧では、見覚えのないユーザーが増えていないかを確認します。プラグイン一覧では、知らないプラグインが有効化されていないか、最近追加されたものがないかを見ます。
セキュリティプラグインだけでは代わりにならない
WAFやセキュリティプラグインは、攻撃の一部を防いだり、ログを残したりする上で役立ちます。
ただし、今回のようにWordPressコア側で修正版が出ている場合、最優先はコア更新です。セキュリティプラグインが入っているから更新しなくてよい、という判断にはなりません。
同じように、レンタルサーバー側のWAFも重要ですが、脆弱なバージョンを残したままにする理由にはなりません。防御層は複数あるほどよい一方で、修正済みバージョンへ上げることが土台です。
制作会社や保守担当者が見るべきポイント
制作会社や複数サイトの保守担当者は、1サイトだけでなく、管理対象全体の棚卸しが必要になります。
今回のようなコア脆弱性では、次のような台帳があると対応が速くなります。
| 確認項目 | 見る内容 |
|---|---|
| サイトURL | 管理対象の漏れがないか |
| 現在のWordPressバージョン | 影響対象かどうか |
| 更新後のバージョン | 修正版に上がったか |
| バックアップ取得 | 更新前に取得済みか |
| 表示確認 | 主要ページが正常か |
| 管理者ユーザー確認 | 不審な管理者がないか |
| 備考 | キャッシュ、プラグイン競合、個別事情 |
ポイントは、「更新しました」だけで終わらせないことです。いつ、どのサイトを、どのバージョンからどのバージョンへ更新し、更新後に何を確認したか。そこまで残しておくと、あとから問い合わせや調査が必要になったときに慌てずに済みます。
古いままにしているサイトほど、見直しのきっかけに
WordPress 6.8より前は今回の2件については影響を受けないとされています。しかし、古いWordPressを意図的に止めているサイトは、今回とは別の理由でリスクを抱えていることがあります。
たとえば、次のような状態です。
- PHPバージョンが古く、WordPressを上げられない
- テーマが古く、更新すると表示が崩れる
- 放置されたプラグインが残っている
- 誰が更新判断をするのか決まっていない
- バックアップや復元手順が確認されていない
セキュリティリリースは、「その場の更新」だけでなく、「そもそも更新できる状態になっているか」を見直すタイミングでもあります。
更新できない理由がある場合は、理由をそのままにせず、検証環境、代替プラグイン、テーマ改修、PHP更新、バックアップ設計まで含めて段階的に整理する必要があります。
まとめ
wp2shellとして話題になっている今回のWordPress脆弱性は、WordPress 7.0.2、6.9.5、6.8.6で修正されています。
特にWordPress 6.9以降では、REST APIの問題とSQLインジェクションが組み合わさり、リモートコード実行につながる問題として扱われています。該当バージョンを使っている場合は、早めに更新し、更新後の点検まで行うべき内容です。
WordPress保守で大切なのは、脆弱性情報を見た瞬間に慌てることではなく、確認手順を持っていることです。
現在のバージョンを確認する。バックアップを取る。更新する。表示と管理者ユーザーを確認する。必要ならログやファイル変更も見る。
地味ですが、この一連の流れを毎回きちんと行えるかどうかが、WordPressサイトを安全に運用できるかの分かれ目になります。
