WordPress編集者から管理者を奪える、TinyMCEに4連の保存型XSS CVE-2026-47759〜47762

WordPressの「編集者」や「寄稿者」権限を持っているだけで、管理者アカウントを奪取できる──そんな保存型クロスサイトスクリプティング（XSS）が TinyMCE に 4本同時 に公開されました。番号は CVE-2026-47759 から CVE-2026-47762 の4連番、いずれもCVSS 8.7（High）です。

TinyMCEはWordPressの旧クラシックエディタの中核として有名になり、現在もWordPress本体・無数のWordPressプラグイン・有償テーマに広く組み込まれています。ただし影響範囲はWordPressにとどまらず、Joomla、Drupal、Umbraco、Shopify、HubSpot、Statamic、独自CMSやSaaSの管理画面など、TinyMCEを採用しているあらゆるサイトで「編集者から管理者を奪える」同じ経路が同時に成立します。

修正版は 8.5.1 / 7.9.3 / 5.11.1（LTS） の3系統で同時公開、公開日は2026年5月28日。記事公開時点で CISA KEV 登録は確認できていませんが、TinyMCEは OSSサプライチェーンの上流に位置する超広域コンポーネント であり、自社プロダクトに組み込まれている可能性を一度はチェックする価値があります。

TinyMCEとは何か、なぜこの4連は他人事ではないのか

TinyMCEは、ブラウザ上に「ブログのエディタ風UI」を提供するJavaScriptライブラリで、ユーザーが入力したリッチテキストをHTMLとして保存・再描画する仕組みです。公式ブログ によれば、TinyMCEはWordPressの旧クラシックエディタの中核として有名になり、現在はJoomla、Umbraco、Shopify、HubSpot、Statamic、その他無数のCMSで採用されています。

日本国内に絞っても、自社CMS、社内Wiki、お問い合わせ管理ツール、顧客対応SaaS、教育プラットフォームの記事編集画面に組み込まれているケースは珍しくありません。WordPressに至っては、CMSのある全Webサイトの約59.5%（全Webサイトの41.9%） を占めるため、間接的にせよTinyMCEの修正影響は無視できない規模になります。

攻撃者像と狙い、編集権限1個でどこまで届くのか

「XSSで管理者権限が取れる」と書くと、多くの方は「サーバのroot権限を取られるのか？」と読み替えがちですが、今回はそうではありません。先に届く先の境界線を引いておきます。

①のCMS管理者乗っ取りは、今回の4連XSSが直接届く範囲です。攻撃の流れは、低権限の編集者（寄稿者・新人ライター・サポート担当）が記事本文に悪性ペイロードを保存し、それを管理者・編集長・経営層がプレビューまたは閲覧で開いた瞬間に、相手のブラウザ上で任意JavaScriptが動きます。具体的に盗まれるのは管理者のセッションCookieやJWT、CSRFトークンです。そのCookieを手元に持ち帰った攻撃者は、以後 CMSの管理画面（/wp-admin、/admin、/manage など）に「正規の管理者として」入っていけます。CMSのなかでできることは全部できる、と理解してください。記事の改ざん・削除、ユーザー追加、会員DBからのメールアドレスや住所の抜き出し、Algoliaなどの外部APIシークレットの参照、Slackウェブフックの読み取り、いずれもCMS管理者の権限内です。

②のWebサーバプロセス権限でのRCEは、CMSの設計上「管理者ならPHPコードを書き込めて当然」だから起きます。WordPressが代表例です。管理画面にログインできれば、テーマエディタやプラグインアップロードから任意のPHPファイルを設置でき、それは www-data や nginx といったWebサーバプロセスの権限で実行されます。Drupal、Joomla、独自CMSでも管理者からのコード実行経路は多くの場合ふさがっていません。つまり、CMS管理者の奪取は Webサーバプロセス権限での任意コード実行とほぼイコール です。/var/www 配下のファイル読み書き、データベースへの直接接続、ログファイルへの書き込み、サーバ間SSH鍵の読み取りなど、サーバ側で起きる攻撃はここから一気に増えます。

③のOSのroot権限には、今回のCVEは 単体では届きません。OS root を取るためには、Webサーバプロセス権限を起点に Linuxカーネル系のローカル特権昇格脆弱性 や、sudo設定不備、SUIDバイナリ等を別途突く必要があります。読者の方は「CMSは陥落するが、サーバそのものは別のCVEがないと残る」という境界線を覚えておいてください。

この①〜②のレベルを欲しがるのは、技術コンテスト勢ではなく、明確に金や情報につながる買い手です。競合企業の社内CMSに寄稿者として潜り込み、未公開の編集中ドラフトや内部メモを抜き出したい産業スパイ、ヘルプセンター記事に偽ログイン誘導を仕込んでEC顧客のセッションCookieを大量に集める詐欺グループ、メディアサイトの新人ライターアカウントを買い叩き編集長プレビューの瞬間に管理者を奪うランサム前駆者、Wiki投稿権限のあるアルバイトを買収し社員全員が触る社内ナレッジページに監視スクリプトを仕込むIAB（Initial Access Broker） が中心です。彼らに共通するのは「サーバの root が欲しいのではなく、CMSとそのコンテンツDBが欲しい」という需要構造で、今回の4連XSSはまさにその欲しがり方に直結しています。

CVSS 8.7というスコアの背後で、CMSを運用する事業者が現実に背負うのは、編集権限1個から始まる管理者セッション奪取、それを起点としたコンテンツDB全件の読み出し・改ざん、WordPressのような「管理者＝PHP実行可能」な構造を持つCMSでは サーバ側ファイルシステムへの書き込みやデータベース直接アクセス にまで連鎖、そして公開記事を経由した一般読者への二次被害、最後に「うちのサイトが踏み台になっていた」という説明責任の連鎖です。

4本のCVEを個別に見る、抜け道はどこにあったのか

4本のCVEはいずれも「TinyMCEのサニタイザがHTMLの一部をすり抜けてしまう」という同じ系統の問題ですが、抜け道として使われた経路が4つに分かれています。順番に整理します。

CVE-2026-47759: data-mce-* 属性のサニタイズ漏れ

CVE-2026-47759 は、TinyMCE内部用のdata-mce-href、data-mce-src、data-mce-style属性が、エディタの内部処理用ということで通常のサニタイズ対象から外れていたところに、検証バイパスが可能なペイロードを書き込めた、というものです。攻撃者は通常のhref/src側のフィルタを正面突破するのではなく、data-mce-*側に毒を仕込むと、保存→復元の局面でDOMに反映される構造でした。対象は5.x < 5.11.1 / 7.x < 7.9.3 / 8.x < 8.5.1。

CVE-2026-47760: ネストSVGによるネームスペースバイパス

CVE-2026-47760 は、サニタイザのSVGネームスペースのスコープ管理が甘く、SVGの中にSVGを入れ子にすると属性のサニタイズが効かなくなる、というものでした。DEVCOREの研究者 maple3142 氏の発見で、修正にはサニタイザの該当部分の書き直しが必要になりました。対象は6.8.0〜7.1.0未満で、7.1.0で根本対応済み。

CVE-2026-47761: メディアプラグイン経由の data-mce-* 注入

CVE-2026-47761 は、47759と同じ「data-mce-*属性経由の保存型XSS」ですが、注入経路が media プラグイン（YouTube埋め込み等を扱う公式プラグイン）でした。YouTube/Vimeo/その他の埋め込みURLをエディタに貼り付けると<mce:object>系の特殊要素に変換される処理の中で、属性のチェックが緩かったというものです。対象は5.x < 5.11.1 / 7.x < 7.9.3 / 8.x < 8.5.1。

CVE-2026-47762: mce:protected コメント偽装

CVE-2026-47762 は、TinyMCEがコンテンツ内のスクリプトタグ等を一時的に<!--mce:protected ...-->形式のHTMLコメントに退避する「保護コメント」機構を悪用するものです。攻撃者は本物の保護コメントに似せた偽コメントを差し込み、コンテンツ復元時に検証を経ずにそのままDOMに戻させることで、任意のスクリプトを実行できました。修正では、デコードされた保護コメントを「事前に設定された保護対象の正規表現ルール」と照合してから復元する形に変わっています。対象範囲が広く、<5.11.1 / 6.0.0〜6.8.6 / 7.0.0〜7.9.3 / 8.0.0〜8.5.1 と、4世代にわたります。

バージョン別の影響範囲早見表

自社プロダクトに組み込んでいるTinyMCEのバージョンを確認し、4本それぞれの該当可否を素早く照らし合わせるための早見表です。

アップデート先の目安は 8.x系なら 8.5.1、7.x系なら 7.9.3、5.x系LTSなら 5.11.1。6.x系は商用サポート切れの状況に近いため、可能なら7.x系または8.x系への移行を検討すべきフェーズに入っています。

自社環境への組み込み状況を確認する手順

TinyMCEは多くの場合、自社プロダクトのpackage.json、composer.json、CDN参照、CMSプラグイン経由のいずれかに紛れ込んでいます。3段で確認します。

1. 直接の依存を洗う。npm系プロジェクトならnpm ls tinymce、Composerならcomposer show tinymce/tinymce、NuGetならdotnet list package | grep -i tinymceでバージョンを確認します。フロントエンドのバンドルログにもtinymceの名前が出ているか目視してください。

2. CDN直リンクを洗う。HTMLテンプレートからcdn.tiny.cloudやcdnjs.cloudflare.com/.../tinymceを grep -r で探します。CDN URLにバージョン番号が直書きされていれば、それを修正版に書き換えるだけで済みます。

3. CMSプラグイン経由を洗う。WordPressサイトの場合、クラシックエディタ系プラグインや有償CMSテーマがTinyMCEを内包しているケースが多いため、テーマとプラグインの更新状況を確認してください。Joomla / Umbraco / Statamic の場合は、CMS本体側の公式パッチ情報を待つほうが現実的です。

タイムライン

運用側がいま取るべき5つの動き

優先順に整理しておきます。

1. バージョン上げの計画を切る。8.x系を使っているなら8.5.1、7.x系なら7.9.3へ。5.x系LTSのまま運用している場合は5.11.1への上げが現実解です。LTS不要のサイトであれば、この機にメジャー系統を整理しても良いタイミングです。

2. 編集権限の棚卸し。攻撃の前提は「保存型」と「低権限編集アカウント」の組み合わせです。退職者・契約終了ライターのアカウントが残っていないか、寄稿者・編集者ロールに不要なメンバーがいないかを確認してください。

3. CSP（Content Security Policy）の見直し。script-src 'self'を中心にした厳格なCSPは、保存型XSSが踏まれた場合でも実行を抑止できる可能性があります。'unsafe-inline'を無条件に許可しているプロダクトは、今回をきっかけに見直す価値があります。

4. 管理画面アクセス元のIP制限・MFA徹底。XSS経由でCookie/JWTを抜かれても、管理画面が社内IPまたはVPN経由限定であれば、横展開の足止めができます。MFAも同様にセッションハイジャック後の追加制約として効きます。

5. 既存記事への保存型ペイロード混入チェック。今回4本は保存型なので、すでにDB内に潜んでいる可能性があります。data-mce-href、data-mce-src、data-mce-style、ネストされたSVG、<!--mce:protectedのいずれかが本文に含まれている記事がないか、DB側でgrepしてみてください。

まとめ、エディタは「単なるUI部品」ではない

リッチテキストエディタは「文字を太字にしたり画像を貼ったりするUI部品」と認識されがちですが、実態はユーザー入力を受け取ってHTMLとしてサーバに保存し、別ユーザーのブラウザでDOMに戻すという、保存型XSSにとって最も価値の高い経路上の制御装置です。サニタイザがどこか一箇所緩むだけで、CMS全体の信頼が崩れます。

今回の4連は、TinyMCE側のサニタイザに4つの抜け道が同時に見つかったというニュースですが、裏返せば TinyMCEの開発チームが4本まとめて公開する形できれいに修正を間に合わせた ということでもあります。読者として今やるべきことは、自社のスタックを開いて、TinyMCEの版数を確認することだけです。普段のCMSメンテナンス予定の中に、今週中に1コマ差し込んでおいてください。

参照元

• ▸ NVD - CVE-2026-47759
• ▸ NVD - CVE-2026-47760
• ▸ NVD - CVE-2026-47761
• ▸ NVD - CVE-2026-47762
• ▸ GitHub Security Advisory - GHSA-mh5m-5hw4-5c69 (CVE-47760)
• ▸ GitHub Security Advisory - GHSA-v98h-vmpc-fpqv (CVE-47762)
• ▸ TinyMCE 公式 Changelog
• ▸ 本サイト - OSSサプライチェーン スキャナー（ハブ記事）