StyleSmuggler 正遭利用：Magento 與 Adobe Commerce 商家的緊急應變指南

StyleSmuggler 是 Sansec 對一項據報正遭積極利用的零時差漏洞所使用的名稱，影響 Magento Open Source 與 Adobe Commerce。其風險極高：未經登入驗證的攻擊者，可能在商店伺服器上取得遠端程式碼執行（RCE）能力。Sansec 表示，攻擊自 2026 年 9 月 4 日開始，並於 9 月 5 日揭露此問題。2223

這仍是快速發展中的事件，而非已完成的原廠資安公告。對商家而言，重點很直接：**不要因為系統在漏洞揭露前已完全更新，就假設公開對外的 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 編號、安全公告、修補程式或因應指引。23Adobe Commerce as a Cloud Service 預計在 9 月 8 日推出正式環境版本，但該發布時程並不表示 StyleSmuggler 一定已被修正。8

上述日期僅反映初始揭露窗口的狀況。商家在安排修補前，應先查閱 Adobe 最新的安全公告與版本說明，以確認原廠目前的立場。

據報的攻擊鏈如何運作

依 Sansec 的說法，攻擊者會在未經驗證的 GraphQL 輸入中濫用 styles 屬性，繞過既有防護，並將攻擊者控制的 PHP 注入 Magento 的範本相關處理流程。此攻擊鏈分為兩個階段：第一步，程式碼被寫入 Magento 產生的內容，例如失敗報告；第二步，付款失敗電子郵件的範本轉譯流程會讓遭污染的內容被執行。22

**Payment Transaction Failed（付款交易失敗）**通知是 Commerce 既有且可設定的電子郵件功能。18在這條據報的攻擊鏈中，關鍵在於伺服器端的範本轉譯，而非收件者是否開啟郵件。對事件應變而言，這個差異很重要：即使外寄郵件沒有成功送達，或根本沒有收件者與郵件互動，可疑的付款失敗活動仍可能與攻擊有關。

公開報導形容攻擊成功後的酬載是一種具持久性的 Linux 後門，可能以 kworker 等名稱偽裝行程，並透過 cron 排程維持存活。2035這些資訊可作為威脅狩獵線索，但不能視為完整或永久有效的指標清單；攻擊者可以更改檔名、行程名稱、路徑與網路基礎設施。

尚未獲獨立證實的說法

部分事件情報報告提出更多主張，包括無須觀察到對外命令與控制連線即可竊取 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 規則可阻擋已知攻擊的兩個階段。22Disrex 也稱已發布用於攔截已知攻擊鏈的緊急緩解修補，但同時警告，這類修補不會移除既有感染。35

所有第三方修補程式或 WAF 規則，都應進行程式碼或設定審查、先於測試環境驗證，並透過受控的變更流程上線。在正式修補完成測試，且確認能封堵相關攻擊路徑前，應維持這些暫時防護。

3. 清理前先保全證據

若有任何遭入侵的可能，請先擷取相關日誌、主機與行程快照，再刪除檔案或重啟服務。應優先檢查：

• Web 伺服器與反向代理對 /graphql 的請求，尤其是涉及 styles 的異常 POST 活動。
• PHP-FPM、應用程式、cron、服務帳號、DNS 與防火牆日誌。
• 付款失敗通知突然增加，或異常的範本轉譯活動。
• 新增或遭修改的 cron 工作，特別是由 Web 服務帳號執行的命令。
• PHP-FPM 啟動的非預期子行程、偽裝成系統工具的可疑行程，以及可寫入或隱藏路徑中的陌生執行檔。
• Web 與 PHP 執行環境帳號建立的開放 socket 與對外連線。

不要只蒐集 var/report/ 或 Magento 應用程式日誌。即使沒有遭到刻意竄改，這些來源本來就可能不完整。

降低成功入侵後的損害

在事件調查期間，下列強化措施普遍有幫助：

• 以專用、非特權帳號執行 Web 與 PHP 工作程序，並將檔案系統權限降至最低。
• 讓執行期帳號無法寫入應用程式程式碼；只對 Commerce 確實需要的目錄開放寫入。
• 在相容的前提下，禁止從暫存、快取、上傳、媒體、日誌、報告與 generated 等可寫入目錄執行檔案。
• 經相容性測試後，考慮對暫存或高寫入量檔案系統採用 noexec、nodev 與 nosuid 掛載選項。
• 對應用程式主機的對外流量採明確允許清單，並針對非預期 DNS 或 UDP 活動告警。
• 不要讓 Redis 暴露於公網；應使用私有網路、合適的身分驗證與傳輸保護。
• 對新的 cron 項目、PHP-FPM 啟動的異常行程，以及部署成品的變動設定告警。

這些控制措施無法取代應用程式修補，但能降低持久化的空間，並提高異常活動的可見度。

一旦發現指標，應如何處理

只要出現正向指標，就應將其視為可能的完整伺服器遭入侵。請隔離受影響主機、保存鑑識證據，並輪替可能從應用程式環境取得的憑證，包括 Magento 管理員與整合憑證、API 密鑰、資料庫與 Redis 憑證、部署與 SSH 密鑰，以及金流服務商憑證；也應依環境需求使客戶工作階段失效。

若已確認發生外洩，從已知安全的映像檔或可信備份重建，比起只刪除看得到的二進位檔再讓原主機繼續服務更安全。緩解修補可以阻止再次感染，卻不能證明既有後門、憑證竊取或持久化機制已被清除。

實務重點

StyleSmuggler 的關鍵教訓是：一條新揭露、且正遭利用的攻擊鏈，可能繞過原本看似已更新至最新狀態的 Magento 環境。在初始揭露期間，最佳做法是縮減或移除公開 GraphQL 曝露面、部署經審核的暫時防護、從應用程式與主機遙測資料全面搜尋入侵跡象，並在 Adobe 正式修補推出後盡快套用與驗證。222335