セキュリティ14分で読める

Magecart型スキマーがMagentoの50%超を侵害——PolyShell攻撃の全貌

セキュリティサイバー攻撃
加木谷 直俊ソース記事を見る

ECサイトを狙うクレジットカード情報窃取攻撃「Magecart（メイジカート）」が、新たなエクスプロイト「PolyShell」を武器に猛威を振るっている。セキュリティ研究者の報告によれば、脆弱な状態のMagento/Adobe Commerceストアの50%以上がすでに侵害されており、世界中のEC事業者に深刻な被害をもたらしている。攻撃キャンペーンは2026年2月から急激に活発化し、3月時点で数千のオンラインストアが影響を受けたとみられる。

本記事では、PolyShellエクスプロイトの技術的な仕組み、Magecart型スキマーの攻撃フロー、そしてEC事業者が今すぐ実施すべき防御策を詳しく解説する。

Magecart攻撃とは何か

Magecartとは、ECサイトの決済ページにJavaScriptコードを不正に埋め込み、クレジットカード情報をリアルタイムで窃取する攻撃手法の総称だ。名称は、最初の主要な標的であったMagentoプラットフォームと、カート（ショッピングカート）を組み合わせた造語に由来する。

Magecart攻撃は2015年頃から確認されているが、年々手口が高度化している。初期は単純なJavaScriptの挿入だったが、現在では多段階の攻撃チェーンを構成し、検知回避のための難読化技術も格段に進歩している。

従来のMagecart攻撃との違い

今回のPolyShell攻撃が従来と大きく異なるのは、以下の3点だ。

  1. 多言語対応のWebシェル: PolyShellはPHP、Python、Perl、Bashなど複数の言語で動作するWebシェルであり、サーバー環境を問わず実行できる
  2. 自動化された大規模スキャン: 脆弱なMagentoインスタンスをインターネット上で自動探索し、発見から侵入まで数分で完了する
  3. 暗号化通信による検知回避: 窃取したカード情報をAES-256で暗号化した上で、正規のHTTPSトラフィックに偽装して外部に送信する

以下の図は、PolyShell攻撃の全体フローを示しています。

Magecart PolyShell攻撃フロー。脆弱性スキャンからPolyShell注入、スキマー埋込、情報窃取までの4段階と、被害状況・推奨対策の一覧

PolyShellエクスプロイトの技術解説

PolyShellは「ポリグロット（polyglot＝多言語）シェル」の略で、単一のファイルが複数のプログラミング言語のインタプリタで実行可能な構造を持つ。これにより、攻撃者はターゲットサーバーのスタック構成を事前に調査する必要がなく、1つのペイロードで幅広い環境を攻略できる。

攻撃の技術的プロセス

第1段階: 脆弱性スキャン

攻撃者はShodanやCensysなどのインターネットスキャンエンジンを活用し、インターネット上に公開されているMagentoインスタンスを列挙する。特に狙われるのは以下のバージョンだ。

  • Magento 2.4.6以前（セキュリティパッチ未適用）
  • Adobe Commerce 2.4.6-p4以前
  • Magento Open Source（コミュニティ版）の古いリリース

第2段階: PolyShellの注入

発見した脆弱なサーバーに対して、既知のRCE（リモートコード実行）脆弱性を悪用してPolyShellファイルをアップロードする。CVE-2024-34102（CosmicSting）やCVE-2024-2961（iconv脆弱性）のチェーンが主に利用されている。PolyShellファイルは.icoや.jpgなどの画像ファイルに偽装されることが多く、ファイル名だけでは不審なものと判別しにくい。

第3段階: スキマーの埋込

PolyShellを通じてサーバーへのフルアクセスを確立した攻撃者は、決済ページのテンプレートファイルにJavaScriptスキマーを注入する。スキマーコードは以下の特徴を持つ。

  • Base64とXORの二重エンコーディングによる難読化
  • DOMの変更を監視し、動的に生成されるフォームにも対応
  • カード番号、有効期限、CVV、カード名義人の全情報を取得
  • 入力されたデータをリアルタイムでキーストロークごとにキャプチャ

第4段階: データの外部送信

窃取したカード情報はAES-256で暗号化され、攻撃者が管理する外部サーバーに送信される。通信は正規のHTTPSトラフィックに偽装されており、一般的なネットワーク監視では検知が困難だ。送信先ドメインも正規のCDNやアナリティクスサービスに似た名前が使われる。

被害の規模と影響

セキュリティ企業Sansecの調査によれば、今回のキャンペーンの被害規模は以下のとおりだ。

指標数値
侵害されたストア数推定5,000〜7,000店舗
脆弱ストアの侵害率50%以上
影響を受けた国40カ国以上
攻撃キャンペーン開始時期2026年2月初旬
主な標的バージョンMagento 2.4.6以前
推定被害カード情報数数十万件
平均検知までの期間約14日間

特に深刻なのは、侵害を受けたストアの多くが攻撃発生から2週間以上気づいていないという点だ。スキマーコードは通常のサイト動作に一切影響を与えないため、売上やUXの異常からは検知できない。被害に気づくのは、カード会社からの不正利用通知や、セキュリティ研究者からの外部通報がきっかけとなることがほとんどだ。

ECプラットフォーム別のリスク比較

以下の図は、主要ECプラットフォームのセキュリティリスクを比較したものです。

EC決済プラットフォームのセキュリティ比較。自社構築型のMagentoが最もリスクが高く、SaaS型のShopify・BigCommerceは低リスク

プラットフォーム別セキュリティ詳細比較

プラットフォーム決済処理パッチ適用WAFFIMMagecartリスク
Magento (自社ホスト)サーバー上で処理手動別途導入別途導入極めて高い
Adobe Commerce CloudAdobe環境で処理半自動標準付属一部付属高い
WooCommerceプラグイン依存手動別途導入別途導入高い
ShopifyShopify決済基盤自動標準付属不要低い
BigCommerceSaaS決済基盤自動標準付属不要低い

自社ホスト型のMagentoが最もリスクが高いのは、セキュリティパッチの適用からWAFの運用まで、すべてが事業者の責任となるためだ。一方、ShopifyやBigCommerceなどのSaaS型プラットフォームは、決済処理がプラットフォーム側のインフラで行われるため、JavaScriptスキマーによる攻撃のリスクが構造的に低い。

EC事業者が今すぐ実施すべき対策

即座に実施すべきこと

  1. Magento/Adobe Commerceのバージョン確認: bin/magento --version コマンドで現在のバージョンを確認し、最新のセキュリティパッチが適用されているか検証する
  2. ファイル整合性チェック: 特に決済関連のテンプレートファイル（checkoutディレクトリ配下）に不審な変更がないか確認する
  3. 管理画面のアクセスログ確認: 不審なログインや管理APIへの異常なアクセスがないか調査する

中長期的な対策

  1. WAF（Web Application Firewall）の導入: Cloudflare、AWS WAF、Sucuriなどのサービスを導入し、不正なリクエストをブロックする
  2. CSP（Content Security Policy）の設定: script-srcディレクティブで許可するスクリプトのオリジンを限定し、不正なJavaScriptの実行を防止する
  3. SRI（Subresource Integrity）の活用: 外部スクリプトにハッシュ値を付与し、改ざんされたスクリプトの読み込みをブラウザレベルで阻止する
  4. PCI DSS準拠の定期スキャン: ASV（Approved Scanning Vendor）による四半期ごとの脆弱性スキャンを実施する

プラットフォーム移行の検討

決済処理のセキュリティ負担を根本的に軽減したい場合は、以下の選択肢がある。

  • Payment Service Provider（PSP）への移行: Stripe、PayPal、Square等のiframeベースの決済フォームを利用し、カード情報が自社サーバーを経由しない構成にする
  • SaaS型プラットフォームへの移行: Shopify Plus、BigCommerce Enterpriseなど、決済インフラがプラットフォーム側で管理されるサービスへの移行を検討する

日本のEC事業者への影響

日本国内のMagento利用状況

日本ではShopifyやBASE、STORESなどのSaaS型プラットフォームの普及が進んでいるものの、大規模ECサイトや高度なカスタマイズが必要なBtoB ECでは、依然としてMagento/Adobe Commerceが利用されている。特にグローバル展開している企業や、海外から日本市場に参入した企業においてMagentoの採用率が高い。

経済産業省の調査によれば、日本のBtoC EC市場は2025年に約24兆円に達しており、決済情報の窃取による被害の潜在的な規模は極めて大きい。

日本固有のリスク要因

  • セキュリティパッチの適用遅延: 日本語のリリースノートや技術ドキュメントが遅れがちで、英語の速報に追随できていないケースがある
  • 開発ベンダーへの依存: Magentoの運用を外部ベンダーに委託している場合、パッチ適用の判断・実行に時間がかかる
  • 改正割賦販売法への対応: 2025年の改正により、カード情報の非通過化（非保持化）が義務化されているが、対応が不十分な事業者も存在する

日本のEC事業者が取るべき追加対策

日本固有の規制環境を踏まえた追加対策として、以下を推奨する。

  • 日本クレジットカード協会（JCA）のガイドラインに準拠しているか再確認する
  • 不正検知サービス（Riskified、Forter、CAFIS等）の導入を検討する
  • カード情報の非通過型決済（トークン決済、リダイレクト型決済）への移行を加速する

過去のMagecart攻撃との比較

攻撃キャンペーン時期主な手法被害規模特徴
British Airways2018年サプライチェーン攻撃38万件のカード情報£2,000万の罰金
Ticketmaster2018年サードパーティスクリプト改ざん4万件以上チャットボットJS経由
Magento大量攻撃 (2020)2020年自動化ツール2,000店舗週末に集中攻撃
CosmicSting (2024)2024年CVE-2024-341024,275店舗XXE脆弱性悪用
PolyShell (2026)2026年多言語Webシェル5,000〜7,000店舗50%超の侵害率

PolyShell攻撃は、過去のMagecartキャンペーンと比較して、侵害率と攻撃の自動化レベルにおいて突出している。これは攻撃ツールの成熟と、未パッチのMagentoインスタンスが依然として多数存在することの両方を反映している。

まとめ——EC事業者が今すぐ取るべき3つのアクション

Magecart型スキマーの脅威は年々深刻化しており、PolyShellエクスプロイトの登場によって攻撃の効率と規模がさらに拡大した。EC事業者は以下のアクションを直ちに実行すべきだ。

  1. 緊急パッチ適用: Magento/Adobe Commerceを利用している場合、最新のセキュリティパッチを48時間以内に適用する。特にCVE-2024-34102とCVE-2024-2961への対応状況を優先確認する
  2. 決済ページの監査: 決済関連テンプレートファイルとJavaScriptの整合性を検証し、不審なコードがないか確認する。FIM（ファイル整合性監視）ツールの導入も検討する
  3. 構造的な防御強化: WAFとCSPの導入、PSPへの移行、PCI DSS準拠スキャンの実施など、中長期的なセキュリティアーキテクチャの見直しに着手する

EC事業者にとってクレジットカード情報の漏洩は、罰金や訴訟リスクだけでなく、ブランドへの致命的なダメージにつながる。「自分のサイトは大丈夫」という思い込みを捨て、今すぐ防御策を講じることが重要だ。

この記事をシェア

XはてブLinkedIn

「セキュリティ」カテゴリの記事

「セキュリティ」の記事をもっと見る

関連記事

新着記事