StyleSmuggler Magento 零日漏洞遭利用：Adobe 修補推出前，商戶要即刻做乜

StyleSmuggler 是 Sansec 對一條據報正被利用的 Magento Open Source 及 Adobe Commerce 零日漏洞鏈所起的名稱。最嚴重之處是：攻擊者毋須登入，便可能在網店伺服器取得遠端程式碼執行（RCE）能力。Sansec 表示，攻擊在 2026 年 9 月 4 日已開始，並在 9 月 5 日公開披露。2223

呢個係快速發展中嘅事件通報，並唔等同廠商已完成嘅保安公告。對商戶而言，重點非常直接：唔好假設「披露前已打齊 patch」就足以保護對外開放嘅 Magento 網店。 應先收窄暴露面、保留證據，並檢查系統有冇失陷，再依賴任何緩解措施。

初步披露期內已知嘅情況

Sansec 指所有現行版本都受影響，包括 Magento Open Source 2.4.9；並已在乾淨安裝嘅 Magento Open Source 2.4.7、2.4.8 及 2.4.9 重現完整嘅未驗證攻擊鏈。22 另有報道指，一個受害者使用 2.4.6-p15，並已套用 2026 年 7 月及 8 月嘅保安更新；反映以往嘅更新狀態並未處理當時新披露嘅問題。32

截至 9 月 6 日嘅報道，Adobe 尚未就 StyleSmuggler 發出專屬 CVE、保安公告、修補程式或 workaround。23 Adobe Commerce as a Cloud Service 當時安排在 9 月 8 日發佈 Production 版本，但呢個排期唔代表一定包含 StyleSmuggler 修補。8

以上日期只反映最初披露期間嘅狀態。商戶作出 patch 決定前，應查閱 Adobe 最新保安公告及 release notes，以確認供應商最新立場。

據報嘅攻擊鏈：由 GraphQL 到伺服器執行

按 Sansec 說法，攻擊者利用毋須登入嘅 GraphQL 輸入內 styles 屬性，繞過現有防護，將攻擊者控制嘅 PHP 注入 Magento 同範本相關嘅處理流程。整條鏈分兩步：第一步，把程式碼寫進 Magento 產生嘅內容，例如失敗報告；第二步，透過付款失敗電郵嘅 rendering 流程，令已被污染嘅內容執行。22

Payment Transaction Failed 通知本身係 Commerce 可設定嘅正常電郵功能。18 呢次攻擊鏈嘅關鍵，係伺服器端進行範本 rendering，而唔係收件人打開電郵。對事故應變尤其重要：就算外寄郵件失敗、或者冇人讀過電郵，異常嘅付款失敗活動仍可能係有用線索。

公開報道指，攻擊成功後嘅 payload 屬持久化 Linux 後門，可能以 kworker 等名稱偽裝程序，並透過 cron 維持運作。2035 呢啲只應當作追查線索，唔係完整或永久有效嘅指標清單；攻擊者可以更改檔名、程序名、路徑及網絡基建。

有啲講法仍未獲獨立證實

部分事故情報報告提出更多說法，例如在無可見 command-and-control 流量下竊取 Redis 支援嘅 session 資料，或透過污染 var/log/system.log，避開只檢查 var/report/ 嘅排查方式。現有材料未有提供可重現嘅惡意程式分析，亦未見第二個獨立鑑證來源證實呢啲具體行為。

所以，呢類資訊應視為未經驗證嘅情報主張，而唔係既定事實。呢個不會降低調查必要性；相反，防守方唔應只睇 Magento 報告，亦要收集主機、程序、cron、web、PHP-FPM、Redis、DNS 及 firewall telemetry。

即時處置優先次序

1. 限制公開 GraphQL

如果網店唔需要公開 GraphQL 仍可正常運作，應暫時停用或封鎖 /graphql。如果 GraphQL 屬業務關鍵服務，就應在 CDN、WAF 或 reverse proxy 層面，只容許必要客戶端、操作及 query pattern 存取。Sansec 公開建議，在未有官方修補時，停用 GraphQL 係即時可做嘅非供應商控制措施。22

不過，呢個只係補償性控制，唔代表伺服器已經乾淨；必須配合入侵調查。

2. 審慎使用緊急緩解措施

Sansec 表示，其 Shield 規則可以封鎖已知攻擊嘅兩個階段。22 Disrex 亦表示已推出旨在阻擋已知攻擊鏈嘅緊急 mitigation patches，同時警告呢啲 patch 唔會移除既有感染。35

任何第三方 patch 或 WAF 規則，都應先進行審閱、在 staging 測試，並透過受控變更流程部署。直至官方修補已完成測試、確認封堵相關攻擊路徑之前，都應保留該等臨時控制。

3. 清理前先保留證據

如有失陷可能，刪檔或重啟服務前，先擷取相關日誌以及主機／程序快照。優先項目包括：

• 對 /graphql 嘅 web server 及 reverse-proxy 請求，尤其涉及 styles 嘅可疑 POST。
• PHP-FPM、應用程式、cron、程序帳戶、DNS 及 firewall 日誌。
• 付款失敗電郵數量突增，或者不尋常嘅範本 rendering 活動。
• 新增或被修改嘅 cron job，特別係由 web service 帳戶執行嘅指令。
• PHP-FPM 意外衍生嘅子程序、偽裝成系統工具嘅可疑程序，以及位於可寫或隱藏路徑嘅陌生可執行檔。
• Web 及 PHP runtime 帳戶開啟嘅 socket 與對外連線。

唔好只收集 var/report/ 或 Magento 應用程式日誌；即使冇人刻意竄改，呢啲來源都可能唔完整。

降低成功入侵後嘅影響範圍

調查期間，以下 hardening 措施普遍有用：

• Web 及 PHP worker 應使用專用、非特權帳戶執行，並只授予最低限度檔案系統權限。
• 令 runtime 帳戶對應用程式程式碼只有唯讀權限；只在 Commerce 真正需要嘅位置容許寫入。
• 在營運相容前提下，禁止從 temporary、cache、upload、media、log、report 及 generated 等可寫目錄執行程式。
• 經相容性測試後，可考慮對臨時或高寫入量檔案系統加上 noexec、nodev 及 nosuid mount option。
• 對應用主機嘅外連流量實施明確 allowlist，並就意外 DNS 或 UDP 活動告警。
• Redis 不應暴露於公網；應採用私有網絡，並設置合適嘅驗證及傳輸保護。
• 為新增 cron、PHP-FPM 啟動嘅異常程序，以及 deployment artifact 變更設置告警。

呢啲措施唔可以取代應用程式層面修補，但可以限制持久化能力，亦令異常活動更易被發現。

一旦發現指標，應點做？

如發現任何正面指標，應視作伺服器可能已全面失陷：隔離受影響主機、保留鑑證證據，並輪換所有可能在應用環境中可取得嘅憑證，包括 Magento 管理員及 integration 憑證、API secret、資料庫與 Redis 憑證、deployment 與 SSH secret，以及支付服務供應商憑證；亦應按環境需要令客戶 session 失效。

如已確認遭入侵，由已知可信映像或 backup 重建，通常比只刪除肉眼見到嘅 binary 後重新上線安全。緩解 patch 可以阻止再次感染，卻無法證明既有後門、憑證竊取或持久化機制已經完全清除。

重點結論

StyleSmuggler 最重要嘅教訓係：新披露、正被利用嘅攻擊鏈，可以繞過一個原本已維持最新 patch 水平嘅 Magento 部署。喺最初披露期間，最佳可行做法係減少甚至移除公開 GraphQL 暴露面、部署經審核嘅臨時防護、從應用與主機 telemetry 全面追查失陷跡象，並準備好在 Adobe 正式 remediation 推出後盡快測試、套用及驗證。222335