Tại Black Hat USA 2026, các nhà nghiên cứu đã chỉ ra rằng Cascading Style Sheets (CSS) có thể bị biến thành vũ khí để khiến các tác nhân email dựa trên AI đọc được nội dung mà người dùng không nhìn thấy. Kỹ thuật này đã vượt qua Outlook, Gmail, Yahoo và Proton, cho phép các tác nhân này đánh cắp mật khẩu, mã xác thực (authentication tokens) và địa chỉ IP.
Tại sao CSS lại quan trọng trong bảo mật email
Trong nhiều năm, các nhà cung cấp webmail đã phòng chống HTML độc hại bằng cách loại bỏ các tập lệnh (scripts), cô lập (sandboxing) các iframe và giới hạn những gì một tin nhắn có thể thực hiện. Những biện pháp đó ngăn chặn các cuộc tấn công cổ điển dựa trên JavaScript hoặc các đối tượng nhúng. Tuy nhiên, CSS luôn được coi là mã trình bày vô hại. Các bộ chọn nâng cao của nó—như bộ chọn thuộc tính (attribute selectors), truy vấn vùng chứa (container queries) và các loại tương tự—cho phép một trang web phản ứng với cấu trúc DOM mà không cần bất kỳ tập lệnh nào.
Các bản demo tại Black Hat đã chứng minh rằng những bộ chọn "vô hại" đó có thể trở thành một kênh phụ (side-channel) để rò rỉ dữ liệu. Bằng cách tạo ra các quy tắc định dạng (style rules) chỉ áp dụng khi các phần tử ẩn nhất định tồn tại, kẻ tấn công khiến văn bản trở nên vô hình đối với người dùng nhưng vẫn hiện diện trong trang đã được kết xuất (rendered page) mà một tác nhân AI phân tích.
Cách thức các cuộc tấn công hoạt động
Một bản thử nghiệm khái niệm (proof-of-concept) đã gửi một email trông có vẻ bình thường đối với người nhận. Bên trong được ẩn đi các quy tắc CSS làm thay đổi màu sắc của một đoạn văn bản cụ thể sao cho trùng với màu nền, giúp che giấu nó một cách hiệu quả. Con người không bao giờ nhìn thấy văn bản đó, nhưng một tác nhân AI khi trích xuất DOM hoặc cây khả năng truy cập (accessibility tree) sẽ không áp dụng bộ lọc hiển thị. Khi tác nhân xử lý email, nó đã đọc được văn bản bị che giấu và truyền nó đi trong một phân đoạn URL (URL fragment)—một phần của địa chỉ web mà các trình duyệt thường bỏ qua khi tải trang.
Một biến thể khác sử dụng kỹ thuật tiêm lệnh gián tiếp (indirect prompt injection). Email chứa một mã Slack token bị ẩn. CSS làm cho token này vô hình với người dùng nhưng vẫn giữ nó trong mã đánh dấu (markup). Tác nhân AI, vốn được huấn luyện để tuân theo các hướng dẫn được nhúng trong email, đã diễn giải token này như một câu lệnh và gửi nó về máy chủ của kẻ tấn công.
Cả hai cuộc tấn công đều thành công đối với cùng một nhóm các nhà cung cấp phổ biến, cho thấy lỗ hổng bắt nguồn từ cách thức cơ bản mà CSS được kết xuất, chứ không phải từ việc triển khai của một nền tảng duy nhất.
Tác nhân AI đối lập với người đọc là con người
Con người theo bản năng sẽ bỏ qua văn bản mà họ không thể nhìn thấy; chúng ta tin tưởng vào bố cục trực quan để biết điều gì là quan trọng. Ngược lại, các tác nhân AI hoạt động trên DOM thô hoặc cây khả năng truy cập, nơi ghi lại mọi phần tử bất kể trạng thái hiển thị. Khi một AI đọc một trang web, nó không áp dụng quy tắc "nếu tôi không thấy nó, tôi sẽ bỏ qua nó". Sự không tương thích này tạo ra một điểm mù: các quy trình làm sạch (sanitisation pipelines) được xây dựng để phục vụ con người không còn đảm bảo an toàn cho các trình đọc tự động.
Vấn đề không phải là một lỗi AI mới. Đó là một lỗi web cũ—khả năng của CSS trong việc ảnh hưởng đến bố cục mà không cần mã—gặp gỡ một loại người dùng mới. Bất kỳ dịch vụ nào chuyển giao nội dung email cho một trợ lý, trình tóm tắt hoặc trình phân loại chạy bằng AI hiện đang đối mặt với rủi ro rằng trợ lý đó sẽ hành động dựa trên dữ liệu mà con người không bao giờ nhìn thấy.
Ai chịu trách nhiệm phòng thủ?
Các cuộc tấn công này đặt ra một câu hỏi về thẩm quyền. Các nhà cung cấp webmail đã thực hiện làm sạch HTML để bảo vệ người dùng; các trình duyệt cũng đã thực thi các quy tắc kết xuất tương tự. Tuy nhiên, không có lớp nào trong số đó xem xét đến một AI ở hạ nguồn (downstream AI) sẽ phân tích cùng một mã đánh dấu đó. Liệu dịch vụ email có nên thêm các bước làm sạch CSS sâu hơn? Liệu các trình duyệt có nên hiển thị một cờ (flag) đánh dấu các phần tử là "vô hình đối với các tập lệnh"? Hay các nhà cung cấp AI phải xây dựng các bộ lọc để loại bỏ các nút (nodes) ẩn trước khi xử lý?
Các đội ngũ bảo mật đang xây dựng các công cụ email dựa trên AI được khuyến cáo nên kiểm tra toàn bộ quy trình kết xuất (rendering pipeline), chứ không chỉ là phần HTML truyền đến hộp thư đến. Điều đó có nghĩa là phải kiểm tra DOM sau khi CSS được áp dụng, kiểm tra cây khả năng truy cập, và loại bỏ hoặc đánh dấu rõ ràng bất kỳ nội dung nào không hiển thị được đối với mắt người.
Những điều cần theo dõi tiếp theo
- Thử nghiệm của nhà cung cấp – Các nhà cung cấp AI được kỳ vọng sẽ đưa các vectơ tấn công CSS trong thế giới thực vào bộ thử nghiệm của họ. Web đã có ba mươi năm nghiên cứu lỗ hổng; các tác nhân AI mới chỉ có vài năm.
Nếu một trợ lý AI có thể bị lừa để làm rò rỉ thông tin xác thực chỉ bằng cách ẩn văn bản bằng CSS, thì mô hình bảo mật bảo vệ hộp thư đến ngày nay sẽ không còn đủ khả năng. Các nhà phát triển, nhà cung cấp và các cơ quan quản lý phải coi trang web đã được kết xuất—chứ không chỉ là HTML thô—là ranh giới bảo mật cho bất kỳ trình tiêu thụ tự động nào. Vấn đề văn bản ẩn nhắc nhở chúng ta rằng một công nghệ từng chỉ được coi là "chỉ để định dạng" có thể trở thành con đường để đánh cắp dữ liệu. Làn sóng phòng thủ tiếp theo sẽ phải công nhận CSS là một bề mặt tấn công tiềm ẩn, chứ không chỉ là một công cụ hỗ trợ hiển thị.