StyleSmugglerゼロデイ：Magento／Adobe Commerce運営者が今すぐ確認すべきこと

StyleSmugglerは、Sansecが名称を付けた、Magento Open SourceおよびAdobe Commerceに影響すると報告された、悪用中のゼロデイです。報告によれば、未認証の攻撃者がストアサーバー上でリモートコード実行（RCE）に到達できる可能性があります。Sansecは、悪用を2026年9月4日に観測し、9月5日に公表しました。2223

これは、ベンダーの対応が完了した後の確定的な脆弱性情報ではなく、急速に状況が動く初期インシデント報告です。運営者が押さえるべき実務上の結論は明確です。開示前に最新パッチを適用していたとしても、インターネットに公開したMagento環境が安全だと決めつけないこと。攻撃面を縮小し、証跡を保全し、緩和策だけに頼る前に侵害の有無を確認してください。

初期開示時点で判明していたこと

Sansecは、最新版の2.4.9を含む現行バージョンが影響を受けるとし、クリーンなMagento Open Source 2.4.7、2.4.8、2.4.9で、未認証の攻撃チェーン全体を再現したと報告しました。22 また、2026年7月・8月のセキュリティ更新を適用済みの2.4.6-p15が被害を受けたとの報告もあり、既存パッチを最新化していても、この新規に開示された問題への対策にはなっていなかったことを示しています。32

9月6日に公開された報道時点では、AdobeはStyleSmuggler固有のCVE、セキュリティアドバイザリ、パッチ、回避策を公表していませんでした。23 Adobe Commerce as a Cloud Serviceでは9月8日の本番リリースが予定されていましたが、その予定だけではStyleSmugglerが修正対象に含まれることは確認できませんでした。8

これらの日付は初期開示期間の状況です。パッチ適用の判断前には、必ずAdobeの現行セキュリティ情報とリリースノートで、最新のベンダー見解を確認してください。

報告された攻撃チェーン

Sansecによると、攻撃者は認証不要のGraphQL入力にあるstylesプロパティを悪用し、既存の保護を回避して、Magentoのテンプレート関連処理に攻撃者制御下のPHPを注入します。攻撃は2段階で説明されています。第1段階で障害レポートなどMagentoが生成するコンテンツにコードを書き込み、第2段階で決済失敗メールのレンダリング処理を利用して、汚染されたコンテンツを実行させます。22

Payment Transaction Failed通知は、Commerceに標準搭載された設定可能なメール機能です。18 報告された攻撃で重要なのは、受信者がメールを開くかどうかではなく、サーバー側でテンプレートがレンダリングされる点です。インシデント対応ではこの違いが重要です。外部メールの配信に失敗していた、または受信者がメールを操作していない場合でも、不審な決済失敗イベントは調査対象になり得ます。

公開報道では、侵害後のペイロードとして、kworkerなどの名称でプロセスを偽装し、cronで永続化するLinuxバックドアが記述されています。2035 ただし、これらはハンティングの手掛かりにはなるものの、完全かつ恒久的なIOCリストではありません。攻撃者はファイル名、プロセス名、配置場所、ネットワーク基盤を変更できます。

独立に確立されていない主張

一部のインシデントインテリジェンス報告には、外向きのC2通信を観測せずにRedis上のセッションデータを窃取する、あるいはvar/log/system.logの汚染でvar/report/中心のハンティングを回避する、といった追加の主張があります。提供資料には、これらの挙動を裏付ける再現可能なマルウェア解析や、第二の独立したフォレンジック情報源は含まれていません。

したがって、これらは確定事実ではなく、未検証の脅威インテリジェンスとして扱うべきです。だからといって調査の必要性が下がるわけではありません。Magentoのレポートだけではなく、ホスト、プロセス、cron、Web、PHP-FPM、Redis、DNS、ファイアウォールのテレメトリーまで含め、幅広く証跡を収集してください。

直ちに優先する封じ込め策

1. 公開GraphQLを制限する

ストア運営に公開GraphQLが不要なら、/graphqlを一時的に無効化または遮断します。GraphQLが事業上不可欠な場合は、CDN、WAF、リバースプロキシで、必要なクライアント、運用元、クエリパターンだけにアクセスを限定してください。Sansecは、公式修正が利用できない間の即時対策として、GraphQLの無効化を案内しています。22

これは代替的な防御策であり、サーバーがクリーンである証明ではありません。侵害調査と並行して実施してください。

2. 緊急緩和策は慎重に導入する

Sansecは、同社のShieldルールが既知の攻撃2段階をともにブロックしたとしています。22 Disrexも、既知のチェーンを遮断する目的の緊急緩和パッチを公開したと述べています。ただし、こうしたパッチでは既存の感染を除去できないと警告しています。35

第三者製パッチやWAFルールは、コードレビューを行い、ステージング環境で検証し、変更管理の手順を通して導入してください。公式修正をテストし、該当する攻撃経路を閉じることを確認するまでは、暫定防御策を維持します。

3. クリーンアップ前に証跡を保全する

侵害の可能性がある場合、ファイルを削除したりサービスを再起動したりする前に、関連ログとホスト／プロセスのスナップショットを取得します。優先度が高い項目は次のとおりです。

• /graphqlへのWebサーバー・リバースプロキシのリクエスト。特にstylesを含む異常なPOST。
• PHP-FPM、アプリケーション、cron、実行アカウント、DNS、ファイアウォールのログ。
• 決済失敗メールの急増、または通常と異なるテンプレートレンダリング。
• 新規または変更されたcronジョブ。特にWebサービス用アカウントから実行されるコマンド。
• PHP-FPMの予期しない子プロセス、システムユーティリティを装う不審プロセス、書き込み可能または隠しパス内の未知の実行ファイル。
• Web／PHPランタイムのアカウントからのオープンソケットと外向き接続。

収集対象をvar/report/やMagentoアプリケーションログに限定してはいけません。意図的な改ざんがなくても、それらだけでは記録が不完全なことがあります。

侵害された場合の影響を小さくする

調査中も、次のハードニングは広く有効です。

• Web・PHPワーカーは専用の非特権アカウントで実行し、ファイルシステム権限を最小化する。
• 実行時アカウントに対してアプリケーションコードを読み取り専用にし、Commerceが実際に必要とする場所だけ書き込みを許可する。
• 運用互換性を確認したうえで、一時、キャッシュ、アップロード、メディア、ログ、レポート、生成済みディレクトリなど、書き込み可能な場所からの実行を防ぐ。
• 互換性テスト後に、一時領域や書き込みの多いファイルシステムでnoexec、nodev、nosuidマウントオプションを検討する。
• アプリケーションホストからの外向き通信を明示的な許可リストに絞り、想定外のDNSやUDPアクティビティを警告対象にする。
• Redisをインターネットに公開せず、プライベートネットワークと適切な認証・転送保護で守る。
• 新規cronエントリー、PHP-FPMから起動した予期しないプロセス、デプロイ成果物の変更を検知・警告する。

これらはアプリケーション修正の代替ではありませんが、永続化の余地を減らし、異常の発見を容易にします。

IOCが見つかった場合

陽性の指標を確認した場合は、サーバー全体が侵害された可能性があるものとして扱ってください。影響ホストを隔離し、フォレンジック証跡を保全したうえで、アプリケーション環境からアクセス可能だった認証情報をローテーションします。対象には、Magentoの管理者・統合認証情報、APIシークレット、データベース・Redis認証情報、デプロイ・SSHシークレット、決済事業者の認証情報が含まれます。環境に応じて顧客セッションも無効化します。

侵害が確認された場合、目に見えるバイナリだけを削除して同じホストを再稼働させるより、既知の正常なイメージまたは信頼できるバックアップから再構築する方が安全です。緩和パッチは再感染を防げても、既存のバックドア、認証情報窃取、永続化機構が取り除かれたことまでは保証できません。

実務上の要点

StyleSmugglerが示すのは、新たに開示され、すでに悪用されている攻撃チェーンは、既存のMagentoパッチレベルが最新でも通過し得るという点です。初期開示期間に取るべき最善の対応は、公開GraphQLを縮小または停止し、検証済みの暫定防御を導入し、アプリケーションとホスト両方のテレメトリーで侵害を捜索し、Adobeの公式修正が提供されたら速やかに適用・検証できる状態にしておくことでした。222335