Joomla JCE CVE-2026-48907がCISA KEV入り、更新後も不正プロファイルとPHPファイルを確認する

TL;DR

影響 Joomla Content Editor 1.0.0〜2.9.99.4。未認証ユーザーがエディタープロファイルを作成し、PHPファイルのアップロードと実行へ到達。CVSS v4.0 10.0

対応 JCE 2.9.99.7への更新（2.9.99.6は正規アップロードを誤検知で弾くリグレッションあり）。CISA KEV（悪用確認済み脆弱性カタログ）追加日は2026年6月16日、期限は2026年6月19日

確認 index.php?option=com_jce&task=profiles.import へのアクセス、見覚えのないエディタープロファイル、images、media、tmp 配下のPHPファイルや php を含む不審ファイル

Joomla Content Editor（JCE）のCVE-2026-48907が、2026年6月16日にCISA KEVへ入った。
対象はJCE 2.9.99.4以前で、CISAのJSONではWidget Factory Joomla Content Editorの不適切なアクセス制御として登録されている。
未認証ユーザーが新しいエディタープロファイルを作成し、そのプロファイル経由でPHPコードのアップロードと実行まで到達できる。

The Hacker Newsは、CISA KEV追加とあわせて、JCE公式の注意喚起、mySites.guruの実地確認、公開済み攻撃コードを整理している。
脆弱性を報告したのはYesWeHackのリサーチチームで、PoC（実証コード）はその後GitHubで別途公開された。
NVDではCVSS v4.0が10.0 CRITICAL、CVSS v3.1が9.8 CRITICAL。
CISAのSSVC（Stakeholder-Specific Vulnerability Categorization。対応優先度を決めるための分類）も、active、automatable、technicalImpact total になっている。

入口はプロファイル取り込みだった

JCEのエディタープロファイルは、ユーザーグループごとにエディタの機能やファイル操作を分ける設定だ。
アップロードできる拡張子、ファイルブラウザ、画像マネージャー、保存先ディレクトリといった権限が、プロファイル側で決まる。

今回の不具合は、そのプロファイルを取り込む処理に、未認証のリクエストがそのまま届いてしまう点にある。
攻撃者は自分で作ったプロファイルをインポートし、PHPやスクリプト系ファイルをアップロードできる設定をサイト側に作る。
そのプロファイルを足がかりに、ウェブシェル（HTTP経由で任意コマンドやPHPコードを実行する悪意あるファイル）を設置する。

YesWeHackの解析では、このRCEは3つの不備が連鎖して成立している。
1つ目は認可の欠落で、プロファイル取り込みハンドラはCSRFトークンしか確認せず、ユーザー認証を見ていなかった。
2つ目は拡張子検証の不在で、ファイル名を整える File::makeSafe() はファイルシステムで使えない文字を落とすだけで、拡張子の種類は見ない。そのため nuclei-<hash>.xml.php のような二重拡張子がそのまま通る。
3つ目はアップロード安全機構の無効化で、内部の File::upload($source, $destination, false, true) が第4引数（unsafe許可）を true で呼び、Joomla内蔵の拡張子ブラックリストを明示的に外していた。

攻撃の実体は、まず公開ページのHTMLからCSRFトークンを拾い、profiles.import へ細工したマルチパートリクエストを送ってプロファイルを差し込む。
そのプロファイル経由でウェブシェルを tmp 配下へ書き込み、HTTP GETでそのファイルにアクセスするとPHPが実行される。

mySites.guruは、実際のJoomlaサイトで不正プロファイルとウェブシェルを確認したと書いている。
最初はひとつの管理対象ポートフォリオ内の3サイトから始まり、その後は数百件を見ているという。
公開攻撃コードが2026年6月9日に出た後は、JCEサイトへの自動化された攻撃が広がっていて、mySites.guruは今後数日で数千件規模になると見込んでいる。
同種の未認証アップロードだった2012年のImageManager脆弱性が最終的に数万サイトへ達した点を、規模の参照点として挙げている。
標的の中心はLinuxのWebサーバーだと報じられている。

公開登録機能を閉じているかどうかでは判断できない。
今回の入口は登録ユーザーの作成ではなく、未認証のプロファイル取り込みタスクなので、外部からJCEコンポーネントへ届くサイトは同じ確認対象になる。

flowchart TD
    A["公開ページからCSRFトークン取得"] --> B["未認証でprofiles.importへ送信"]
    B --> C["不正な取り込みプロファイル作成"]
    C --> D["拡張子ブラックリストを無効化"]
    D --> E["二重拡張子 .xml.php を tmp配下へ設置"]
    E --> F["HTTP GETでPHPコード実行"]

2.9.99.5で入口を閉じ、2.9.99.7まで上げる

JCE公式は2026年6月3日にJCE 2.9.99.5を出し、2.9.99.4以前の重大な脆弱性を修正した。
6月6日の2.9.99.6では、攻撃経路を狭める防御をさらに追加した。
ただし2.9.99.6にはPHPタグの誤検知で正規の画像・ファイルアップロードまで弾く不具合があり、それを直してハードニングを足したのが2.9.99.7だ。
更新先は2.9.99.6で止めず、2.9.99.7まで上げる。

2.9.99.7はPHP 7.4以上、Joomla 3.10以上を要求する。
そこまで上げられないサイト向けに、JCE 2.7.x、2.8.x、2.9.x用の無償パッチパッケージも用意されている。
ただしこれは脆弱性の入口だけを閉じるもので、2.9.99.6以降の追加防御までは反映されない。
JCE 2.6.xはデフォルト構成では未認証プロファイル取り込み経路が塞がれているようだが、公式自身も独立検証前として扱っている。2.6.xはサポート対象外なので、移行計画には引き続き含める。

CISA KEV入りで重要なのは、スコアの高さよりも悪用が確認された状態に移ったことだ。
このブログでもLiteLLMのCISA KEV入りRCEで書いたが、KEVは「理論上危ない」ではなく「実際に悪用が確認された」リストとして運用される。
今回の期限は2026年6月19日で、追加から3日しかない。

更新だけでは置かれたファイルが残る

JCE公式が強めに書いているのは、アップデートとクリーンアップが別作業だという点だ。
JCEを更新するとプロファイル取り込みの入口は閉じる。
しかし、更新前に作られた不正プロファイルや、すでに置かれたPHPファイルは自動では消えない。

JCEの管理画面で、作った覚えのないエディタープロファイルを確認する。
mySites.guruが報告している不正プロファイルは、大文字の J ＋6桁の数字という機械生成の名前（J940401、J938560 など）が多い。
Pwned という名前で、説明欄に RCE via JCE と入ったものも見つかっている。
並び順を決める ordering に -99999 のような大きな負値を入れて、一覧の最上位へ強制しているケースもある。
そのプロファイル内で、Image ManagerやFile BrowserのPermitted File ExtensionsにPHPやスクリプト系拡張子（php、phtml、txt）が入っていないかを見る。

データベースから直接当てる場合は、#__wf_profiles テーブル（#__ はJoomlaのテーブル接頭辞）を名前のパターンで検索する。

SELECT id, name FROM `#__wf_profiles` WHERE name REGEXP '^J[0-9]{6}$';

ログでは、未認証のまま並ぶ次の2リクエストを探す。

POST .../index.php?option=com_jce&task=profiles.import                          → 200
POST .../index.php?option=com_jce&task=plugin.rpc&plugin=browser&method=upload  → 200

取り込み（profiles.import）の直後に、ブラウザプラグインのアップロード（plugin.rpc）が200で続く並びが、典型的な攻撃の痕跡になる。
URLに id=RCExxx（RCEc37、RCE401 など）という攻撃者のマーカーが残ることもある。
最初のリクエストの時刻が、侵害開始時刻の目安になる。
ホスティング環境ではアクセスログの保存期間が短いことがあるので、更新作業の後回しにすると、最初に踏まれた時刻を拾えなくなる。

ファイル側では、images、media、tmp に加えて media/system/js、libraries/joomla 配下にPHPファイルがないかを確認する。
JCE公式は、foo.php.xml のようにファイル名へ php を含めたものにも触れている。
mySites.guruは、.xml.php の二重拡張子ドロッパー、eval(gzinflate(base64_decode(...))) や shell_exec($_POST) を含む難読化ウェブシェル、Nxploited というマーカーファイルを実例として挙げている。
プロファイル側にアップロード先が指定されていない場合、デフォルトの images に保存されるため、そこから見る。

ShowDocのファイルアップロードRCEでも同じ形だった。
アップロード機能の拡張子制御が崩れると、攻撃者はPHPファイルをウェブから呼べる場所へ置き、以後は通常のHTTPアクセスだけでサーバー上のコード実行へ進む。
JCEでは、プロファイルを差し替えることで、アップロードの可否そのものを攻撃者が決められる点が違う。

既存サイトの判断はJCEの有無から始める

このブログではJoomla・JCE・Widget Factory自体を扱った記事はまだない。
近いのは、CISA KEV入りしたRCEや、CMS・PHP系のファイルアップロードで侵害後にウェブシェルが残るパターンで、対応の型はそちらと同じだ。

管理対象が複数ある場合、最初に確認するのはJCEのインストール有無とバージョンだ。
JCE FreeとJCE Proのどちらも対象になる。
2.9.99.4以前なら、外部公開の有無、登録機能の有無、Joomlaのメジャーバージョンに関係なく、更新と痕跡確認を同じチケットで扱う。

侵害が見つかった場合は、削除前に不正プロファイルと不審ファイルのコピーを残す。
その後、JCEを2.9.99.7へ更新して入口を閉じ、不正プロファイルとアップロードされたファイルを削除する。
管理者ログイン、データベース、ホスティング、FTPのパスワードを変え、ログインセッションも無効化する。
同じ認証情報を他サイトで使い回していた場合は、そちらも合わせて入れ替える。
最後に、他にバックドアが残っていないかフルスキャンで確認する。