荷蘭電商安全公司Sansec於9月5日發布公告指出，攻擊者正在利用Magento Open Source與Adobe Commerce中一個尚未修補的新漏洞，該漏洞允許攻擊者在未登入的情況下於線上商店伺服器執行惡意程式碼。

Sansec將此漏洞命名為StyleSmuggler，並表示攻擊自9月4日開始。該公司強調「由於商店正遭受入侵，故提前發布警告」。截至9月6日，Adobe尚未發布相關公告、CVE編號、修補程式或替代方案，Adobe Commerce的安全公告索引自8月11日更新後無新消息。

成功攻擊將使攻擊者能在商店伺服器上執行程式碼並安裝持久後門。Sansec表示所有現行版本均受影響，包括2.4.9，並在乾淨的Magento Open Source 2.4.7、2.4.8及2.4.9版本中重現完整的未經身份驗證攻擊鏈。

首個受害者使用2.4.6-p15版本，已套用Adobe於2026年7月及8月的安全更新，為該版本線的最新修補，Adobe 8月公告稱之為2.4.6-2026-aug。

Sansec尚未在Adobe Commerce或Adobe Commerce on Cloud上發布重現案例，Adobe也未確認受影響版本，且未透露受害商店數量。

研究人員暫時建議未使用Sansec Shield產品的商店暫時停用GraphQL，直到Adobe發布修補。

Magento主機及開發公司Disrex Group表示，無頭（headless）及漸進式網頁應用（PWA）商店前端需GraphQL，而大多數經典及Hyvä前端則不需。

Sansec表示Adobe預計於9月8日發布下一次安全更新，目前尚不清楚是否會涵蓋此漏洞。

Disrex獨立證實Sansec外的利用證據。該公司於9月5日發布事件回應資料庫，表示處理兩家受害商店及一家遭攻擊但未被入侵的商店，並基於其中一家受害商店的攻擊流量制定網頁伺服器規則。

Disrex回覆The Hacker News時表示，兩家商店均為Magento Open Source版本，非Adobe Commerce，且由其自有品牌RexHosting代管。

Disrex標記的商店A使用Magento Open Source 2.4.8，為Sansec Shield客戶，模組已安裝、啟用並授權。該商店於9月4日23:10 UTC遭攻擊，早於Sansec首批防禦規則上線數小時，當時Shield仍在運作並阻擋其他惡意流量。

商店B非Shield客戶，使用Magento 2.4.7-p2版本，Adobe版本歷史顯示該版本為2024年8月的安全修補，落後目前2.4.7-p10八個版本。該商店於9月5日00:55 UTC首次遭攻擊，Disrex表示其網頁伺服器規則及漏洞程式碼分析即來自此商店。

Disrex指出，兩家商店均在Sansec觀察到首次利用與防禦措施出現間約八小時的窗口期內被入侵。該公司強調「修補狀態在此事件中無關緊要，這是商家最需要知道的部分」。

Disrex資料庫附帶警告，指出該資料庫由AI協助、在事件發生時數小時內完成，尚未經審查，Apache規則未在實際伺服器測試，多數清理指令為撰寫而非執行。

Sansec指示植入程式為背景程序，偽裝成[kworker/u:8:0]，該名稱屬Linux核心執行緒，二進位檔安裝於網站用戶家目錄下的~/.local/share/.gvfsd/gvfsd-user，非網頁根目錄，並設有每五分鐘重啟的cron任務。

Disrex描述該二進位檔為約1.9 MB的剝離版、靜態連結Rust程式，支援x86-64與arm64架構，cron任務直接寫入/var/spool/cron/crontabs/的排程檔，系統日誌不會顯示crontab替換。

其中一家商店的cron任務重複同一行1,728次，且植入程式在被移除後一秒內會重新加入。

在兩家商店中，其中一家植入程式未建立任何外部連線，僅維持28個連線至本地Redis執行個體的6379埠，讀取Magento的會話儲存。Disrex表示，兩次超過200 MB的封包擷取均未發現任何發送至下載主機或Sansec列出的指揮控制地址的封包。

Disrex表示，每家商店運行於獨立帳戶，僅有單一網站擁有者，無sudo權限，且無法存取其他客戶，植入程式以非特權網站用戶身份執行，無法橫向移動，平台上無其他受影響網站。

兩家商店均於首次接觸後約11至14小時內被控制，未發現資料外洩、非法管理員帳號、支付竊取程式或資料庫後門。所有會話均被失效，並正進行憑證輪替作為預防措施。

Disrex表示，由於自家平台運行多個Magento商店，且迅速發現首起入侵，於一小時內掃描全平台並於當日下午找到第二家受害商店，並發布事件報告。

Sansec表示，對於在其規則生效前遭攻擊的Shield客戶，尚無跡象顯示後門被實際利用，建議在發現後門的地方更換Magento憑證。

Sansec說明攻擊分兩階段，首先在Magento自動寫入的檔案中植入PHP程式碼，例如生成錯誤報告時。接著透過觸發平台標準的「付款交易失敗提醒」郵件，使Magento執行該檔案。程式碼在渲染郵件時執行，無需開啟郵件，且即使郵件送達失敗攻擊仍可成功。

Sansec尚未公布完整攻擊鏈，表示將於後續更新中釋出攻擊鏈、投放器及植入程式的詳細分析。

Disrex對攻擊鏈的分析指出，注入文字中的指令驅動Magento自身類別序列，執行僅用於命令列依賴注入編譯器的程式碼，最終包含攻擊者選擇的檔案路徑，即先前被污染的日誌。執行的PHP投放器嘗試六種PHP函數啟動進程，然後下載並啟動植入程式。

Disrex指出攻擊鏈終點位於setup/src/Magento/Setup/Module/Di/Code/下的三個檔案，並表示透過閱讀受害商店的Magento原始碼自行識別該終點。Sansec尚未確認此分析，Disrex未公開組合請求。

攻擊標記已變化：Disrex於9月5日上午見到形式為X-TRACE-後接十個十六進位字元的觸發標頭，下午則見到無TRACE字樣的相同標頭，故搜尋應匹配格式而非精確字串。

Disrex表示，系統日誌中include後緊接的array_merge()函數因傳入整數參數產生TypeError，是攻擊成功的證據，但更隱蔽的變種會回傳空陣列且不留日誌。

Disrex說明，真正的核心執行緒由root擁有且無常駐記憶體，網站用戶下有記憶體使用的括號名稱即為植入程式。植入程式將命令列設為字面括號字串，故檢查comm欄位不會匹配到。

Disrex發現其中一家商店記憶體中執行的二進位檔與磁碟上不同，建議同時對/proc/<pid>/exe的執行檔與磁碟檔案進行雜湊比對。Sansec表示，異常大量的「付款交易失敗提醒」郵件是調查理由，儘管合法拒付也會產生相同通知。

Disrex的兩起入侵中，有一起即由該郵件揭露。Disrex共同創辦人Rick Bouma告訴The Hacker News，該商店寄給自身擁有者的失敗交易通知中，模板變數未解析，內容充滿原始{{var ...}}標籤，客戶地址為.invalid域名，總金額為零。

Bouma表示，該郵件看似錯誤訂單，但實為利用嘗試通過Magento模板過濾器的殘留訊息，商家轉寄該郵件後一小時內即展開調查並發現植入程式。

Disrex發布匿名化副本作為早期警告，指出Magento自身的「生成內容時發生錯誤」回退文字出現在地址區塊內，是第三個警示訊號，並稱該郵件為商家最有用的早期警告，因為發現它不需額外工具。

Sansec與Disrex均發布指標列表。

Sansec建議使用其eComscan掃描器檢測植入程式，並表示1.9.7版將為Shield客戶終止該程序。

Disrex於9月5日10:00 UTC在商店A執行eComscan，植入程式運行約11小時後掃描，報告商店清潔。Disrex解釋為掃描範圍問題，因掃描指向文件根目錄，而植入程式安裝於該目錄上一層的帳戶家目錄，已擴大掃描範圍並將另行確認eComscan版本。

目前無廠商修補可用。Adobe發布修補前，選項包括Sansec的暫時停用GraphQL、Disrex、ProxiBlue及Graycore發布的非官方緩解措施，以及兩個不依賴漏洞本身的伺服器設定。

Disrex發布nginx與Apache規則，阻擋URL查詢字串中帶有攻擊參數的請求。實測顯示限制有效，但POST或JSON主體中相同參數仍會送達PHP，因nginx與Apache僅檢查查詢字串。Disrex表示該規則阻止目前攻擊活動，但非漏洞本身。

Disrex主要緩解措施為在Magento依賴注入程式碼掃描器的三個方法中加入檢查，阻止其在非命令列環境執行。此手動修改會被composer install覆蓋，故Disrex提供composer-patches來源補丁，自動於部署時套用，適用於2.4.6至2.4.9版本。

三個檔案之一ClassesScanner.php被至少一個第三方模組mageplaza/module-admin-permissions透過HTTP呼叫，啟用防護會破壞該模組管理介面，Disrex建議管理員先搜尋供應商目錄再決定是否修改。

該防護在測試環境驗證，非實際商店，Disrex表示單獨使用並非完整修補。GitHub用戶ProxiBlue於9月5日獨立發布相同防護的三個非官方補丁。Bouma表示ProxiBlue（即Magento開發者Lucas van Staden）與Disrex獨立得出相同修護，使用相同的PHP_SAPI !== 'cli'檢查及例外訊息，Disrex版本為回應事件時撰寫。

Disrex已在其資料庫中重現ProxiBlue三個補丁並標明出處，提醒兩者為相同修補，切勿重複套用，認為雙方獨立達成相同修補是強力佐證。Sansec與Adobe尚未確認攻擊鏈終點是否在這些掃描器中。

Graycore, LLC於9月5日在GitHub與Packagist發布Magento模組，強化攻擊鏈三個環節：郵件模板區塊指令拒絕後端區塊、網格列URL產生器檢查類別、Web API致命錯誤報告中PHP開啟標籤被破壞。

Packagist上的版本為較早釋出，僅針對已移除的PayPal GraphQL解析器提供緩解。README說明「這是強化非修補」，警告漏洞其他路徑仍開放，且商店可能已被入侵。

Disrex表示兩個伺服器設定不依賴攻擊鏈細節。其一商店中，投放器嘗試的六個PHP函數中前四個被禁用，proc_open未禁用，投放器利用proc_open啟動植入程式，open_basedir無法限制子程序。

Disrex建議將proc_open加入PHP的disable_functions，並將/tmp、/var/tmp及/dev/shm掛載為noexec，防止下載的二進位檔執行，作為所有規則前的防護層。

已感染商店的清理指南為：先保留證據，移除cron任務再終止程序，因程序會自動復原cron；勿重啟系統，因/proc下的複本可能是唯一二進位檔；勿執行composer install，避免覆蓋時間戳。

接著建議清空會話儲存，因植入程式會讀取，並輪替app/etc/env.php中的crypt/key、所有管理員密碼、支付提供者API密鑰及其他整合憑證。

主機商Nexcess與Liquid Web於9月5日發布相同事件通知，表示正在檢視伺服器環境並實施預防措施。

兩者均未確認客戶受害或自行重現漏洞。Disrex從兩家商店的nginx存取日誌中去重後記錄26個不同來源IP，其中兩個為基礎設施批量發送，其他為住宅代理池，每個發送2至6次請求。Disrex表示，封鎖Sansec公告中的單一攻擊者IP僅能阻擋不到四分之一流量。早前計數為28，包含兩個Disrex自家伺服器驗證請求，已剔除。無來源指認攻擊者身份。

The Hacker News已聯繫Adobe、Sansec及Graycore求證，若有回應將更新報導。

（報導發表後更新，加入Disrex Group Rick Bouma回應，修正兩家受害商店版本、Shield狀態及首次接觸時間，解釋eComscan漏掃原因，描述揭露入侵的早期警告郵件，並確認ProxiBlue補丁與Disrex版本獨立產生。）

了解如何針對新CVE測試環境，確認攻擊者實際可利用的漏洞，並修補最具風險的曝露。

學習如何更快識別可利用風險，優先處理重要問題，並在AI驅動攻擊加劇威脅前降低曝露。