Magento通販に乗っ取りの脆弱性 CVE-2026-45247、攻撃発生中で即更新を

世界中のネット通販サイトの土台として使われているMagento（Adobe Commerce）向けの拡張機能に、ログインせずに遠隔から店のサーバーを乗っ取れる脆弱性が見つかりました。CVE-2026-45247として公開され、深刻度は10点満点中9.8（緊急）です。

問題が厄介なのは、これがすでに「狙われている穴」だという点です。セキュリティ企業のImpervaは、修正版が出た直後から実際にこの脆弱性を突こうとする攻撃を観測しています。米政府機関のCISAも、現に攻撃へ使われている脆弱性をまとめた「悪用が確認された脆弱性リスト（KEV）」に本件を登録しました。問題の拡張機能を作るMirasvitは2026年5月25日に修正版を公開しており、対象店舗にはただちの更新が呼びかけられています。

そもそもMagentoとMirasvitの拡張機能とは何か

Magentoは、ネット通販サイト（オンラインショップ）を構築するためのソフトウェアです。商品ページ、買い物カゴ、会計（決済）、会員管理といった、お店をネット上で動かすための機能が一式そろっており、世界中の中小から大手まで、数多くのネット通販がこのMagentoの上で動いています。Adobeが買収して以降は、企業向けの有償版が「Adobe Commerce」という名前でも提供されています。

そのMagentoには、機能を後から追加する「拡張機能（プラグイン）」という仕組みがあります。今回問題になったのは、Mirasvit Full Page Cache Warmerという拡張機能です。これは、ページの表示を速くするために「キャッシュ（あらかじめ作っておいた表示結果）」をあらかじめ温めておく（warm up）ための部品で、表示速度を気にするお店が導入しています。買い物客がその名前を目にすることはまずありませんが、店の裏側で静かに動いている縁の下の力持ちのような存在です。

今回の問題は、この拡張機能が「ブラウザから送られてきたデータを、元のプログラム部品の形に戻す」ときに起きます。この「データを元に戻す」処理は専門的にはデシリアライゼーションと呼ばれ、PHP（Magentoが使っているプログラミング言語）やJavaの世界では昔から事故の多い、危険な処理として知られてきました。同じ仕組みが原因の事故は、つい先日報じた通信部品Apache MINAの乗っ取り脆弱性でも登場しています。

CVE-2026-45247で何が起きるのか

攻撃者は、細工した「クッキー」を店のサイトに送りつけるだけで、サーバー上で好きなプログラムを動かせます。クッキーとは、ブラウザがサイトとやり取りする小さなデータのことで、本来はログイン状態の保持などに使われる無害なものです。ところがこの拡張機能では、攻撃者が中身を自由に書き換えたクッキーを送ると、その中身がそのままサーバー上で実行されてしまいます。これは遠隔からの任意コード実行（RCE）と呼ばれ、サーバー乗っ取りに直結する、脆弱性の中でも最も重いタイプです。しかも攻撃にログインや会員登録は一切不要で、サイトを開ける相手なら誰でも狙えます。

攻撃を最初に発見したのは、ネット通販向けセキュリティを専門とするオランダの企業Sansec（サンセック）です。同社の調査では、Mirasvitの拡張機能を動かしているサイトは世界でおよそ6,000店舗あり、実際の数はそれ以上とみられています。先に紹介したPalo AltoのVPN製品の脆弱性と同じく、本件もすでに攻撃が始まっている「待ったなし」の案件です。

カゴの裏側で、客のカード番号が抜かれていくとき

この脆弱性は、すでに机上の話ではありません。修正版が出た直後から、Impervaは「PWNED_CVE2026」と書き込んだ試し攻撃や、わざとサーバーを5秒止めて反応を見る偵察を世界中で観測しています。つまり攻撃者はもう、踏める店を一軒ずつ探して回っている段階にいます。だからこそ、この穴に手を入れてくるのがどんな相手で、踏まれた店から何が出ていくのかを、生身の言葉で見ておく必要があります。

真っ先に群がるのは、通販サイトの会計ページに盗聴コードを仕込んでカード番号を吸い出すスキミング集団（いわゆるMagecart）、店のサーバーを暗号化して身代金を要求するランサムウェア集団、侵入できる店の入口だけを作って他の犯罪者に売り渡す初期アクセスブローカーです。彼らが欲しがるのは、買い物客が決済画面に打ち込んだクレジットカード番号と有効期限、氏名・住所・電話番号、注文履歴、会員のログインパスワード、そして店の管理画面そのものの操作権限です。細工したクッキーが一通そのサイトに届いた瞬間、攻撃者の書いたプログラムが店のサーバー上でそのまま走り出し、レジの裏側が丸ごと他人の手に渡ります。

乗っ取りは一度では終わりません。攻撃者はまず、サーバーに自由に出入りするための裏口プログラム（Webシェル）を設置して居座り、次に会計ページのプログラムをこっそり書き換えて、客が入力したカード情報を入力と同時に外部へ送る盗聴コードを埋め込みます。買い物客は普段どおり買い物を済ませたつもりでも、その裏で番号が抜かれ続けるのです。盗まれたカード情報や会員情報はダークウェブで売買され、そこで得た情報を使って別のサイトへのなりすまし侵入や不正利用が連鎖していきます。一軒の店の拡張機能の穴が、その店で買い物をしただけの何千人もの客を巻き込む入口になるのが、この種の乗っ取りの本当の怖さです。

そして請求書は、最後に店の運営者へ返ってきます。カード情報が漏れれば、カードブランドの安全基準（PCI DSS）違反による制裁金、個人情報保護委員会への報告と顧客への通知義務、問い合わせ対応、損害賠償、そして「あの店で買うとカードが危ない」という評判による客離れが、長く尾を引きます。CVSS 9.8という数字が示すのは技術的な深刻度の最大値にすぎず、店を預かる事業者にとっての本当の損失は、止まった売上と離れていった客の側にあります。いま自分の店がこの拡張機能を使っているかを確かめ、更新できるかどうかが、その分かれ目になります。

影響を受けるのはどんな店舗か

対象になるのは、Mirasvit Full Page Cache Warmerの1.11.12より前のバージョンを使っているMagento 2系の店舗です。やっかいなのは、この拡張機能を狙うのに特別な設定や管理者ログインが一切いらない点です。Sansecの説明を引くと、「細工したCacheWarmerクッキーを乗せた店頭ページへのリクエストはどれも、認証も管理者セッションも設定スイッチも必要とせずに、攻撃者が操れるデータのままPHPのunserialize()に届く」とされています。導入していれば、原則そのまま危険な状態にあると考えるのが安全です。

自分の店が該当するかは、下の早見表で確認できます。バージョンが1.11.12より前なら、最優先で更新が必要です。

「自分の店にどんな拡張機能が入っているか即答できない」というケースも珍しくありません。Magentoは数多くの外部部品（オープンソースのライブラリ）を取り込んで動いており、今回の攻撃もその部品群に含まれる仕掛けを悪用しています。どのソフトがどの部品を抱えているかをまとめて洗い出す考え方は、オープンソース部品の供給網を点検する仕組みの回でも整理しています。

技術的に何が起きているのか

中核にあるのは、PHPのunserialize()という関数の使い方です。この拡張機能は、キャッシュを温める処理のために、ブラウザ側に「CacheWarmer」という名前のクッキーを発行し、その中に状態をしまっておきます。問題は、店に戻ってきたそのクッキーの中身を、復元してよい部品の種類を制限せずにunserialize()でそのまま元の形に戻していた点にあります。クッキーの中身は利用者（＝攻撃者）が自由に書き換えられるため、悪意あるデータをそこに仕込めてしまいます。

CVE-2026-45247：クッキーから始まる「PHPオブジェクトインジェクション」

攻撃者が細工したデータをunserialize()に通すだけでは、まだプログラムの実行には至りません。そこで使われるのが「ガジェットチェーン」と呼ばれる手口です。これは、Magentoやその部品の中にもともと存在する正規のプログラム部品を、本来の用途とは違う順番でつなぎ合わせ、最終的にコマンド実行へと持ち込むテクニックです。Impervaの分析によれば、観測された攻撃では、ログ出力用の有名な部品「Monolog」に含まれるSyslogUdpHandlerやBufferHandlerなどが、この踏み台として悪用されていました。つまり、拡張機能自体に攻撃用のコードが入っているわけではなく、店のシステムにすでにある部品を組み合わせて乗っ取りが成立してしまうのです。

外から届いたデータを信用してそのまま処理してしまう、という根っこは、最近報じたSambaの認証なしコード実行や家庭用ネット監視ツールPi.Alertの乗っ取りとも共通しています。入口がクッキーか、ファイルか、設定値かが違うだけで、「信頼できない入力をそのまま実行可能な形に変えてしまう」という失敗の型は同じです。

すでに攻撃は始まっている

本件が他の脆弱性と違うのは、修正版が出た時点ですでに攻撃が観測されている点です。Sansecが発見してからCISAの「悪用が確認された脆弱性リスト」に載るまでの流れを、下の年表で追えます。

← スワイプで移動

Impervaの観測では、これまでに確認された攻撃の多くは「まず脆弱かどうかを確かめる」初期段階のものでした。攻撃者は本格的な侵入の前に、踏める店を選別している段階とみられます。だからこそ、攻撃が本番に切り替わる前の今が、更新の好機だといえます。なお、本件が登録されたCISA KEVの動向は日本語版ダッシュボードでも継続的に追っています。

自分の店が狙われていないか確かめる方法

更新と並行して、すでに攻撃を受けていないかも確認しておきたいところです。Sansecによれば、攻撃の手がかりはサーバーに届いた「CacheWarmer」クッキーの値に残ります。悪用のためのデータは多くの場合「base64」という符号化方式で運ばれ、その先頭が特定の文字列になるため、見分けがつきます。

具体的には、Sansecの指摘では、CacheWarmerクッキーの値が CacheWarmer:(Tz|Qz|YT) という形（Tz・Qz・YT のいずれかで始まる）になっていれば、攻撃の試みである可能性が高いとされています。Webサーバーのアクセスログを「CacheWarmer」で検索し、こうした不審な値が記録されていないかを点検してください。さらに、攻撃が成功している場合に備えて、身に覚えのないPHPファイルが公開ディレクトリに増えていないか、会計ページのプログラムが書き換えられていないかも確認するのが安全です。

今すぐやるべき対策

対策はシンプルで、Mirasvit Full Page Cache Warmerを修正版の1.11.12以降に更新することに尽きます。公式の変更履歴でも、このバージョンで「セッションクッキーのデシリアライゼーションにおけるPHPオブジェクトインジェクション」が修正されたと明記されています。攻撃に管理者ログインがいらない以上、「たぶん大丈夫」で先延ばしにするより、バージョンを上げて穴そのものを塞ぐのが一番速くて確実です。

すぐに更新できない事情がある場合は、その間の防御として、Webアプリケーションファイアウォール（WAF＝不正なリクエストをふるい分ける防御の壁）で先ほどの不審なCacheWarmerクッキーを遮断する、という当面の緩和策があります。ただしこれはあくまで時間稼ぎで、根本的には更新が必要です。更新後も、すでに侵入されていた可能性を考え、ログの保全と侵入痕跡の調査をあわせて行うことが推奨されています。Webアプリの権限まわりの脆弱性という意味では、WordPressプラグインWPCodeの任意コード実行と同じく、「サイトを支える追加部品が静かに穴を抱える」典型例といえます。

よくある質問

参照元

• ▸NVD - CVE-2026-45247 Detail
• ▸Sansec - Critical vulnerability in Mirasvit Cache Warmer for Magento
• ▸Imperva - Customers Protected Against CVE-2026-45247
• ▸Mirasvit - Full Page Cache Warmer 変更履歴（1.11.12）
• ▸VulnCheck - Mirasvit Cache Warmer for Magento PHP Object Injection
• ▸GitHub Advisory Database - GHSA-rg8p-9rpg-r32p
• ▸Cyber Security News - Critical Magento Cache Plugin Vulnerability
• ▸CISA - Known Exploited Vulnerabilities Catalog