早前有研究發現新的攻擊方式，一封不含附件、不含 JavaScript 、只靠 HTML 與 CSS 排版碼的電郵，已經足以衝破訊息框的信任邊界，直接操控 Webmail 介面、即時側錄使用者輸入的密碼，並且透過提示注入指揮讀取電郵的 AI 代理外洩企業 Token。
PortSwigger 研究員 Gareth Heyes 於 2026 年 8 月 6 日發表研究報告「CSS: The Bomb Inside Your Inbox」，同期在 Black Hat USA 2026 公開示範，攻擊鏈覆蓋 Outlook 、 Gmail 、 Fastmail 、 Proton Mail 、 Yahoo Mail 與 AOL Mail 6 個主流平台。研究團隊同時把概念驗證程式碼放上公開 GitHub 倉庫，而部分廠商至報告發表當日仍未完成修補，企業的電郵防線因此出現一個長期被忽略的結構性缺口。
排版語言早已不只是排版
CSS 過去在保安圈子的地位相當邊緣，業界普遍假設排版碼無法影響訊息以外的頁面元素，Webmail 亦一直沿用這個假設去設計過濾器， Heyes 向 Dark Reading 形容，CSS 現時「幾乎已經是一種程式語言」，單靠 CSS 與 HTML 兩者，不需要任何指令碼，就可以砌出一個能夠運作的鍵盤側錄器。瀏覽器廠商持續為 CSS 與 HTML 加入新功能，攻擊面亦隨之擴張，而過濾器的設計思維卻停留在防範 JavaScript 的年代。
研究把突破手法歸納為 2 條路線，第 1 條是直接濫用 Webmail 本身「允許清單」內的合法 CSS 屬性與 HTML 元素；第 2 條則利用過濾器判斷與瀏覽器實際渲染結果之間的落差，也就是報告所稱的「CSS gadget」。 Outlook 的個案同時示範了兩者的組合效果：平台允許自訂 data 屬性通過，而其中一個前端函式庫會把該屬性重新寫入 DOM ，過程中帶入允許清單以外的 position: fixed ，攻擊者因此可以把元素定位到頁面任何位置，脫離電郵訊息窗框並改寫 Outlook 介面。
從假登入畫面到剪貼簿競態
Outlook 攻擊鏈的完成度最高，也最具威脅性，攻擊者利用合法的 label 元素觸發訊息框以外的控制項，再配合媒體查詢的解析技巧取得任意 CSS 控制權，最後把一個 select 下拉選單偽裝成密碼輸入框，並仿造 Microsoft 登入畫面。使用者每按一個鍵，都會觸發對應的 CSS 規則向攻擊者伺服器發出背景圖片請求； Firefox 在 select 元素移出畫面時會重設約 1 秒的選項比對計時器，令整個側錄過程接近即時。
Yahoo Mail 與 AOL Mail 則暴露另一條路徑，在 Firefox 環境下，貼上的 HTML 會在過濾器介入之前短暫保留有效樣式， Heyes 以 Medium 的電郵登入功能作示範，攻擊者先為受害者啟動登入流程，再誘使對方複製一段 CSS 並貼入草稿，隨後產生的請求已經足以讓攻擊者伺服器還原那組 12 個字元的 16 進位 Token，並以受害者身分登入。
報告另外提出一種針對 Content Security Policy 的繞道手法，當 CSP 封鎖所有外部資源請求，攻擊者仍然可以憑注入的樣式判斷電郵內純文字 Token 出現過哪些數字、各自出現多少次，再隱藏不符合條件的連結、把符合條件的連結鋪滿整頁，受害者一次點擊就把資料送到攻擊者手上。
AI 代理把電郵風險放大成企業事故
真正令風險升級的部分在於 AI 與電郵的整合， Gmail 的 image-set() 後備機制可以在過濾之後仍然發出外部請求， Heyes 與 PortSwigger 同事 Pete Hendy 把這個缺口串連到一封間接提示注入電郵，再交由連接了 Gmail connector 的 Anthropic Claude Cowork 處理。
示範情境中，攻擊者先觸發一封 Slack Token 確認電郵，受害者其後要求 Cowork 整理郵件，注入指令便驅使代理取出 Token 並寫入 HTML 草稿，草稿一經檢視，Token 即告外洩。針對 OpenAI 的 Atlas 瀏覽器，另一組示範利用 CSS 偽元素與透明度製造「人機所見不同」的效果，人類看到無害文字，模型讀到隱藏指令，使用者要求翻譯時，隱藏提示便驅使瀏覽器開啟分頁並把受害者姓名編碼入網址片段。
廠商反應參差， Fastmail 修補了 2 項 CSS 變異缺陷， Proton Mail 的代理繞過在重測時已經失效； Outlook 的 label 劫持與 Gmail 的 image-set() 繞過，在報告發表當日仍然有效，而 Outlook 完整密碼擷取鏈是否已修補，報告並無交代。 Dark Reading 引述 Heyes 指出，部分廠商回應迅速透明，另一部分先否定研究結果，事後才靜靜修補而不作說明。
企業應該怎樣拆解這道風險
對企業而言，這批攻擊鏈的實務意義在於推翻 2 個長年成立的假設，第 1 個假設是「沒有附件、沒有指令碼的電郵屬於低風險」，防毒引擎、沙箱與垃圾郵件過濾器大多圍繞可執行內容設計，純 CSS 攻擊可以完整繞過；第 2 個假設是「 AI 助理讀取郵件等同閱讀文字」，實際上代理同時繼承了使用者對 Gmail 、 Slack 等系統的存取權限，一封郵件的內容因此可以轉化為橫向移動的指令來源。
保安團隊短期內可以先從幾個方向收窄暴露面：在企業租戶層面關閉遠端圖片自動載入或強制經由自家圖片代理、把 AI 代理的連接器權限收窄至最低必要範圍、要求代理在跨系統取用機密資料前必須經人手確認，並且把「代理自動生成的草稿與外發內容」納入資料外洩監控範圍，至於平台層面的責任， Heyes 的建議相當明確：把 HTML 電郵隔離在 sandboxed iframe 內、以字元允許清單方式驗證 CSS 、在開放自訂屬性之前先檢查是否存在 CSS gadget 、封鎖 select 選單與 :has() 、 :checked 等高危選擇器，並且限制所有由攻擊者控制的圖片請求與允許網域。
電郵安全的下一個戰場
這批研究指向一個更根本的轉向：企業過去把電郵視為內容通道，如今電郵已經同時是渲染引擎的輸入、 AI 代理的指令來源，以及跨系統權限的觸發點，瀏覽器與 CSS 規格持續演進，攻擊面只會繼續擴大，而防守方對排版層的檢視能力明顯落後。 Heyes 相信 CSS 攻擊會成為下一個主要戰線，理由除了它能夠避開指令碼偵測，也因為業界至今投放的注意力太少。
企業採購 AI 電郵工具的節奏近年明顯加快，安全評估卻甚少涵蓋「模型讀到的內容與人眼看到的內容是否一致」這一層，這份研究把答案擺得很清楚：兩者可以完全不同，而差異正正就是攻擊者的操作空間。資訊保安總監在下一輪工具評估中，應該把提示注入抵抗力、連接器權限粒度與代理行為稽核紀錄，列為與傳統郵件閘道同等重要的採購條件。
