Joomla拡張「Page Builder CK」の未認証ファイルアップロードによるRCE(CVE-2026-56290)の機構と対策

Joomlaサイトのページ作成に広く使われる拡張Page Builder CKに、ログインなしでサーバー上へファイルを置かれ、そのままコードを実行されうる脆弱性が見つかりました。CVE-2026-56290です。前面(フロントエンド)のファイルアップロード処理が認証もアクセス制御も持たず、保存先フォルダとファイル名を拡張子ごとリクエストのまま受け取ってしまうため、認証を通していない攻撃者がPHPのWebシェルをWeb公開ディレクトリに設置し、リモートコード実行(RCE)に至ります。すでに実環境での悪用が観測され、CISAはKnown Exploited Vulnerabilities(KEV)カタログへ収録して早期の是正を求めています。

この記事は、Joomlaサイトを運用する開発者や情報システムの担当者に向けて、何がどう壊れるのかという機構を、NVDやCISA KEV、ベンダー公式の告知をもとに冷静に整理します。攻撃を再現するペイロードや手順は示しません。事実は執筆時点(2026年7月24日)で確認できた範囲に限り、検証は自組織が管理するサイトに対してのみ行う前提です。

Page Builder CKの脆弱性CVE-2026-56290の全体像#

Page Builder CKは、joomlack.fr(Joomlack)が提供するJoomla向けのページ作成拡張です。CVE-2026-56290は、この拡張の前面にあるファイルアップロード機能が、認証と認可のチェックを一切行わないまま外部からのアップロードを受け付けてしまう欠陥です。攻撃者はログインせずに実行可能なファイルをアップロードでき、その結果としてWebサーバー上で任意のコードを実行できます。

NVDはこの脆弱性をCWE-434(危険な種類のファイルの無制限アップロード)に分類しています。一方でCISA KEVは根本原因に着目し、脆弱性名を「Joomlack Page Builder Improper Access Control Vulnerability」として不適切なアクセス制御(CWE-284相当)と位置づけています。認証と認可が働かないという入り口の欠陥が、危険な拡張子のファイルを置けてしまうという結果につながっている、という二段の見立てです。

深刻度の数値は情報源によって表現が分かれます。CNAであるJoomla!プロジェクトはCVSS 4.0で10.0(Critical)を付与し、NISTはCVSS 3.1で9.8(Critical)を付与しています。いずれも上限に近い評価で、未認証かつネットワーク経由で完全なコード実行に至るという性質を反映しています。

認証を通さないアップロード口がRCEに至る機構#

問題の核心は、Page Builder CKの前面アップロード処理が満たすべき二つの確認を欠いていた点にあります。ひとつはリクエストを送った相手がログイン済みかという認証の確認、もうひとつはその相手にアップロードの権限があるかという認可の確認です。脆弱な版ではこのどちらも行われませんでした。

唯一の防御はCSRFトークンの検証でした。ただしCSRFトークンは、正規の画面遷移かどうかを見分けるための仕組みであって、相手が誰かを確かめるログインではありません。しかもこのトークンはサイトの公開ページから1回のリクエストで誰でも取得できたため、攻撃者はまず公開ページからトークンを拾い、それをアップロード要求に添えるだけで検証を通せました。

さらに、このアップロード処理は保存先フォルダをリクエストのパラメータからそのまま受け取り、ファイル名も拡張子を含めて送られたとおりに使いました。これにより攻撃者は、拡張子.phpのファイルを、Webから直接実行できるディレクトリへ狙って置けます。認証の欠如と、攻撃者が保存先とファイル名を選べることが重なり、置いたPHPを外部からHTTPで叩いて動かすというRCEが成立します。ファイルアップロードの取り扱いがなぜコード実行に直結するのか、その原理は次の記事で基礎から整理しています。

あわせて読みたい

ファイルアップロード機能の脆弱性と対策。Webシェルを置かせないための検証と保存の設計

このように、認証や認可という入り口の制御が抜けたことが被害の根にあります。アクセス制御の不備はWebアプリの代表的な弱点で、OWASP Top 10でも上位に位置づけられます。設計段階でどこを守るべきかは、次の記事で整理しています。

あわせて読みたい

OWASP Top 10とは。開発者が押さえるべきWebの代表的リスクと対策を一気に理解する

mySites.guruは、脆弱な版の前面アップロード処理が認証も認可も行わず、検証はCSRFトークンのみで、そのトークンは公開ページから取得できたと説明しています。あわせて、エンドポイントが保存先フォルダとファイル名(拡張子を含む)をリクエストのまま受け取ったこと、影響は3.5.10以前で修正版3.6.0が2026年6月27日に公開されたこと、実際に設置されたアップローダ型Webシェルの存在を記載しています。

Webシェル設置とその後の持続化#

観測された悪用では、攻撃者はこの欠陥を使ってサーバー上にPHPのWebシェルを設置しました。設置されたのは、外部からのPOSTを受けて追加のファイルアップロードを行う小さなアップローダ型のシェルで、Page Builder CK配下のメディアフォルダなど、Webから到達できる場所に置かれた事例が報告されています。いったんこの種のシェルが動くと、攻撃者は同じ経路でさらにファイルを追加し、サーバー内での活動を広げられます。

Webシェルはあくまで足がかりであり、攻撃者はそこから持続的なアクセスの確保に進むことがあります。ベンダーの復旧手引きは、侵害時に確認すべき痕跡として、身に覚えのない管理者(Super User)アカウント、不審なスケジュールタスクやCRONジョブ、改ざんされたファイルを挙げています。これらは、パッチを当てても消えません。修正版へ更新して入り口を塞いだあとも、すでに置かれたシェルや作られた不正アカウントが残っていれば、そこから再び侵入されるためです。更新と痕跡調査を別々の作業として両方進める必要があります。

攻撃再現のコードや、シェルの中身そのものはこの記事では扱いません。検証を行う場合も、自組織が管理する資産に対してのみ、関連法令や利用規約を守って実施します。

Joomlack公式フォーラムは、Page Builder CK 3.5.x系に脆弱性が見つかったこと、少なくとも3.6.0へ更新すべきこと、Joomla 3系とJoomla 4系の双方に修正を提供したことを告知しています。侵害時の対応として、6月初旬の正常なバックアップと現在のファイルを比較して不審な追加を特定すること、Super Userのパスワードとデータベース資格情報を変更すること、不正な管理者アカウントの削除、不審なスケジュールタスクやCRONジョブの削除を挙げています。

影響を受ける版と修正版#

影響と修正の対応は次の表のとおりです。バージョンはNVDおよびベンダー公式の記載にもとづきます。

対応の基本は、Page Builder CKを3.6.0以降へ更新することです。ベンダーによれば、修正はJoomla 3系とJoomla 4系のそれぞれに向けても提供されているため、古い系統を使っている環境も、提供されている最新のセキュリティ修正へ更新します。更新はJoomla管理画面のシステムから拡張機能の更新として適用できます。

拡張機能の更新を後回しにしないという運用の勘所は、この事例に限らず被害を左右します。更新をためらう理由と、それでも早期に当てるための考え方は、次の記事で整理しています。

あわせて読みたい

ソフトウェア更新が脆弱性を塞ぐ仕組みと放置したときのリスク

NVDはCVE-2026-56290を、Joomlack.frのPage Builder CK拡張における未認証の任意ファイルアップロードで、実行可能ファイルをアップロードでき完全なRCEに至るものと記載しています。CWE分類はCWE-434(危険な種類のファイルの無制限アップロード)で、CVSSはCNA(Joomla!プロジェクト)がCVSS 4.0で10.0、NISTがCVSS 3.1で9.8です。採番はJoomla!プロジェクトです。

CISA KEVへの収録と実悪用の状況#

CVE-2026-56290は、修正版の公開とほぼ同時に悪用が始まった事例です。修正版3.6.0が2026年6月27日に公開された前後から、実環境でWebシェルを設置する試みが観測されました。CISAは2026年7月7日にこのCVEをKEVカタログへ収録し、連邦文民行政機関に対して2026年7月10日までの是正を求めました。3日という短い是正期限は、悪用が進行中である深刻さを反映しています。

KEVに付く是正期限は米連邦文民機関に向けたもので、民間組織に同じ日付が義務づけられるわけではありません。ただし実悪用が確認されている以上、民間にとっても緊急対応の目安として扱うのが妥当です。KEV収録やEPSSを使って対応の優先順位を組み立てる考え方は、次の記事で整理しています。

あわせて読みたい

脆弱性対応の優先順位付け。CVSSだけに頼らないEPSSとCISA KEVの使い方

外部に公開されたCMSの拡張が、認証なしで大規模に狙われるという構図は、同時期のWordPress Coreの未認証RCE(wp2shell)とも共通します。公開直後にPoCが出回り、無差別のスキャンが始まるという展開は近年繰り返し起きており、更新の速さがそのまま被害の分かれ目になります。同時期のCMS大量悪用の事例は次の記事でも扱っています。

あわせて読みたい

WordPress Coreの未認証RCE「wp2shell」(CVE-2026-63030)。バッチREST APIのルート取り違えがSQLiと連鎖する機構

CISA KEVカタログのデータには、CVE-2026-56290がベンダーJoomlack、製品Page Builderの「Improper Access Control Vulnerability」として、収録日2026-07-07、是正期限2026-07-10で登録されています。あわせてCVE-2026-48908(JoomShaper SP Page Builder)も同じ収録日と是正期限で登録されています。

並行して悪用されたSP Page Builderの脆弱性#

同じ時期に、別のJoomla拡張であるSP Page Builder(ベンダーJoomShaper)でも、未認証の任意ファイルアップロードCVE-2026-48908が悪用されました。仕組みはよく似ていますが、別の拡張の別のCVEであり、バージョンや対処も異なります。混同を避けるため、確認できた事実だけを分けて整理します。

CVE-2026-48908は、SP Page Builderの1.0.0から6.6.1に影響し、6.6.2で修正されています。NVDはこちらもCWE-434に分類しています。報告によれば、ゼロデイとして悪用され、攻撃者が新たなSuper User(管理者)アカウントを作成する挙動が確認されました。CISAはこのCVEもCVE-2026-56290と同じ2026年7月7日にKEVへ収録し、是正期限を2026年7月10日としています。

自組織でSP Page Builderを使っている場合は、6.6.2以降へ更新し、身に覚えのないSuper Userアカウントが作られていないかをあわせて確認します。二つの脆弱性は別物ですが、Joomlaエコシステムを狙った同時期の一連の動きとして、拡張の棚卸しと更新をまとめて見直すのが実務的です。

NVDはCVE-2026-48908を、JoomShaperのSP Page Builder(1.0.0から6.6.1)における未認証の任意ファイルアップロードで、最終的にPHPコードのアップロードと実行に至るものと記載しています。修正版は6.6.2、CWE分類はCWE-434、CVSSはCVSS 4.0で10.0、CVSS 3.1で9.8です。

運用側がとる初動#

Page Builder CKを使ったJoomlaサイトを外部に公開している場合、悪用が確認されている以上、更新と侵害調査を並行して進めます。次の順序で手を付けます。

確認チェックリスト#

対応の抜けを防ぐための確認項目を整理します。

まとめ#

CVE-2026-56290は、Joomla拡張Page Builder CKの前面アップロード処理が認証も認可も行わず、保存先フォルダとファイル名を拡張子ごとリクエストのまま受け取ることで、未認証の攻撃者にWebシェルを設置され、リモートコード実行に至る脆弱性です。唯一の防御だったCSRFトークンは公開ページから取得でき、認証の代わりにはなりませんでした。影響は3.6.0より前で、修正版3.6.0は2026年6月27日に公開されています。CISAは2026年7月7日にKEVへ収録し2026年7月10日までの是正を求め、同日に別拡張SP Page BuilderのCVE-2026-48908も収録されました。実悪用が確認されている以上、更新を最優先で進めつつ、パッチだけでは消えないWebシェルや不正な管理者アカウントの痕跡を更新前の侵害を前提に点検する判断が妥当です。脆弱性の悪用にあたる検証は、許可された自組織の資産に対してのみ行います。第三者のシステムを対象にする場合は、所有者や運用者からの明示的な事前許可を得たうえで、不正アクセス禁止法などの適用法令やホスティング事業者の利用規約を守って実施します。