摘要： Cloudflare 在 2026 年 9 月 16 日說明 Page Shield ML 找出四個電商店面惡意行動，合計八個 payload。其中有七個在 VirusTotal 完全找不到，URLScan 也沒有判為惡意，顯示簽章式掃描難以察覺條件觸發的腳本。文章主張以執行時行為分析與持續監控補足第三方 JavaScript 的安全缺口。
頁面看起來正常，不代表沒有問題
一個電商店面可以載入飛快、品項擺得滿滿、結帳一路順到底，但底層的 JavaScript 卻在做店主從未點頭的事：把聯盟佣金吸走、綁架搜尋與點擊、動手改掉分析數據，或是向遠端伺服器請示下一步該做什麼。Cloudflare 在 2026 年 9 月 16 日發布的文章把這個盲點點得很明白：頁面健康與程式碼安全，該分開來看。
貼文追蹤的是四個仍在實際運作中的惡意行動、合計八個 payload，全數由 Page Shield ML 自動揪出，人類只負責在系統發出標記之後進場覆核。若改用一般安全掃描工具回頭查，八個 payload 裡有七個在 VirusTotal 上完全找不到，URLScan 也沒對其中任何一個給出惡意判定。整篇的張力就落在這個落差上：等到威脅情報資料庫願意替你貼標籤，時間早就來不及了。
為什麼簽章式防禦在這裡失效
這四個行動彼此之間沒有共用的簽章，藏匿手法也各走各的。Cloudflare 描述，其中一個要等裝置、國家、時間、referrer 或瀏覽器狀態全部對上才會醒過來；另一個把不需點擊的聯盟請求塞進看不見的 iframe；其餘變體則會攔截點擊、壓制監控，或在條件成立時才從遠端載入更多程式碼。
講得更直白一點，把頁面靜態掃過一遍是不夠的。這些腳本被設計成在正確的受害者出現之前維持安靜，所以真正需要的是持續的瀏覽器可視性，而不是單點式的檢查。
Cloudflare 的切入角度，是不把 JavaScript 當成一段平面文字，而是當成一張圖來推理。同一個 GNN 先前已抓出惡意 npm 套件與一個正在線上運作的 Magecart 付款側錄程式；它順著語法樹把程式符號串接起來，看清誰呼叫誰、攻擊者埋進了什麼、還有哪些連線仍在對外發聲。被 GNN 標為惡意的流量佔全部分析量不到 0.3%，這些案例會再送往 Workers AI 上的輕量 LLM 取得即時的第二意見，在壓低誤判的同時把召回率守住。
最複雜的腳本則交給一組前沿模型處理，Cloudflare 稱它們為 teachers，各自在獨立 session 中分析，需要時以受限的 JavaScript 評估器拆解片段。模型之間出現分歧時，Cloudflare 把它當成訊號而非雜訊，每個標記都依模型在 Artificial Analysis Intelligence Index 的分數加權投票，最後收斂成 benign、payment skimming、other malware、cryptomining 四類的機率分布。只有被標為惡意、或拿不到三分之二多數的腳本，才需要人工檢視。
四個行動各自偷走不同的東西
第一個行動鎖定行動裝置訪客：商品點擊被攔下之後，攻擊者預選的商品頁會在新分頁開啟，原分頁則繞經攻擊者的聯盟追蹤連結再折回商店，順手在背景種下歸因 cookie。結果是店家可能付出一筆不該付的佣金；但更棘手的是，真正把客人帶上門的合作夥伴被搶走歸因——信任一旦破裂，傷害會遠超過單筆佣金。這個行動的變體以 MutationObserver 監看動態生成商品磚與按鈕，並在 localStorage 寫入三天冷卻期；被擷取到的暫停版本甚至留著版本註解，記錄自己在 Black Friday 之後遭到暫停。
第二個行動連點擊都用不上。訪客打開訂房頁、翻看幾個選項、完全沒碰廣告，腳本卻可能已經把聯盟請求送了出去，讓之後的成交看起來像別人轉介的。Cloudflare 指出，程式碼證明了隱蔽的自動化聯盟請求確實存在，但某個具體請求是否真的完成歸因、入帳或付出佣金，則沒有被觀察到。這條界線值得產品團隊牢牢記住：能證明機制存在，不等於能證明損失金額。
供應鏈與 typosquatting 才是入口
第一個行動的投放路徑穿過兩個外觀平凡的 tag manager：Google Tag Manager → 另一個 tag manager → 惡意腳本。Cloudflare 特別聲明，這說的是 payload 抵達瀏覽器的方式，並不構成任一 tag manager 遭到入侵的證據。
更該留意的是網域偽裝。其中一個投放主機 adtargett[.]com 與 1998 年註冊的廣告網域 adtarget[.]com 只差一個 t，首頁還自稱 Performance Marketing Agency。靠著這類 typosquatting，它得以混跡在一堆例行行銷標籤之中，輕鬆通過快速的人工審查。
對產品與行銷團隊來說，實務上真正該做的下一步不是再買更多掃描器，而是承認第三方腳本本身就是一條持續變動的攻擊面。Cloudflare 的案例顯示，偵測能力必須跟著程式碼在執行時的行為走；對一般開發者而言，這也呼應我們先前談過的 Cloudflare 把混合用途爬蟲拆成三種行為 那類思路：先分清誰在做什麼，再決定要不要放行。
至於這套 ML 流程本身，Cloudflare 說回饋迴路仍有一部分得靠人工，自動化才正要起步。這是個誠實的限制，也提醒我們：自動偵測的準確度不是設定一次就結束，而是一套需要長期維護的系統。