WordPress本体に、ログインしていない相手がサーバー上で任意のコードを実行できてしまう脆弱性の組み合わせが見つかり、開発チームが緊急の修正版を公開しました。プラグインやテーマ側ではなく本体そのものの問題で、特別な設定や特定の拡張を入れていないサイトも対象になります。

公開は2026年7月17日。研究者が付けた「wp2shell」という呼び名で各所のセキュリティメディアが報じており、公開から数日のうちに実際に狙われている事例も確認されています。WordPressを扱っている制作者としては、いったん手を止めて手元の案件を見直しておきたい内容です。

本体だけで成立してしまう経路

今回問題になったのは二つの弱点です。ひとつは、WordPress 6.9で導入されたREST APIのバッチ処理用エンドポイントで、複数のリクエストをまとめて処理する際に権限の確認が正しく働かない場合があるというもの。もうひとつは、WP_Queryのauthor__not_inというパラメータに残っていたSQLインジェクションの穴で、こちらは6.8の系統から存在していたとされています。

単独で見ればどちらも即座に致命傷というわけではないのですが、順につないでいくと、認証を一切通らないまま任意のコードの実行まで到達します。プラグインを一つも入れていない素のWordPressでも成立する点が、今回いちばん重く受け止められている理由です。REST APIは投稿画面やブロックエディタが日常的に使っている入口なので、単純に閉じてしまえば済むという性質のものでもありません。

対象になる版と修正が入った版

修正版として出ているのは 7.0.2、6.9.5、6.8.6 の三つです。7.0.0から7.0.1、6.9.0から6.9.4、そして6.8系の古い版が対象に含まれます。自分の案件がどの系統で止まっているかによって、上げるべき先が変わる形です。

数年前に納品してそのまま動いている中小企業のサイトほど、メジャー更新を意図的に止めているケースが多いはずです。テーマや古いプラグインとの相性を心配して更新を保留する判断自体は珍しくありませんが、今回のように本体側で認証を通らない経路が見つかった場合は、その保留がそのまま危険の持ち越しになります。

なお、SQLインジェクション側の穴は6.8の系統から存在していたとされる一方で、実際に危険な連鎖として成立するのはREST APIの入口が加わった6.9以降です。古い版だから安全という話ではなく、修正版が出ている以上はどの系統でも上げておくのが素直な対応になります。

強制的な自動更新という対応

WordPress.orgは、対象となるサポート中のインストールに向けて自動更新を強制的に配信する措置を取りました。マイナー更新が自動で当たる仕組みは以前から用意されていましたが、深刻度に応じてここまで踏み込んだ形で運用されるのは、それだけ状況が急いでいるという合図と読めます。

ただし、この仕組みに全面的に寄りかかるのも避けたいところです。自動更新を明示的に無効化している環境、ファイルの書き換えを禁止している構成、独自の配置で運用しているサイトなどでは、そもそも配信が届きません。届いているつもりで届いていない、という状態がいちばん危ないパターンです。

受託で複数のサイトを預かっている立場だと、更新方針が案件ごとにばらばらというのもよくある話です。どのサイトが自動更新に任せてあって、どのサイトが手動運用なのか。今回のような場面で真っ先に効いてくるのは、その一覧がすぐ出てくるかどうかという、地味な管理の部分だったりします。

制作者側で確認しておきたいこと

まずは管理している各サイトのバージョンを実際に開いて確認するのが先です。更新が当たっているサイトはそれで終わりですが、当たっていないサイトが一つでも出てきたら、その環境で自動更新が働いていない理由を確かめておく価値があります。サーバー側で遮断する運用を取っている場合は、バッチ処理用のエンドポイントへの外部からのアクセスを一時的に止める手も選択肢に入ります。

抜けやすいのは、日常の運用から外れているサイトです。検証用に残したままの複製、しばらく更新していない古い案件、担当が変わって誰も見ていないサブドメイン。攻撃する側は運用の熱心さで対象を選り好みしないので、忘れられているサイトほど先に踏まれます。案件一覧を開いて、更新の当たり具合を一通り眺めておくだけでも、この週末の作業としては十分に意味があります。