PolyShell脆弱性がMagento/Adobe Commerceを直撃——認証不要のRCE
ECサイト構築プラットフォームMagento Open SourceおよびAdobe Commerceに、極めて深刻な脆弱性が発見された。「PolyShell」と名付けられたこの脆弱性は、REST API経由で認証なしに任意のコードを実行（RCE: Remote Code Execution）できるもので、CVSSスコアは最高レベルに近い9.8（Critical）と評価されている。2026年3月19日以降、50以上のIPアドレスから世界中のMagento/Adobe Commerceサイトに対する大規模なスキャンが確認されており、セキュリティ研究者は「既に実際の侵害が発生している可能性が高い」と警告している。影響を受けるサイトは世界で約30万サイトにのぼると推定される。
PolyShellとは何か——脆弱性の技術的詳細
PolyShellは、Magento/Adobe CommerceのREST APIにおけるデシリアライゼーション（逆シリアル化）処理の欠陥を悪用する脆弱性だ。
デシリアライゼーション脆弱性とは
シリアライゼーションとは、プログラム内のオブジェクト（データ構造）を保存や通信に適した形式（文字列やバイト列）に変換する処理のことだ。デシリアライゼーションはその逆で、文字列やバイト列からオブジェクトを復元する処理を指す。
問題は、信頼できないデータをデシリアライズした場合に発生する。攻撃者が悪意のあるデータ（ペイロード）を送信し、サーバー側がそれをそのままデシリアライズすると、ペイロードに含まれるコードがサーバー上で実行されてしまう。これが「デシリアライゼーション攻撃」であり、OWASPのTop 10脆弱性にも含まれる代表的な攻撃手法だ。
PolyShellの特徴
PolyShellが特に危険とされる理由は、以下の3点にある。
| 特徴 | 詳細 | 危険度 |
|---|---|---|
| 認証不要 | REST APIのパブリックエンドポイントを悪用するため、ログイン情報は不要 | 極めて高い |
| ポリグロットペイロード | PHP、Phar、シェルスクリプトなど複数の形式で動作する「多言語」ペイロード | 高い |
| WAF回避 | 一般的なWAFルールでは検知が困難な形式でペイロードをエンコード | 高い |
「PolyShell」という名称は、「Polyglot（多言語）」と「Shell（シェル、すなわちコマンド実行環境）」を組み合わせた造語だ。攻撃ペイロードが複数のプログラミング言語やファイル形式として同時に有効な構造を持つことに由来する。
具体的には、PolyShellのペイロードは以下の複数形式として解釈可能だ。
- PHPコード: Magentoのバックエンドで直接実行される
- Pharアーカイブ: PHPのアーカイブ形式としてデシリアライズされる
- シェルスクリプト: サーバーのOS上でコマンドとして実行される
この「多形態」の特徴により、単一のペイロードで複数の攻撃ベクトルを同時に試行できるため、防御側は対策が非常に困難になる。
攻撃の流れ
以下の図は、PolyShell攻撃がどのようにREST API経由で実行され、どのような被害をもたらすかの全体フローを示しています。
攻撃は以下のステップで進行する。
Step 1: 攻撃者がMagento/Adobe CommerceのREST APIパブリックエンドポイント（例: /rest/V1/guest-carts/ や /rest/V1/products）に対して、特別に細工したリクエストを送信する。認証トークンは不要だ。
Step 2: サーバーがリクエスト内のデータをデシリアライズする際に、PolyShellペイロードが展開・実行される。この段階でサーバーのPHPプロセスが攻撃者のコードを実行してしまう。
Step 3: 攻撃者はサーバー上で任意のコマンドを実行できる状態（RCE）になる。ここから以下の攻撃に展開する。
- Webシェル設置: サーバーにバックドアを設置し、いつでも再アクセスできるようにする
- 顧客データ窃取: データベースからクレジットカード情報、住所、メールアドレスなどを抽出
- スキマー注入: 決済ページにJavaScriptスキマーを注入し、今後の決済情報をリアルタイムで窃取
- ランサムウェア: サーバーのファイルを暗号化し、身代金を要求
攻撃の規模——50以上のIPから大規模スキャン
以下の図は、3月19日以降のスキャン検知数の推移と攻撃統計サマリーを示しています。日を追うごとにスキャン件数が急増していることがわかります。
セキュリティ企業Sansecの報告によると、2026年3月19日以降、以下の状況が確認されている。
| 指標 | 数値 | 備考 |
|---|---|---|
| 攻撃元IPアドレス | 50以上 | 世界各地に分散（VPN/Tor経由含む） |
| 1日あたりのスキャン件数 | 3月19日: 約50件 → 3月27日: 約500件以上 | 急増中 |
| 主な攻撃元地域 | 東欧、東南アジア、南米 | ボットネット利用の可能性 |
| 確認済み侵害サイト | 詳細は非公開 | 「少なくとも数十サイト」とSansec |
| スキャン対象エンドポイント | REST API全般 | 特に /rest/V1/guest-carts/ |
攻撃のタイムライン
| 日付 | 出来事 |
|---|---|
| 2026年3月上旬 | セキュリティ研究者がPolyShell脆弱性を発見、Adobeに非公開で報告 |
| 2026年3月19日 | 最初のスキャン活動を複数のハニーポットで検知 |
| 2026年3月21日 | 攻撃元IPが10→30以上に急増 |
| 2026年3月25日 | Adobeが緊急セキュリティパッチ（APSB26-18）をリリース |
| 2026年3月26日 | The Hacker News等でPolyShellの詳細が公開報道 |
| 2026年3月27日 | スキャン件数がさらに増加（パッチ未適用サイトを狙った攻撃が激化） |
影響を受けるバージョンとパッチ情報
影響を受けるバージョン
| 製品 | 影響を受けるバージョン | 修正バージョン |
|---|---|---|
| Adobe Commerce | 2.4.7-p4以前の全バージョン | 2.4.7-p5 |
| Adobe Commerce B2B | 1.4.2-p4以前の全バージョン | 1.4.2-p5 |
| Magento Open Source | 2.4.7-p4以前の全バージョン | 2.4.7-p5 |
パッチ適用方法
Adobeは2026年3月25日にセキュリティパッチAPSB26-18をリリースした。適用方法は以下の通りだ。
Composerを使用する場合（推奨）:
# パッチバージョンに更新
composer require magento/product-community-edition 2.4.7-p5 --no-update
composer update magento/product-community-edition
# データベースアップグレード
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento cache:flush
Adobe Commerce Cloudの場合:
Adobe Commerce Cloud環境では、Adobeが自動的にパッチを適用するが、反映までに最大48時間かかる場合がある。管理画面から手動でパッチ適用を確認・促進できる。
ECプラットフォームのセキュリティ比較
PolyShellのような脆弱性は、ECプラットフォームの選定基準にも影響を与える。主要なECプラットフォームのセキュリティ体制を比較してみよう。
| 比較項目 | Magento/Adobe Commerce | Shopify | WooCommerce | BigCommerce |
|---|---|---|---|---|
| ホスティング形態 | セルフホスト/Cloud | SaaS（フルマネージド） | セルフホスト | SaaS |
| セキュリティパッチ | 手動適用が必要 | 自動適用 | 手動適用が必要 | 自動適用 |
| WAF | 自前で構築/Cloud付属 | 標準搭載 | 自前で構築 | 標準搭載 |
| PCI DSS準拠 | 自社で対応 | Shopifyが対応 | 自社で対応 | BigCommerceが対応 |
| カスタマイズ性 | 極めて高い | 制限あり | 高い | 中程度 |
| 過去の重大脆弱性 | 多い（Magecart等） | 少ない | 中程度（プラグイン依存） | 少ない |
| 月額費用 | 無料〜$2,000+/月 | $39〜$2,000/月 | 無料〜（ホスティング別） | $39〜$399/月 |
| 日本語対応 | 対応 | 対応 | 対応 | 一部対応 |
Magento/Adobe Commerceの強みは圧倒的なカスタマイズ性だが、セキュリティの責任が運営者側にある点がリスクとなる。SaaS型のShopifyやBigCommerceは、セキュリティパッチの自動適用やWAFの標準搭載により、運営者のセキュリティ負担が大幅に軽減される。
なぜMagento/Adobe Commerceが狙われるのか
MagentoはECプラットフォームとして世界で約30万サイトに利用されている。攻撃者にとって魅力的なターゲットである理由は明確だ。
- 金銭的価値: ECサイトにはクレジットカード情報、個人情報、決済データが集中している
- セルフホスト型の脆弱性: パッチ適用がサイト運営者の判断に委ねられるため、適用が遅れるサイトが多い
- プラグインエコシステム: サードパーティプラグインが攻撃面を広げる
- Magecartの「成功体験」: 2018年以降のMagecart攻撃で攻撃者が大きな収益を得たことが、さらなる攻撃を誘引している
緊急対応ガイド——ECサイト運営者が今すぐやるべきこと
即座に実施すべきアクション
1. パッチ適用の確認と実行
最優先事項は、Adobe Commerce / Magento Open Sourceを**最新バージョン（2.4.7-p5）**に更新することだ。パッチ適用前にステージング環境でテストすることが理想だが、PolyShellの深刻度（CVSS 9.8）を考慮すると、テストを待たずに本番環境にもパッチを適用する判断も正当化される。
2. IOC（侵害指標）の確認
パッチ適用と並行して、既に侵害されていないかを確認する。以下のチェック項目を実施しよう。
# 不審なPHPファイルの検索（最近変更されたファイル）
find /var/www/html -name "*.php" -newer /var/www/html/index.php -mtime -14
# Webシェルの兆候を検索
grep -r "eval(" /var/www/html/pub/ --include="*.php"
grep -r "base64_decode" /var/www/html/pub/ --include="*.php"
grep -r "system(" /var/www/html/pub/ --include="*.php"
# REST APIアクセスログの確認
grep "rest/V1/guest-carts" /var/log/nginx/access.log | grep -v "GET"
# 不審なcronジョブの確認
crontab -l
ls -la /etc/cron.d/
3. WAFルールの追加
パッチ適用までの暫定対策として、WAF（Web Application Firewall）にルールを追加する。
# Cloudflare WAFの場合（カスタムルール例）
# REST APIへのPOST/PUTリクエストでデシリアライゼーション系のパターンをブロック
(http.request.uri.path contains "/rest/V1/" and http.request.method in {"POST" "PUT"} and http.request.body contains "O:") -> Block
4. データベースの整合性確認
管理者アカウントが不正に追加されていないか、決済設定が改ざんされていないかを確認する。
-- 最近作成された管理者アカウントの確認
SELECT * FROM admin_user WHERE created > DATE_SUB(NOW(), INTERVAL 14 DAY);
-- 決済設定の変更履歴を確認
SELECT * FROM core_config_data WHERE path LIKE '%payment%' ORDER BY updated_at DESC LIMIT 20;
中長期的なセキュリティ対策
即座の対応が完了したら、以下の中長期的な対策も検討しよう。
セキュリティ監視サービスの導入: Sansec eComscan、MageReport、Sucuriなどの専門サービスが、Magentoサイト向けの継続的なセキュリティ監視を提供している。月額$50〜$200程度で導入可能だ。
強固な認証情報管理: 管理画面のパスワードはもちろん、APIキー、データベース認証情報、SSHキーなどすべての認証情報を1Passwordのようなパスワードマネージャーで一元管理し、定期的にローテーションすることが重要だ。特にPolyShellのような脆弱性で認証情報が漏洩した可能性がある場合は、全ての認証情報を即座にリセットすべきだ。
バックアップと復旧計画: 日次の自動バックアップを確実に取得し、復旧手順を定期的にテストする。侵害が発覚した場合に「いつの時点のバックアップに戻せば安全か」を迅速に判断できる体制を整えよう。
過去のMagento脆弱性との比較
Magento/Adobe Commerceは過去にも深刻な脆弱性が発見されている。PolyShellとの比較は以下の通りだ。
| 脆弱性名 | 発見年 | CVSSスコア | 攻撃手法 | 認証要否 | 影響規模 |
|---|---|---|---|---|---|
| PolyShell | 2026年 | 9.8 | REST APIデシリアライゼーション | 不要 | 約30万サイト |
| CosmicSting (CVE-2024-34102) | 2024年 | 9.8 | XXE + デシリアライゼーション | 不要 | 約25万サイト |
| Magecart | 2018年〜 | — | JavaScriptスキマー注入 | 脆弱性依存 | 数万サイト |
| Shoplift Bug (CVE-2015-1397) | 2015年 | 7.5 | SQLインジェクション | 不要 | 約10万サイト |
| Fwoosh (CVE-2022-24086) | 2022年 | 9.8 | テンプレートインジェクション | 不要 | 約20万サイト |
PolyShellは過去の脆弱性と同等かそれ以上の深刻度を持つ。特に「認証不要」「CVSS 9.8」「大規模スキャン活動が既に進行中」という3つの条件が揃っており、2024年のCosmicStingと並ぶ最悪レベルの脆弱性と言える。
日本のECサイトへの影響と対策
日本でのMagento利用状況
日本ではShopifyやEC-CUBEの利用が主流だが、大規模ECサイトや越境EC（クロスボーダーEC）ではAdobe Commerce/Magentoの採用例が少なくない。
| セグメント | 日本でのMagento利用例 | リスクレベル |
|---|---|---|
| 大規模BtoC EC | ファッション、家電系の大手EC | 高い |
| 越境EC | 日本から海外への販売サイト | 高い |
| BtoB EC | 製造業の受発注システム | 中程度 |
| マーケットプレイス | マルチベンダー型ECモール | 高い |
日本のMagento/Adobe Commerceサイトの正確な数は公開されていないが、業界推計では500〜1,000サイト程度とされている。小さな数字に見えるが、大規模サイトが多いため、1サイトあたりの被害額は甚大になりうる。
日本特有の注意点
個人情報保護法への対応: PolyShellを悪用して顧客の個人情報が漏洩した場合、改正個人情報保護法に基づき、個人情報保護委員会への報告と本人への通知が義務付けられる。漏洩が発覚してから速やかに（概ね3〜5日以内に速報）報告する必要があり、対応が遅れた場合は行政処分の対象となりうる。
クレジットカード情報の取り扱い: 日本のEC事業者はクレジットカード情報の非保持化が原則だが、PolyShellのようなRCE脆弱性があると、決済ページにJavaScriptスキマーを注入され、カード情報がリアルタイムで窃取される「フォームジャッキング」攻撃のリスクがある。非保持化していても安全ではない点に注意が必要だ。
決済代行会社への連絡: 侵害が疑われる場合は、契約している決済代行会社（GMOペイメントゲートウェイ、SBペイメントサービスなど）にも速やかに連絡し、取引の監視強化を依頼すべきだ。
EC-CUBEユーザーへの教訓
日本で広く使われているEC-CUBEも、過去にクロスサイトスクリプティング（XSS）やSQLインジェクションの脆弱性が発見されている。PolyShellはMagento固有の脆弱性だが、ECプラットフォーム全般に共通するセキュリティの教訓がある。
- セルフホスト型ECは、セキュリティの自己責任が伴う: パッチ適用、WAF設定、監視体制をサイト運営者自身が構築・維持する必要がある
- SaaS型ECへの移行も選択肢: セキュリティ運用のコスト・リスクが許容できない場合、Shopify等のSaaS型ECへの移行を検討する価値がある
- 多層防御が必須: WAF、IDS/IPS、定期的な脆弱性スキャン、アクセスログ監視を組み合わせた多層防御体制を構築する
攻撃者の動向——PolyShellの背後にいるのは誰か
2026年3月時点で、PolyShellの攻撃を実行しているグループの特定には至っていない。ただし、複数のセキュリティ企業の分析から以下の傾向が見えている。
攻撃元の分散性: 50以上のIPアドレスが確認されており、単一のグループではなく複数のグループが並行して攻撃している可能性が高い。脆弱性の詳細がダークウェブフォーラムで共有・売買されているとの情報もある。
Magecartグループとの関連: 過去にMagento向けのJavaScriptスキマー攻撃を行ってきた「Magecart」グループの手法との類似点が指摘されている。特に、侵害後に決済ページにスキマーを注入する手順が酷似している。
自動化ツールの存在: セキュリティ企業Recorded Futureは、PolyShellのエクスプロイトコードが自動化ツールとしてダークウェブで販売されていることを確認した。これにより、技術レベルの低い攻撃者でも簡単にPolyShellを悪用できる状態になっている。
まとめ——ECサイト運営者が今とるべきアクション
PolyShellは、Magento/Adobe Commerceを利用する全てのECサイトにとって緊急かつ深刻な脅威だ。認証不要でRCEが可能という点で、過去最悪レベルの脆弱性と言える。パッチが既に公開されているにもかかわらず、スキャン活動は日に日に激化しており、未対応のサイトは「いつ侵害されてもおかしくない」状況にある。
今すぐとるべき3つのアクション:
- Magento/Adobe Commerceユーザー: 最優先でセキュリティパッチAPSB26-18を適用し、2.4.7-p5にアップデートする。パッチ適用前にIOC（侵害指標）の確認も並行して実施し、既に侵害されていないかをチェックする
- 全てのECサイト運営者: 自社サイトのECプラットフォームのバージョンとセキュリティパッチの適用状況を棚卸しする。認証情報の管理には1Passwordのようなパスワードマネージャーを使い、全てのAPIキー・管理者パスワードを定期的にローテーションする体制を構築する
- EC事業の意思決定者: セルフホスト型ECのセキュリティ運用コストとリスクを再評価する。パッチ適用のリードタイムが長い場合や、セキュリティ専任チームがいない場合は、SaaS型EC（Shopify、BigCommerce等）への移行を真剣に検討する
ECサイトは攻撃者にとって最も金銭的な見返りが大きいターゲットの一つだ。PolyShellのような脆弱性は今後も繰り返し発見される。一時的な対策だけでなく、継続的なセキュリティ運用体制の構築が不可欠だ。
「セキュリティ」カテゴリの記事
- セキュリティ
Drift Protocolから$2.85億流出——Solana史上2番目のDeFiハッキング
- セキュリティ
FCC、外国製ルーターの新規輸入を禁止——Salt Typhoon攻撃が引き金に
- セキュリティ
DatabricksがAIエージェント型SIEM「Lakewatch」発表——セキュリティ運用コスト80%削減
- セキュリティ
FBI盗聴システムに重大サイバー侵害——中国ハッカーの影
- セキュリティ
Cisco DefenseClawが登場——AIエージェント時代のセキュリティをOSSで変える
- セキュリティ
Tenex.aiが$2.5億調達でユニコーンに——AIセキュリティの新星