Black Hat USA 2026 में, शोधकर्ताओं ने दिखाया कि Cascading Style Sheets (CSS) को हथियार बनाकर AI-संचालित ईमेल एजेंटों को ऐसा कंटेंट पढ़ने के लिए मजबूर किया जा सकता है जो मानव उपयोगकर्ताओं के लिए अदृश्य है। इस तकनीक ने Outlook, Gmail, Yahoo और Proton को बायपास कर दिया, जिससे एजेंट पासवर्ड, ऑथेंटिकेशन टोकन और IP एड्रेस चुरा सके।

ईमेल सुरक्षा में CSS क्यों महत्वपूर्ण है

वर्षों से वेबमेल प्रदाता दुर्भावनापूर्ण HTML से बचाव के लिए स्क्रिप्ट को हटाकर, iframes को सैंडबॉक्स करके और एक संदेश क्या कर सकता है इस पर सीमाएँ लगाकर सुरक्षा करते रहे हैं। वे उपाय उन क्लासिक हमलों को रोकते हैं जो JavaScript या एम्बेडेड ऑब्जेक्ट्स पर निर्भर करते हैं। हालाँकि, CSS को हमेशा एक हानिरहित प्रेजेंटेशन कोड माना गया है। इसके उन्नत सिलेक्टर्स—एट्रिब्यूट सिलेक्टर्स (attribute selectors), कंटेनर क्वेरीज़ (container queries) और इसी तरह के—बिना किसी स्क्रिप्टिंग के एक पेज को DOM संरचना के प्रति प्रतिक्रिया करने की अनुमति देते हैं।

Black Hat के डेमो ने साबित कर दिया कि वे "हानिरहित" सिलेक्टर्स डेटा लीक के लिए एक साइड-चैनल (side-channel) बन सकते हैं। कुछ छिपे हुए तत्वों के मौजूद होने पर ही लागू होने वाले स्टाइल रूल्स बनाकर, हमलावर टेक्स्ट को उपयोगकर्ता के लिए अदृश्य बना देते हैं, लेकिन वह रेंडर किए गए पेज में मौजूद रहता है जिसे एक AI एजेंट पार्स (parse) करता है।

ये हमले कैसे काम करते हैं

एक प्रूफ-ऑफ-कॉन्सेप्ट (proof-of-concept) ने एक ऐसा ईमेल भेजा जो प्राप्तकर्ता को सामान्य लगा। इसके अंदर छिपे हुए CSS रूल्स थे जिन्होंने विशिष्ट टेक्स्ट का रंग बदलकर बैकग्राउंड के समान कर दिया, जिससे वह प्रभावी रूप से छिप गया। एक इंसान उस टेक्स्ट को कभी नहीं देख पाता, लेकिन एक AI एजेंट जो DOM या एक्सेसिबिलिटी ट्री (accessibility tree) को निकालता है, वह विजुअल फ़िल्टर लागू नहीं करता है। जब एजेंट ने ईमेल को प्रोसेस किया, तो उसने छिपे हुए टेक्स्ट को पढ़ा और उसे एक URL फ्रैगमेंट (URL fragment) में ट्रांसमिट कर दिया—वेब एड्रेस का वह हिस्सा जिसे ब्राउज़र आमतौर पर पेज लोड करते समय अनदेखा कर देते हैं।

एक अन्य वेरिएंट ने इनडायरेक्ट प्रॉम्प्ट इंजेक्शन (indirect prompt injection) का उपयोग किया। ईमेल में एक छिपा हुआ Slack टोकन था। CSS ने टोकन को उपयोगकर्ता के लिए अदृश्य बना दिया लेकिन उसे मार्कअप में रखा। AI एजेंट, जिसे ईमेल में एम्बेडेड निर्देशों का पालन करने के लिए प्रशिक्षित किया गया था, ने टोकन को एक कमांड के रूप में समझा और इसे हमलावर के सर्वर पर वापस भेज दिया।

दोनों हमले लोकप्रिय प्रदाताओं के एक ही सेट के खिलाफ सफल रहे, जिससे पता चलता है कि यह भेद्यता (vulnerability) CSS के रेंडर होने के मौलिक तरीके से उत्पन्न होती है, न कि किसी एक प्लेटफॉर्म के कार्यान्वयन से।

AI एजेंट बनाम मानव पाठक

इंसान स्वाभाविक रूप से उस टेक्स्ट को अनदेखा कर देते हैं जिसे वे देख नहीं सकते; हम यह जानने के लिए विजुअल लेआउट पर भरोसा करते हैं कि क्या महत्वपूर्ण है। इसके विपरीत, AI एजेंट कच्चे DOM या एक्सेसिबिलिटी ट्री पर काम करते हैं जो विजुअल स्थिति की परवाह किए बिना हर तत्व को रिकॉर्ड करता है। जब एक AI किसी पेज को पढ़ता है, तो वह "यदि मैं इसे नहीं देख सकता, तो मैं इसे अनदेखा कर दूँगा" वाला नियम लागू नहीं करता है। यह विसंगति एक ब्लाइंड स्पॉट (blind spot) पैदा करती है: मानव उपभोग के लिए बनाई गई सैनिटाइजेशन पाइपलाइन (sanitisation pipelines) अब स्वचालित पाठकों के लिए सुरक्षा की गारंटी नहीं देती हैं।

समस्या कोई नई AI खामी नहीं है। यह एक पुरानी वेब खामी है—बिना कोड के लेआउट को प्रभावित करने की CSS की क्षमता—जो एक नए प्रकार के उपभोक्ता से मिल रही है। कोई भी सेवा जो ईमेल कंटेंट को AI-संचालित असिस्टेंट, समराइज़र या क्लासिफायर को सौंपती है, उसे अब इस जोखिम का सामना करना पड़ता है कि असिस्टेंट उस डेटा पर कार्य करेगा जिसे मानव कभी नहीं देख पाता।

रक्षा के लिए कौन जिम्मेदार है?

ये हमले एक क्षेत्राधिकार संबंधी प्रश्न (jurisdictional question) उठाते हैं। वेबमेल प्रदाता मानव उपयोगकर्ताओं की सुरक्षा के लिए पहले से ही HTML को साफ करते हैं; ब्राउज़र रेंडरिंग के लिए पहले से ही समान नियमों को लागू करते हैं। फिर भी, इनमें से कोई भी लेयर उस डाउनस्ट्रीम AI पर विचार नहीं करती है जो उसी मार्कअप को पार्स करेगा। क्या ईमेल सेवा को गहरा CSS सैनिटाइजेशन जोड़ना चाहिए? क्या ब्राउज़रों को एक ऐसा फ्लैग दिखाना चाहिए जो तत्वों को "स्क्रिप्ट के लिए अदृश्य" के रूप में चिह्नित करे? या क्या AI विक्रेताओं को ऐसे फ़िल्टर बनाने चाहिए जो प्रोसेसिंग से पहले छिपे हुए नोड्स को हटा दें?

AI-संचालित ईमेल टूल बनाने वाली सुरक्षा टीमों को केवल उस HTML का ऑडिट करने के लिए नहीं, बल्कि पूरी रेंडरिंग पाइपलाइन (rendering pipeline) का ऑडिट करने के लिए कहा जा रहा है जो इनबॉक्स तक पहुँचता है। इसका मतलब है कि CSS लागू होने के बाद DOM की जाँच करना, एक्सेसिबिलिटी ट्री का निरीक्षण करना, और स्पष्ट रूप से किसी भी ऐसी सामग्री को हटाना या फ्लैग करना जो मानव आँख को दिखाई नहीं देती है।

आगे क्या देखें

  • विक्रेता परीक्षण (Vendor testing) – AI विक्रेताओं से अपनी टेस्ट सूट्स में वास्तविक दुनिया के CSS अटैक वेक्टर्स को शामिल करने की उम्मीद है। वेब के पास तीस वर्षों का भेद्यता अनुसंधान है; AI एजेंटों के पास केवल कुछ ही वर्ष हैं।

यदि एक AI असिस्टेंट को केवल CSS के साथ टेक्स्ट छिपाकर क्रेडेंशियल्स लीक करने के लिए मूर्ख बनाया जा सकता है, तो आज के इनबॉक्स की रक्षा करने वाला सुरक्षा मॉडल अब पर्याप्त नहीं है। डेवलपर्स, प्रदाताओं और नियामकों को रेंडर किए गए पेज को—न कि केवल कच्चे HTML को—किसी भी स्वचालित उपभोक्ता के लिए सुरक्षा सीमा (security boundary) मानना चाहिए। छिपे हुए टेक्स्ट की समस्या हमें याद दिलाती है कि एक तकनीक जो कभी "सिर्फ स्टाइलिंग" तक सीमित थी, वह डेटा चोरी का माध्यम बन सकती है। रक्षा की अगली लहर को CSS को केवल एक विजुअल सहायता के रूप में नहीं, बल्कि एक संभावित अटैक सरफेस (attack surface) के रूप में पहचानना होगा।