Vercel ने आपके सीक्रेट सादे पाठ में संग्रहित किए और उसे एक विशेषता कहा

Vercel से समझौता हुआ। पता लगने से पहले हमलावर लगभग दो महीने तक अंदर रहा। उसने ग्राहकों के एनवायरनमेंट वेरिएबल — API keys, डेटाबेस पासवर्ड, साइनिंग keys, टोकन — उन सभी प्रोजेक्ट के लिए खोजे और डिक्रिप्ट किए, जिन्होंने Vercel का वैकल्पिक "sensitive" फ़्लैग इस्तेमाल नहीं किया था।

हमले की श्रृंखला: Context.ai नामक एक तीसरे पक्ष का AI उपकरण समझौता कर लिया गया। हमलावर ने उस आधार का इस्तेमाल करके एक Vercel कर्मचारी के Google Workspace खाते पर कब्ज़ा कर लिया। वहां से वह Vercel के आंतरिक तंत्र में पहुंच गया। फिर उसने सीक्रेट पढ़ने शुरू किए।

कथित तौर पर यह डेटा अब BreachForums पर $20 लाख में बेचा जा रहा है।

वह "sensitive" चेकबॉक्स, जो डिफ़ॉल्ट नहीं था

असली बात यह है।

Vercel में दो प्रकार के एनवायरनमेंट वेरिएबल हैं। सामान्य, जो "encrypted at rest" होते हैं, लेकिन जिन्हें Vercel के तंत्र डिक्रिप्ट करके पढ़ सकते हैं। और "sensitive" वेरिएबल, जिनमें अतिरिक्त एन्क्रिप्शन होता है, जिसके बारे में Vercel का दावा है कि यह आंतरिक पहुंच को भी रोकता है।

हमलावर सभी सामान्य वेरिएबल पढ़ सकता था। केवल "sensitive" वेरिएबल सुरक्षित थे।

समस्या: "sensitive" वैकल्पिक था। डिफ़ॉल्ट नहीं। हर उस डेवलपर ने जिसने DATABASE_URL या STRIPE_SECRET_KEY या JWT_SIGNING_KEY बिना चेकबॉक्स चुने सेट किया — और ऐसे अधिकांश डेवलपर थे — उनके वे मान ऐसे रूप में पड़े थे, जिन्हें आंतरिक पहुंच वाला हमलावर डिक्रिप्ट कर सकता था।

उल्लंघन के बाद Vercel का मार्गदर्शन: "एन्क्रिप्टेड स्टोरेज के लिए sensitive environment variable सुविधा सक्षम करें।" इसका अर्थ: जो एन्क्रिप्शन आपको लगा था कि आपके सीक्रेट की रक्षा कर रहा है, वह वास्तव में उन्हें हमसे — या हमारे तंत्र में घुसने वाले किसी भी व्यक्ति से — सुरक्षित नहीं कर रहा था।

दो महीने का प्रवास-समय

प्रारंभिक समझौता फरवरी 2026 में हुआ। Vercel ने अपनी पहली सुरक्षा बुलेटिन 19 अप्रैल को प्रकाशित की। यानी लगभग दो महीने तक हमलावर की आंतरिक तंत्र तक पहुंच रही।

Vercel की अपनी सुरक्षा टीम ने हमलावर को "उनकी संचालन गति और Vercel के उत्पाद API सतह के गहन ज्ञान के आधार पर अत्यधिक परिष्कृत" बताया। जब वह कंपनी जो आपका बुनियादी ढांचा होस्ट करती है, कहे कि हमलावर ने उनके तंत्र को अपेक्षा से बेहतर समझा था, तो आपको ठिठक कर सोचना चाहिए।

उन दो महीनों में हमलावर के पास प्रभावित ग्राहक प्रोजेक्ट में उपलब्ध हर एनवायरनमेंट वेरिएबल खोजने का समय था। डेटा बाहर भेजने का समय था। बेचने का समय था।

OAuth आपूर्ति श्रृंखला

प्रवेश बिंदु Vercel का अपना कोड भी नहीं था। एक Vercel कर्मचारी ने Context.ai — एक AI उत्पादकता उपकरण — को Google OAuth के ज़रिए अधिकृत किया था। जब Context.ai समझौता हुआ, तो हमलावर को उस OAuth अनुमति द्वारा दी गई हर अनुमति विरासत में मिल गई।

यह एक ऐसा प्रतिरूप है जो बार-बार दोहराया जाता है। संगठन अपनी प्राथमिक प्रमाणीकरण को सावधानी से सुरक्षित करते हैं, फिर तीसरे पक्ष के उपकरणों को OAuth टोकन बांट देते हैं, जिनका अपना — अक्सर कमज़ोर — सुरक्षा तंत्र होता है। श्रृंखला में एक समझौता किया गया ऐप, और हमलावर आपके कर्मचारी की पहुंच विरासत में ले लेता है।

समझौता किए गए OAuth App ID को सार्वजनिक किया गया है: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com। यदि आपके संगठन ने इस ऐप को अधिकृत किया है, तो अभी उसे रद्द करें।

आपको क्या करना चाहिए

यदि आप Vercel पर तैनाती करते हैं:

• हर एनवायरनमेंट वेरिएबल को तुरंत बदलें — यह निर्धारित करने की प्रतीक्षा न करें कि आप "प्रभावित" थे या नहीं
• आगे से सभी एनवायरनमेंट वेरिएबल पर sensitive फ़्लैग सक्षम करें
• अपनी Google Workspace OAuth ऐप अनुमतियों का ऑडिट करें और जिसका आप सक्रिय रूप से उपयोग नहीं करते, उसे रद्द करें
• फरवरी-अप्रैल 2026 के दौरान अप्रत्याशित परिवर्तनों के लिए Vercel तैनाती लॉग की समीक्षा करें
• जो क्रेडेंशियल Vercel में संग्रहीत थे, उनका उपयोग करके अनधिकृत पहुंच के लिए डाउनस्ट्रीम सेवाओं (डेटाबेस, भुगतान प्रोसेसर, API) की जांच करें

असली सबक

Vercel के वास्तुकला ने ग्राहकों के सीक्रेट ऐसे रूप में संग्रहीत किए कि आंतरिक पहुंच उन्हें डिक्रिप्ट कर सकती थी। उन्होंने एक मज़बूत विकल्प दिया, लेकिन उसे डिफ़ॉल्ट नहीं बनाया। दो महीने तक किसी ने उस हमलावर को नोटिस नहीं किया, जो वे सीक्रेट पढ़ रहा था।

"हम पर भरोसा करें" वाली सुरक्षा की यही समस्या है। Vercel ने आपके एनवायरनमेंट वेरिएबल को रेस्ट पर एन्क्रिप्ट किया — तकनीकी रूप से सही। लेकिन डिक्रिप्शन keys उनके पास थीं। जब उनके तंत्र समझौता हुए, आपके सीक्रेट भी हुए।

विकल्प है शून्य-ज्ञान (zero-knowledge) वास्तुकला, जहां सेवा प्रदाता गणितीय रूप से आपका डेटा डिक्रिप्ट नहीं कर सकता। "नहीं करने का चुनाव करता" नहीं — कर ही नहीं सकता। कितना भी आंतरिक समझौता हो, कोई भी भ्रष्ट कर्मचारी हो, दो महीने तक आपके बुनियादी ढांचे में रहने वाला कोई भी परिष्कृत हमलावर हो — वह वह नहीं पढ़ सकता, जिसे डिक्रिप्ट करने की keys सर्वर के पास कभी थीं ही नहीं।

Vercel ग्राहकों से कह रहा है कि असली एन्क्रिप्शन अपनाने के लिए एक चेकबॉक्स चुनें। पूछने लायक सवाल: शुरू से यही एकमात्र विकल्प क्यों नहीं था?