WordPressの表示を速くするプラグイン「10Web Booster」に、ログインしていない第三者がサーバーにファイルを置けてしまう重大な脆弱性(CVE-2026-108587)が見つかりました。影響を受けるのは2.34.10以前で、危険度を示すCVSSスコアは最も高い区分の9.8です。10Web Boosterは6万以上のサイトで使われています。

結論から書くと、10Web Boosterを入れているサイトは、2.34.11以降へすぐに更新してください。修正版の2.34.11は2026年10月13日に公開されていて、当社でも公式の配布ファイルのコードを比べ、問題の箇所が直っていることを確認しました。使っていないサイトには影響はありません。ただし、すでに侵入されていた場合は更新だけでは足りないので、後半の確認点も見てください。

10Web Boosterの脆弱性(CVE-2026-108587)とは?

一言でいうと、画像を軽くする機能の入口に、ログインしていない人でも通れるすき間があり、そこから好きなファイルを置けてしまうという問題です。置かれたファイルがプログラム(PHP)だった場合、攻撃者はそのファイルを開くだけでサーバー上で命令を実行できます。こうなると、サイトの改ざん、迷惑メールの送信、ほかのサイトへの攻撃の踏み台など、サーバーを好きなように使われるおそれがあります。

項目 内容
脆弱性ID CVE-2026-108587
種類 任意のファイルのアップロード(ログイン不要)
危険度 CVSS 9.8(Critical:最も高い区分)
影響を受けるバージョン 2.34.10以前
修正版 2.34.11(2026年10月13日公開)
公表 2026年10月15日(Rapid7など)
利用サイト数 6万以上(WordPress.orgの表示)

なお、2026年10月16日時点で当社が確認した範囲(Rapid7・Patchstack・公式の配布ページ)では、この脆弱性を使った攻撃が実際に起きたという報告は見当たりませんでした。ただし、Patchstackは「大量のサイトをまとめて狙う攻撃に使われやすい種類」と注意を呼びかけています。ログイン不要で使える脆弱性は、公表から短い期間で自動の攻撃が始まることが多いため、報告がないうちに更新しておくのが安全です。

影響を受けるサイトと受けないサイト

影響を受けるのは、10Web Boosterの2.34.10以前が「有効化」されているサイトです。無効化したまま残っているだけなら、この脆弱性の入口は動きません。とはいえ、使っていないプラグインは削除しておくのが基本です。

  • 10Web Boosterを使っていない:影響なし
  • 2.34.11以降に更新済み:今回の脆弱性は修正済み(ただし更新前に侵入されていないかは別に確認)
  • 2.34.10以前を有効化している:すぐに更新が必要

また、10Web Boosterには、この1か月ほどで別の脆弱性も報告されています。ログイン不要で悪意のあるスクリプトを埋め込まれる問題(2.34.8以前)や、限られた範囲でファイルを書き込まれる問題(2.34.5以前)です。2.34.11へ上げれば、これらの影響バージョンもまとめて抜けられます。

自分のサイトで使っているか確認する方法

プラグイン一覧で10Web Boosterのバージョンを確認し、2.34.11へ更新するイメージ

確認は管理画面から1分ほどでできます。

  • WordPressの管理画面にログインする
  • 左のメニューから「プラグイン」→「インストール済みプラグイン」を開く
  • 一覧に「10Web Booster」があるかを探す(正式名称は「10Web Booster – Website speed optimization, Cache & Page Speed optimizer」)
  • 見つかったら、名前の下に表示されている「バージョン」の数字を確認する
  • 2.34.10以前なら「今すぐ更新」を押す

制作会社にサイトを作ってもらい、どんなプラグインが入っているか分からないという方も多いと思います。高速化やキャッシュの名前が付いたプラグインが入っている場合は、念のため一覧を確認してください。

更新の手順と注意点

更新は、プラグイン一覧の「今すぐ更新」か、「ダッシュボード」→「更新」から行えます。表示を速くするプラグインは、ページのキャッシュや画像の変換にかかわるため、更新前にバックアップを取り、更新後にトップページと主要なページの表示を確認するのが安全です。手順の詳細は安全なアップデート手順の記事にまとめています。

すぐに更新できない事情がある場合は、更新できるまでの間、10Web Boosterを一時的に無効化するのが現実的な対処です。表示は少し遅くなるかもしれませんが、サーバーを乗っ取られる危険と比べれば小さな影響です。当社が保守を担当しているサイトでは毎日7世代のバックアップを自動で取っているので、更新で表示が崩れても前日の状態へ戻せます。バックアップの取り方は別の記事で解説しています。

すでに侵入されていないか確認するポイント

更新は「これから入られないようにする」対策で、更新前に置かれたファイルは、更新しても消えません。2.34.10以前を使っていた期間がある場合は、次の点を確認してください。

  • 「ユーザー」一覧に、見覚えのない管理者アカウントがないか
  • wp-content/uploads の中に、画像ではないファイル(特に .php で終わるもの)がないか
  • uploads の直下に、見覚えのないフォルダが増えていないか
  • サイトを開くと別のサイトへ飛ばされる、検索結果に見覚えのないページが出る、といった異常がないか
  • サーバー会社から「迷惑メールの送信」や「不正なプログラム」の通知が届いていないか

uploadsは、本来は画像やPDFを置く場所です。ここにPHPファイルがあれば、ほぼ確実に不正なものです。ただし、自分で消すと証拠や他の入口を見落とすことがあるので、見つけた場合は消す前に専門家へ相談してください。駆除の流れはマルウェア駆除の記事にまとめています。

ここまでのまとめ

  • 10Web Booster 2.34.10以前に、ログイン不要でファイルを置かれる脆弱性がある
  • 修正版は2.34.11。使っているサイトはすぐ更新し、無理なら一時的に無効化する
  • 更新前に侵入されていた場合に備え、管理者アカウントとuploadsの中を確認する

ここから先は、制作者・開発者向けに、何が原因でどう直されたのかを説明します。

技術者向け:2.34.11で何が直ったのか(当社でコードを確認)

Rapid7の説明では、原因は2つの組み合わせです。1つは、画像を圧縮する処理(compressCustom)が受け取る page_id という値を検査していなかったこと。この値はキュー用のフォルダ名やファイル名を作るのに使われるため、拡張子やフォルダの区切りを含む値を渡されると、意図しない場所や種類のファイルが作られます。もう1つは、本来はログインした人だけが持つ確認用の値(nonce)が、誰でも読める場所のファイルに保存されていたことです。これで認証の確認をすり抜けられました。

当社では、WordPress.orgの公式配布から2.34.10と2.34.11を取り寄せて、コードを比べました(2026年10月16日)。変更されたのは主に画像最適化のキューとREST APIの部分で、公式の更新履歴にある「画像最適化キューとREST APIのセキュリティ強化」と一致します。修正の内容は次のとおりです。

2.34.10までの問題 2.34.11での修正
page_id の値を検査せず、フォルダ名やファイル名に使っていた 英数字・アンダースコア・ハイフンだけの64文字以内に制限。それ以外(ドットやスラッシュを含む値など)は受け付けない
処理の再開に使う確認用の値(nonce)を、外部から読めるファイルに書き出していた サーバー側に保存する、15分だけ有効で1回しか使えない合言葉(トークン)に置き換え。再開用のファイルには書き出さない
キュー用のフォルダが外部から読めた フォルダに .htaccess と空の index.html を自動で置き、Apacheでは外部から読めず、一覧も表示されないようにした
再開用のファイルが壊れていると処理が止まることがあった 読み込みに失敗したらファイルを消して、処理を続けるようにした

報告された2つの原因の両方に、対応する修正が入っていました。Patchstackの「2.34.11で修正」という情報とも一致するため、当社は2.34.11を修正版と判断しています。なお、.htaccessによる保護はApache向けで、Nginxだけで動いているサーバーでは効きません。Nginxの場合は、uploads配下でPHPを実行させない設定をサーバー側でも入れておくと安心です。

技術者向け:同じ種類の被害を防ぐための恒久対策

今回の脆弱性は、OWASP Top 10でいう「アクセス制御の不備」と「入力値の検査不足」が重なったものです。プラグイン側の修正とは別に、サイト側でも次の対策を入れておくと、似た脆弱性が見つかったときの被害を小さくできます。

  • wp-content/uploads でPHPを実行させない(Apacheなら .htaccess、Nginxならサーバー設定)
  • 使っていないプラグインは無効化ではなく削除する
  • WAF(ウェブアプリケーションファイアウォール)を有効にする。多くのレンタルサーバーに無料で付いています
  • 管理者アカウントの追加やファイルの変更を通知する仕組みを入れる
  • 使っているプラグインの脆弱性情報を、定期的に確認する

最後の「定期的な確認」は、数が増えると手間がかかります。当社では、保守を担当しているサイトで使っているElementor・Jetpack・WooCommerceなどのプラグインについて、生成AIを使って毎週脆弱性の情報を集め、該当するものがないかを確認しています。集めた情報は、今回のように公式の配布ページや脆弱性データベースで裏を取ってから判断します。プラグインを放置する危険については、放置されたプラグインのリスクの記事でも解説しています。

まとめ:まず更新、次に点検

10Web Booster 2.34.10以前には、ログインなしでサーバーにファイルを置かれる重大な脆弱性があります。使っているサイトは2.34.11以降へ更新し、更新できない場合は一時的に無効化してください。そのうえで、見覚えのない管理者アカウントや、uploadsの中の不審なファイルがないかを確認しましょう。過去にも、同じようにログイン不要で悪用できるTranslatePressの脆弱性が見つかっています。よく使われているプラグインほど狙われやすい、という点は変わりません。

「更新したいがサイトが壊れないか不安」「すでに何か置かれているかもしれない」という場合は、WordPressトラブル対応サービスで調査から復旧までお引き受けします。毎週の脆弱性の確認や更新を任せたい場合は、更新代行と毎日のバックアップをまとめた保守サポートサービスをご検討ください。まず現状を知りたい方は、無料AI診断でサイトのリスクを確認できます。

参考情報

この記事の内容は2026年10月16日時点の情報です。新しい情報が分かり次第、更新します。

この記事を書いた人

矢部 敦

矢部 敦合同会社Edel Hearts 代表

WordPress専門の開発会社を経営。プラグイン開発・カスタマイズ・保守を専門とし、18時間におよぶUdemyのWordPress講座を開講。出典付きで回答するAIチャットボット「Edel AI Hybrid Chat」開発者。著書『WordPress はじめての最小プラグイン』(Kindle)。本ブログの記事は、実際の開発・運用で得た一次情報をもとに執筆しています。会社情報はこちら

この記事をシェア