At Black Hat USA 2026 นักวิจัยได้แสดงให้เห็นว่า Cascading Style Sheets (CSS) สามารถถูกนำมาใช้เป็นอาวุธเพื่อทำให้เอเจนต์อีเมลที่ขับเคลื่อนด้วย AI อ่านเนื้อหาที่มนุษย์มองไม่เห็นได้ เทคนิคนี้สามารถข้ามผ่านระบบป้องกันของ Outlook, Gmail, Yahoo และ Proton ทำให้เอเจนต์สามารถดึงข้อมูลรหัสผ่าน, โทเค็นการยืนยันตัวตน (authentication tokens) และที่อยู่ IP ออกไปได้

ทำไม CSS ถึงมีความสำคัญต่อความปลอดภัยของอีเมล

เป็นเวลาหลายปีที่ผู้ให้บริการเว็บเมลได้ป้องกัน HTML ที่เป็นอันตรายด้วยการลบสคริปต์ (stripping scripts), การทำ sandboxing สำหรับ iframe และการจำกัดความสามารถของข้อความ มาตรการเหล่านั้นสามารถหยุดยั้งการโจมตีแบบดั้งเดิมที่พึ่งพา JavaScript หรือวัตถุที่ฝังอยู่ (embedded objects) ได้ อย่างไรก็ตาม CSS มักถูกมองว่าเป็นเพียงโค้ดสำหรับการนำเสนอที่ไม่มีอันตรายมาโดยตลอด ตัวเลือกขั้นสูง (advanced selectors) เช่น attribute selectors, container queries และอื่นๆ ช่วยให้หน้าเว็บสามารถตอบสนองต่อโครงสร้าง DOM ได้โดยไม่ต้องใช้สคริปต์ใดๆ

การสาธิตในงาน Black Hat พิสูจน์ให้เห็นว่าตัวเลือกที่ "ไม่มีอันตราย" เหล่านั้นสามารถกลายเป็นช่องทางรอง (side-channel) สำหรับการรั่วไหลของข้อมูลได้ ด้วยการสร้างกฎสไตล์ (style rules) ที่จะทำงานก็ต่อเมื่อมีองค์ประกอบที่ซ่อนอยู่บางอย่างเท่านั้น ผู้โจมตีจึงสามารถทำให้ข้อความล่องหนสำหรับผู้ใช้ แต่ยังคงปรากฏอยู่ในหน้าเว็บที่ถูกเรนเดอร์ (rendered page) ซึ่งเอเจนต์ AI จะทำการประมวลผล

วิธีการโจมตีทำงานอย่างไร

หนึ่งในตัวอย่างการพิสูจน์แนวคิด (proof-of-concept) คือการส่งอีเมลที่ดูเหมือนปกติสำหรับผู้รับ แต่ภายในมีการซ่อนกฎ CSS ที่เปลี่ยนสีของข้อความเฉพาะส่วนให้ตรงกับสีพื้นหลัง ซึ่งเป็นการพรางข้อความนั้นอย่างมีประสิทธิภาพ มนุษย์จะไม่เห็นข้อความดังกล่าวเลย แต่เอเจนต์ AI ที่ดึงข้อมูลจาก DOM หรือ accessibility tree จะไม่ได้ใช้ตัวกรองทางสายตา (visual filter) เมื่อเอเจนต์ประมวลผลอีเมล มันจะอ่านข้อความที่ถูกพรางไว้และส่งข้อมูลนั้นผ่าน URL fragment ซึ่งเป็นส่วนหนึ่งของที่อยู่เว็บที่เบราว์เซอร์มักจะเพิกเฉยเมื่อโหลดหน้าเว็บ

อีกรูปแบบหนึ่งใช้การทำ indirect prompt injection โดยอีเมลมี Slack token ที่ถูกซ่อนไว้ CSS ทำให้โทเค็นนั้นมองไม่เห็นสำหรับผู้ใช้แต่ยังคงอยู่ใน markup เอเจนต์ AI ซึ่งถูกฝึกมาให้ปฏิบัติตามคำสั่งที่ฝังอยู่ในอีเมล จะตีความโทเค็นนั้นเป็นคำสั่งและส่งกลับไปยังเซิร์ฟเวอร์ของผู้โจมตี

การโจมตีทั้งสองรูปแบบประสบความสำเร็จกับผู้ให้บริการยอดนิยมกลุ่มเดียวกัน แสดงให้เห็นว่าช่องโหว่นี้เกิดจากวิธีการพื้นฐานที่ CSS ถูกเรนเดอร์ ไม่ใช่เกิดจากการปรับใช้ (implementation) ของแพลตฟอร์มใดแพลตฟอร์มหนึ่ง

เอเจนต์ AI ปะทะ ผู้อ่านที่เป็นมนุษย์

โดยสัญชาตญาณแล้ว มนุษย์จะเพิกเฉยต่อข้อความที่มองไม่เห็น เราเชื่อมั่นในเลย์เอาต์ทางสายตาที่จะบอกเราว่าอะไรสำคัญ ในทางตรงกันข้าม เอเจนต์ AI ทำงานบน DOM ดิบ หรือ accessibility tree ที่บันทึกทุกองค์ประกอบโดยไม่คำนึงถึงสถานะทางสายตา เมื่อ AI อ่านหน้าเว็บ มันไม่ได้ใช้กฎที่ว่า "ถ้าฉันมองไม่เห็น ฉันจะเพิกเฉย" ความไม่สอดคล้องกันนี้ทำให้เกิดจุดบอด: กระบวนการทำความสะอาดข้อมูล (sanitisation pipelines) ที่สร้างขึ้นเพื่อการบริโภคของมนุษย์ จึงไม่สามารถรับประกันความปลอดภัยสำหรับผู้อ่านที่เป็นระบบอัตโนมัติได้อีกต่อไป

ปัญหานี้ไม่ใช่ข้อบกพร่องใหม่ของ AI แต่เป็นข้อบกพร่องเก่าของเว็บ นั่นคือความสามารถของ CSS ในการส่งผลต่อเลย์เอาต์โดยไม่ต้องใช้โค้ด ซึ่งมาพบกับผู้บริโภคประเภทใหม่ บริการใดก็ตามที่ส่งต่อเนื้อหาอีเมลให้กับผู้ช่วย, ตัวสรุปความ หรือตัวจำแนกประเภทที่ขับเคลื่อนด้วย AI กำลังเผชิญกับความเสี่ยงที่ผู้ช่วยจะดำเนินการตามข้อมูลที่มนุษย์ไม่มีวันได้เห็น

ใครคือผู้รับผิดชอบในการป้องกัน?

การโจมตีเหล่านี้ทำให้เกิดคำถามเรื่องขอบเขตความรับผิดชอบ ผู้ให้บริการเว็บเมลได้ล้าง HTML เพื่อปกป้องผู้ใช้ที่เป็นมนุษย์อยู่แล้ว และเบราว์เซอร์ก็บังคับใช้กฎการเรนเดอร์แบบเดียวกัน แต่ไม่มีเลเยอร์ใดเลยที่คำนึงถึง AI ที่อยู่ปลายน้ำ (downstream AI) ซึ่งจะทำการประมวลผล markup เดียวกันนั้น บริการอีเมลควรเพิ่มการทำ CSS sanitisation ที่ลึกซึ้งยิ่งขึ้นหรือไม่? เบราว์เซอร์ควรเปิดใช้งาน flag ที่ระบุองค์ประกอบว่าเป็น "มองไม่เห็นสำหรับสคริปต์" หรือไม่? หรือผู้จำหน่าย AI จะต้องสร้างตัวกรองที่คัดทิ้งโหนดที่ซ่อนอยู่ก่อนการประมวลผล?

ทีมรักษาความปลอดภัยที่สร้างเครื่องมืออีเมลที่ขับเคลื่อนด้วย AI กำลังได้รับคำแนะนำให้ตรวจสอบกระบวนการเรนเดอร์ (rendering pipeline) ทั้งหมด ไม่ใช่แค่ HTML ที่ส่งถึงกล่องขาเข้า นั่นหมายถึงการตรวจสอบ DOM หลังจากที่ CSS ถูกนำมาใช้แล้ว, การตรวจสอบ accessibility tree และการลบหรือทำเครื่องหมายเนื้อหาใดๆ ที่ไม่สามารถมองเห็นได้ด้วยตาเปล่าของมนุษย์อย่างชัดเจน

สิ่งที่ต้องจับตามองต่อไป

  • การทดสอบโดยผู้จำหน่าย (Vendor testing) – คาดว่าผู้จำหน่าย AI จะรวมเวกเตอร์การโจมตีด้วย CSS ในโลกความเป็นจริงเข้าไว้ในชุดทดสอบของตน เว็บมีงานวิจัยด้านช่องโหว่มานานถึงสามสิบปี แต่เอเจนต์ AI เพิ่งจะมีเพียงไม่กี่ปีเท่านั้น

หากผู้ช่วย AI สามารถถูกหลอกให้รั่วไหลข้อมูลประจำตัวได้เพียงแค่การซ่อนข้อความด้วย CSS โมเดลความปลอดภัยที่ปกป้องกล่องขาเข้าในปัจจุบันก็ไม่เพียงพออีกต่อไป นักพัฒนา, ผู้ให้บริการ และหน่วยงานกำกับดูแลต้องปฏิบัติกับหน้าเว็บที่ถูกเรนเดอร์แล้ว—ไม่ใช่แค่ HTML ดิบ—ในฐานะขอบเขตความปลอดภัยสำหรับผู้บริโภคที่เป็นระบบอัตโนมัติ ปัญหาข้อความที่ถูกซ่อนเตือนให้เราระลึกว่า เทคโนโลยีที่ครั้งหนึ่งเคยถูกจำกัดไว้เพียงแค่ "การจัดรูปแบบ" สามารถกลายเป็นช่องทางในการขโมยข้อมูลได้ คลื่นลูกใหม่ของการป้องกันจะต้องยอมรับว่า CSS คือพื้นผิวการโจมตี (attack surface) ที่อาจเกิดขึ้นได้ ไม่ใช่เป็นเพียงเครื่องมือช่วยด้านการแสดงผลเท่านั้น