Magento/Adobe Commerceの未修正率62%でRCEが“現実化”：CVE-2025-54236が自動化攻撃で悪用加速中です

今日の深掘りポイント

• 重大度の高い未認証RCE（CVE-2025-54236）がAdobe Commerce/Magentoに影響し、攻撃は既に自動化フェーズに入っていると報じられています。未修正店舗は62%に達し、スキャンから侵入までが高速化している可能性が高いです。
• 侵入ベクトルは「悪意のあるセッション」×「REST APIのネストされたデシリアライズ欠陥」の組み合わせで、Webシェル設置やアカウント乗っ取りに直結する設計上の弱点を突かれている点が本質です。
• メトリクスでは「immediacy: 10」「probability: 9」「magnitude: 9」「credibility: 10」。運用現場では“パッチ先行・調査並行・セッション全面失効”の即応3点セットが必要です。
• セッションストレージがファイル型の環境はリスク増。セッションの取り扱い・シリアライズ設定・REST公開範囲など、アプリ層設定の見直しが被害抑制の分水嶺になります。
• 影響は顧客アカウント不正利用、個人情報/注文データ流出、決済フロー改ざん、Webシェル常駐化による長期支配など広範です。PCI DSS観点のインシデント化も想定して準備すべきです。

はじめに

CVE-2025-54236はAdobe CommerceおよびMagentoにおける未認証RCEで、REST API側のネストされたデシリアライズ脆弱性とセッション処理の組み合わせを突かれることで、サーバ側で任意コード実行に至ると報じられています。Adobeは9月に緊急パッチを提供済みですが、未修正環境が依然として62%と高水準にあり、すでに自動化攻撃キャンペーンが観測されている状況です。オンライン店舗は、対処の遅れが直接的な金銭被害とブランド毀損に跳ね返るフェーズに入っていると捉えるべきです。

本稿では、報じられている事実関係を整理し、現場で即応するための実務アクション、ならびにMITRE ATT&CKの観点からの脅威シナリオ評価を提示します。

参考情報（報道）: Active Exploits Target Magento & Adobe Commerce Platforms to Execute Remote Code

深掘り詳細

事実整理（報道ベース）

• 脆弱性: CVE-2025-54236（Adobe Commerce/MagentoのREST APIにおけるネストされたデシリアライズ欠陥に起因）です。
• 攻撃面: 悪意のあるセッション操作と組み合わせることで、未認証のままリモートコード実行と顧客アカウント乗っ取りが可能になると報じられています。特にファイルベースのセッションストレージ利用環境は高リスクとされています。
• 対応状況: Adobeは9月に緊急パッチを公開済みですが、62%の店舗が未修正のままで、自動化攻撃が進行中とされています。
• 情報公開: 一部報道では、パッチコードのGitHub上での露出が攻撃準備を加速させた可能性が示唆されています（一次情報の確認は別途必要です）。

出典: 前掲の報道リンク

インサイト（示唆と運用上の論点）

• 設計上の弱点が複合するタイプのRCEです。単一エンドポイントの入力検証不備にとどまらず、セッションの取り扱いとシリアライズの組み合わせが“実行”へ到達する導線になっている点が要注意です。セッションの保管形態（ファイル/DB/メモリ）とシリアライズ形式の選択が、実効リスクを大きく左右します。
• REST APIはヘッドレス構成や外部連携で広く公開されがちです。管理画面の防御（2FA/WAF/IP制限）だけでは不十分で、API側のスキーマ検証、メソッド制限、クライアント許可リストなど、API境界の制御を強化する必要があります。
• パッチ適用率が低いとされる背景には、EC運用の“止めづらさ”と“改修検証の重さ”が影響します。とはいえ未認証RCEは停止コストより被害コストが圧倒的に大きくなりやすく、可用性より安全側に倒す判断（緊急メンテナンス）が合理的です。
• メトリクスの解釈と運用示唆:
  • immediacy: 10（最優先・即日対応）。パッチ適用、RESTの一時的制限、全セッション失効を同時実施する価値が高いです。
  • probability: 9（悪用継続の蓋然性が非常に高い）。週末や夜間もスキャンが続く前提で監視強化が必要です。
  • magnitude: 9（影響度大）。PCI DSS/個人情報保護の報告義務が発生し得るレベルで、“完全侵害前提”で初動を設計すべきです。
  • actionability: 8（実施可能な対策が明確）。パッチ、公開制御、セッション無効化、鍵のローテーション、改ざん検知まで一気通貫で打てます。
  • credibility: 10（情報の信頼度が高いと評価）。現場は即応に躊躇すべきではないです。
  • score: 64.00（総合リスク量）。平時なら“高”に該当する水準で、経営レベルの関与を要請すべき領域です。
  • novelty: 8（新規性あり）。従来のMagento攻撃（管理画面狙い・カードスキミング）に加え、API経由の前段突破が主軸になる可能性が高く、監視パターンの刷新が必要です。

脅威シナリオと影響

• 想定シナリオA（未認証RCE→Webシェル常駐化）です。
  • 初期侵入でサーバ上にWebシェルを設置し、永続化と横展開、データ探索を実施します。注文・顧客テーブルのダンプ、APIキー/秘密鍵の窃取、ジョブ実行（cron）改変などに進む可能性が高いです。
• 想定シナリオB（アカウント乗っ取り→不正注文/ポイント・ギフト券搾取）です。
  • セッションやリセットフローの悪用で顧客アカウントを奪取し、クレデンシャル詐取なしでも不正取引に至る可能性があります。ブランド毀損のリスクが高いです。
• 想定シナリオC（コード注入→フロント改ざん）です。
  • 過去事例の延長として、フロントに不正スクリプトを注入して支払い情報を窃取する攻撃に移行する可能性があります（仮説）。CSP/SRI/整合性チェックでの早期検知が鍵です。
• 事業影響です。
  • 個人情報/取引情報の流出、在庫・価格の改ざん、決済ゲートウェイの不正操作、検索順位低下（改ざん/マルウェア検知）、インシデント公表・法的報告・罰金対応コストが累積します。特にカード情報関与が疑われる場合はPCI DSSインシデントとしての専門対応が必要です。

MITRE ATT&CK（参考マッピング）

• Initial Access: Exploit Public-Facing Application（T1190）です。
• Execution: Command and Scripting Interpreter（T1059、PHP/シェル等の汎用）です。
• Persistence/Defense Evasion: Web Shell（T1505.003）、Obfuscated/Compressed Files（T1027）です。
• Credential Access/Discovery: Application Layer DiscoveryやConfigファイル窃取（各種Discovery/T1552系）です。
• Exfiltration/C2: Exfiltration Over Web Protocol（T1041/T1071）です。
• Impact: Data Manipulation（T1565）やDefacement（T1491.002）です。

上記は一般化したTTPの当てはめであり、実環境ではログとアーティファクトに基づく検証が不可欠です。

セキュリティ担当者のアクション

即日（24–48時間）対応の優先順位です。

1. パッチ適用と露出低減です。

• 最新パッチを最優先で適用します。適用前にフルバックアップを取得し、適用後は整合性チェック（差分・ハッシュ・ファイル改ざん監視）を実施します。
• 一時的な緩和として、REST APIの公開範囲を最小化します。不要なエンドポイント無効化、メソッド制限、レート制限、既知悪性UA/IPの遮断を行います。可能なら許可リスト方式で外部連携先を限定します。
• セッションストレージがファイル型の環境は、短期的に権限/パーミッション/分離を強化し、中期的に別ストア（例: メモリ/DB）への移行を計画します。シリアライズ形式の見直し（PHPオブジェクト直列化の回避）も検討します。

2. 侵害前提の調査・狩りです。

• 直近2〜4週間のアクセスログからREST APIへの大量POST・異常サイズのリクエスト・短時間高頻度のエラー/500系を抽出します。
• Webルート/メディア配下/var配下に未知のPHP/スクリプト/タイムスタンプ不整合がないか確認します。cron、app/etc/env.php、composer autoload、.user.ini/.htaccess改変痕跡を点検します。
• 管理者アカウントの新規作成・権限変更・2FA設定変更・APIトークン発行履歴の突合を行います。外部への不審送信（大量の外向きHTTP/HTTPS、DNSトンネル兆候）も確認します。

3. 認証・鍵・セッションのリセットです。

• すべてのセッションを強制失効します。顧客・管理者双方のパスワードリセットを段階的に案内します。
• アプリシークレット、APIキー、決済連携トークン、Webhook署名鍵をローテーションします。SSO/IdP連携がある場合はトラストの再確立を行います。

4. 追加のハードニングです。

• WAF/WAAPでJSONスキーマ検証や危険なペイロードパターンのブロックを有効化し、誤検知と可用性のバランスを調整します。
• Egress制御でWebサーバからの外向き通信を最小化します。バックドアの外部C2確立やデータ持ち出しを抑止します。
• フロント改ざん対策としてCSP/SRI、ビルド生成物の整合性検査、CI/CDの署名検証を徹底します。

5. インシデント対応とコミュニケーションです。

• カード情報や個人情報にアクセスされ得る構成の場合、PCI DSSのIR手順に準拠して決済代行・関係当局と連携します。法的報告・顧客通知の要否を早期に法務と合意します。
• 再発防止として、脆弱性公表から適用までのSLO（例: 未認証RCEは72時間以内）を設定し、運用/開発/事業側で合意します。

6. 監視の更新です。

• REST API経由の攻撃検知ユースケースを新設します。失敗レスポンスのバースト、異常なユーザーエージェント、同一IPからの多機能エンドポイント叩き、レスポンス時間のスパイクなどの兆候を可視化します。
• 改ざん検知のためのファイル整合性監視（FIM）を高感度で運用し、変更イベントのチケット化/承認フローを仕組み化します。

参考情報

• 報道: Active Exploits Target Magento & Adobe Commerce Platforms to Execute Remote Code

注記

• 上記は報道ベースの情報に基づく分析で、一次情報（ベンダー公式アドバイザリやCVEデータベース）の確認と整合性チェックを推奨します。パッチ適用後も“侵害前提”で監査・鍵ローテーション・セッション失効を実施し、継続監視を強化すべきです。