3 पॉइंट द्वारा GN⁺ 2026-04-20 | 3 टिप्पणियां | WhatsApp पर शेयर करें
  • Vercel ने आधिकारिक रूप से पुष्टि की है कि उसके आंतरिक सिस्टम में अनधिकृत पहुंच से जुड़ी एक सुरक्षा घटना हुई है, और वह फिलहाल incident response विशेषज्ञों तथा law enforcement agencies के साथ मिलकर काम कर रहा है
  • इस उल्लंघन की वजह third-party AI tool Context.ai की Google Workspace OAuth app के compromise होने से Vercel कर्मचारियों के अकाउंट का takeover होना था
  • हमलावर ने गैर-संवेदनशील (non-sensitive) environment variables को enumerate करके अतिरिक्त access privileges हासिल किए, और ये variables बिना encryption के stored थे
  • खुद को ShinyHunters बताने वाले हैकर ने एक hacking forum पर access keys, source code, database data, API keys आदि बेचने का दावा किया है और 20 लाख डॉलर की फिरौती मांगी है
  • Vercel ने Next.js, Turbopack जैसे open source projects की सुरक्षा की पुष्टि की है, और ग्राहकों को environment variables की समीक्षा करने तथा sensitive variables feature को enable करने की सलाह दी है

सुरक्षा घटना का सार

  • Vercel JavaScript frameworks पर केंद्रित एक cloud hosting और deployment infrastructure platform है, जो Next.js की डेवलपर कंपनी भी है और serverless functions, edge computing, CI/CD pipelines services प्रदान करती है
  • एक security notice के जरिए कंपनी ने आधिकारिक रूप से पुष्टि की कि उसके आंतरिक सिस्टम में अनधिकृत पहुंच (unauthorized access) हुई
  • कंपनी ने कहा कि कुछ सीमित ग्राहक प्रभावित हुए, लेकिन service पर खुद कोई असर नहीं पड़ा
  • incident response विशेषज्ञों को नियुक्त किया गया है और law enforcement agencies को सूचित कर जांच जारी है

उल्लंघन का रास्ता और तकनीकी विवरण

  • इस उल्लंघन का मूल कारण third-party AI platform Context.ai की Google Workspace OAuth app का compromise होना था
  • Vercel के CEO Guillermo Rauch ने X (पूर्व Twitter) पर अतिरिक्त जानकारी साझा की
    • हमलावर ने Context.ai breach के जरिए Vercel कर्मचारी के Google Workspace अकाउंट पर कब्जा किया
    • इसके बाद उस अकाउंट से Vercel environment में access को escalate किया गया
  • हमलावर ने "गैर-संवेदनशील (non-sensitive)" के रूप में चिह्नित environment variables तक पहुंच बनाई; ये variables बिना encryption के stored थे (not encrypted at rest)
  • Vercel ने कहा कि वह सभी ग्राहक environment variables को पूरी तरह encrypted at rest स्टोर करता है और उसके पास multi-layered defense mechanisms हैं, लेकिन "non-sensitive" मार्क किए गए variables कमजोर कड़ी बन गए
  • Google Workspace administrators को नीचे दी गई OAuth app की जांच करने की सलाह दी गई है:
    • 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

हैकर का डेटा बिक्री दावा

  • ShinyHunters नाम का उपयोग करने वाले एक threat actor ने hacking forum पर Vercel breach और data sale से जुड़ी पोस्ट डाली
    • बिक्री के लिए बताए गए डेटा: access keys, source code, database data, internal deployment access, API keys (NPM tokens, GitHub tokens सहित)
    • उसने Linear data को सबूत के रूप में पेश किया और कई employee accounts तक पहुंच होने का दावा किया
  • ShinyHunters group से जुड़े पुराने threat actors ने BleepingComputer से कहा कि उनका इस घटना से कोई संबंध नहीं है
  • हमलावर द्वारा साझा की गई text file में Vercel कर्मचारियों की 580 entries शामिल थीं, जिनमें नाम, Vercel email addresses, account status और activity timestamps थे
  • एक screenshot भी साझा किया गया, जो आंतरिक Vercel Enterprise dashboard जैसा दिखता है
  • BleepingComputer इस डेटा और screenshot की authenticity को स्वतंत्र रूप से verify नहीं कर सका
  • Telegram messages में threat actor ने दावा किया कि वह Vercel से संपर्क में है और 20 लाख डॉलर की ransom मांगी गई है

Vercel की प्रतिक्रिया और ग्राहकों के लिए सलाह

  • Next.js, Turbopack और अन्य open source projects सुरक्षित हैं, इसकी पुष्टि की गई
  • dashboard पर environment variables के लिए overview page और sensitive environment variables management के लिए बेहतर interface deploy किया गया
  • ग्राहकों के लिए सुझाए गए कदम:
    • environment variables की समीक्षा करें
    • sensitive environment variable feature enable करें ताकि उपयोग न होने पर encryption सुनिश्चित हो
    • आवश्यकता होने पर secret rotation करें

3 टिप्पणियां

 
GN⁺ 2026-04-20
Hacker News की राय
  • अभी-अभी नोटिस अपडेट हुआ, और यह बात महत्वपूर्ण लगी कि उल्लंघन की शुरुआत third-party AI tool के Google Workspace OAuth app के compromise से हुई थी
    जांच में मदद के लिए IOC भी जारी किए गए, और admins से कहा गया कि वे तुरंत जांचें कि यह app इस्तेमाल हुआ था या नहीं
    OAuth App है 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com, और मूल विवरण Vercel security bulletin में देखा जा सकता है

    • Guillermo Rauch की व्याख्या के अनुसार, शुरुआत Vercel कर्मचारी द्वारा इस्तेमाल किए जा रहे Context.ai customer account के compromise से हुई, और उसके बाद Vercel Google Workspace account और environment तक chain access हुआ लगता है
      खास तौर पर यह बात ध्यान खींचने वाली थी कि non-sensitive environment variables की enumeration के जरिए आगे की access संभव हुई, और यह भी अनुमान आया कि हमलावर AI से काफी accelerate हुआ कोई sophisticated group हो सकता है
      इसके बावजूद अभी तक users के लिए email notice न होना काफी चिंताजनक लगा
    • लगा कि सिर्फ OAuth client ID बताने के बजाय असली app name भी public करना चाहिए
      सामने वाले को तुरंत नाम लेकर target न करने की भावना समझ में आती है, लेकिन service name छिपाने से response ही धीमा पड़ता है ऐसा लगा
    • वैसे भी अंततः बात सामने आनी ही है, तो responsible app को सीधे नाम लेकर क्यों नहीं बताया जा रहा, यह समझ नहीं आया
    • ऐसा लगा कि वह app पहले ही delete किया जा चुका है
    • यह घटना पिछले 10 साल में web development जिस दिशा में गया है, उसका स्वाभाविक नतीजा लगी
      आजकल stable foundation पर build करने से ज्यादा कई third-party combinations जोड़ना बहुत सामान्य हो गया है, और उसी अनुपात में failure points भी बढ़ गए हैं
      आखिरकार security उतनी ही मजबूत होती है जितनी उसकी सबसे कमजोर कड़ी, यह बात फिर से सामने आई, और खासकर vibe-coded जैसे AI tools पर business टिकाना साफ़ risk लगा
      इससे खुद से यह सवाल उठने लगा कि क्या हमें इसी दिशा को आगे बढ़ाते रहना चाहिए, और complexity कितनी बढ़ने पर हम पीछे मुड़कर देखेंगे
  • Claude Code recommendation stack analysis को देखकर लगा कि Claude Code default में कुछ specific providers और frameworks recommend करके web को और ज्यादा एकरूप बना रहा है
    ऐसी diversity की कमी से किसी incident के समय blast radius और बड़ा हो जाता है ऐसा लगा

    • reddit पर दिखने वाले low-effort vibe-coded projects सच में बहुत बार Vercel पर deploy दिखे
      ऐसा लगा कि यह लगभग default choice बन चुका है
    • कुछ दिन पहले Claude Code से जबरन एक नया CRUD React app बनवाने की कोशिश की, तो उसने default में Node JS और NPM dependencies की बाढ़ लगा दी
      फिर जब साफ़ कहा कि Node के बिना चाहिए, तो उसने तुरंत Python backend के साथ फिर से बना दिया, और खुद बताया कि dependencies भी कम करने की दिशा में बदला है
      वैसे यह बस discard कर देने वाले output के लिए किया गया experiment था, vibe coding recommend करने के लिए नहीं
    • यह अच्छी बात है, लेकिन समस्या का मूल Claude खुद है, ऐसा नहीं लगा
      आखिरकार यह इस्तेमाल के तरीके की समस्या है, और developers को इस तरह बेहतर guide करना चाहिए कि Claude उनके behalf पर decisions न ले
      सलाह ली जा सकती है, लेकिन अंतिम रूप से किसी इंसान को critical review करना ही चाहिए, और उस लिहाज से यह किसी दूसरे teammate के साथ काम करने से बहुत अलग नहीं लगा
    • दिमाग से यह बात निकल ही नहीं रही कि AI औसत की ओर अभिसरण को बहुत तेज़ कर रहा है
      internet में पहले से ऐसी प्रवृत्ति थी, लेकिन इस बार उसका texture कुछ अलग लग रहा है
    • agents को scapegoat बनाने का मैं पूरी तरह विरोध नहीं कर रहा, लेकिन ऐसी समस्याएँ असल में इंसानों के बीच भी हमेशा से दिखती रही हैं, ऐसा लगा
  • पहले security incident response team में रह चुका हूँ, इसलिए इस response team पर क्या बीत रही होगी, इसका अंदाज़ा है
    फिर भी पहला notice सचमुच बेहद खराब communication जैसा लगा
    क्या हुआ यह बताए बिना, बस इतना कहा गया कि मामला इतना गंभीर था कि law enforcement को inform किया गया, और customers के लिए action guidance बस "environment variables review करें" जैसी थी
    लेकिन customer के नज़रिए से उससे क्या करना है, यह बहुत अस्पष्ट था। क्या values अभी भी मौजूद हैं यह देखना है, या पहले से leak हुईं या नहीं यह कैसे तय करना है, कुछ समझ नहीं आता था
    मेरे हिसाब से तुरंत passwords, access tokens, और Vercel को सौंपे गए सभी sensitive data को rotate करने को कहना चाहिए था, और उसके बाद access logs तथा customer data में anomalies का audit करने को कहना चाहिए था
    महंगे hosting खर्च का एक कारण यह उम्मीद भी होती है कि security और reliability को professional तरीके से manage किया जाएगा, लेकिन अभी शुरुआती uncertainty को देखते हुए भी यह जरूरत से ज्यादा जानबूझकर अस्पष्ट लगा

    • incident page देखने पर पता चला कि Vercel में sensitive mark किए गए environment variables ऐसे store होते हैं कि उन्हें पढ़ा नहीं जा सकता, और फिलहाल access का कोई evidence नहीं मिला
      लेकिन अगर API keys, tokens, DB credentials, signing keys जैसी secrets को sensitive mark नहीं किया गया था, तो उन्हें संभावित रूप से exposed मानकर प्राथमिकता से बदलने को कहा गया
      स्रोत incident page था, और मैंने यह पूर्वी समय के अनुसार शाम 4:22 बजे देखा
    • सच कहूँ तो समझ नहीं आया कि मैं यह बात पहले यहाँ क्यों पढ़ रहा हूँ
      एक साल से ज़्यादा समय से paying customer हूँ, और company email से पहले news aggregator से पता चलना बेतुका लगा
    • पिछले साल भी Vercel ने Next middleware vulnerability response को अकुशलता से संभाला था, इसलिए यह पूरी तरह नया नहीं लगा
      संबंधित संदर्भ HN thread और उस समय की प्रतिक्रिया में देखा जा सकता है
    • security वाकई मुश्किल है, और मुझे जिन vendors पर भरोसा है वे सिर्फ AWS, Google, और IBM हैं
      बाकी ज़्यादातर विकल्प मुसीबत को न्योता देने जैसे लगते हैं
    • महँगी कीमत देने की वजह सिर्फ security और reliability नहीं, बल्कि कुछ clicks में deploy हो जाने वाली सुविधा भी है
      लेकिन मैंने अब उस सुविधा पर निर्भर न रहने का फैसला कर लिया है, और Render से सब कुछ linode पर migrate कर दिया है
      पहले Render पर महीने के 50 डॉलर से ज्यादा देता था, अब 3–5 डॉलर के स्तर पर हूँ, इसलिए आगे ऐसे hosting providers का इस्तेमाल फिर करने का इरादा लगभग नहीं है
  • “Vercel ने यह नहीं बताया कि कौन-सा system breach हुआ” यह वाक्य देखकर, security expert न होते हुए भी यह रवैया काफी कठिन-से-स्वीकार्य लगा
    ऐसा भी लगा कि customers को impact समझाने से ज्यादा वे अपनी defense पर केंद्रित हैं

    • दूसरी ओर, यह भी लगा कि system name और specific बताने से हर बार जरूरी नहीं कि ज्यादा उपयोगी जानकारी मिले
      उदाहरण के लिए, यदि कहा जाए कि GitHub का कोई कम-ज्ञात subsystem X breach हुआ, तो वह शायद पहले से कही गई “कुछ customer environments compromise हुए” जैसी बात से व्यावहारिक रूप से ज्यादा मददगार न हो
  • notice में IOC जोड़े जाने के बाद दोबारा देखने पर, यह बात कि घटना की शुरुआत Google Workspace OAuth app के compromise से हुई, पूरे community के लिए स्पष्ट रूप से महत्वपूर्ण जानकारी लगी
    admins और account owners को तुरंत उस app identifier की जांच कर लेनी चाहिए, ऐसा लगा, और विस्तृत जानकारी Vercel notice में थी

    • बहुत जिज्ञासा थी कि वह OAuth app आखिर कौन-सा tool है
  • मैं MacBook Pro और Chrome 147.0.7727.56 environment पर हूँ, और page के ऊपर बाएँ Vercel logo पर click करते ही Chrome app तुरंत crash हो गया
    यह काफी दिलचस्प bug लगा

    • मैं Arch Linux पर हूँ, और Chrome 147.0.7727.101 में वही crash reproduce हुआ, जबकि Firefox 149.0.2 या Chromium 147.0.7727.101 में नहीं हुआ
      अभी सब लोग यह पढ़ रहे हैं कि शायद Vercel के साथ कुछ compromise हुआ है, और साथ में webpage crash भी reproduce कर रहे हैं—यह स्थिति अजीब तरह से मज़ेदार लगी
      बेशक यह भी लगा कि ऐसी सामूहिक reproduction activity का बिलकुल भी उल्टा असर न हो, ऐसा हो ही नहीं सकता
    • अफसोस, मेरी तरफ Windows 11 Pro के Chrome 147.0.7727.101 में crash reproduce नहीं हुआ
      वीडियो भी रिकॉर्ड किया, और uBlock Origin Lite इस्तेमाल कर रहा था तो लगा वही कारण होगा, लेकिन उसे बंद करने पर भी crash नहीं हुआ
      लगा कि अगर reproduce हो जाता तो थोड़ा मज़ेदार होता
    • 2021 के आसपास Linux पर GitHub dropdown menu खोलते ही पूरा system मर जाने वाला Chromium bug याद आ गया
      कुछ समय तक ऐसा था, फिर आखिरकार ठीक हो गया था
    • मैंने भी Windows 11 के Chrome में यही behavior देखा
      लेकिन URL से Vercel home एक बार सीधे खोलने के बाद logo दबाने पर फिर crash नहीं हुआ
    • मेरा setup MBP M4 Max और Chrome 146.0.7680.178 है, और crash नहीं हुआ
      लेकिन अब Finish update button दबाने का मन थोड़ा कम हो गया है
  • संबंधित जानकारी के लिए HN की दूसरी thread और कुछ X posts भी साथ देख रहा था
    Theo की पहली पोस्ट में इसे credible बताया गया था, और follow-up post में कहा गया कि sensitive mark किए गए env vars सुरक्षित हैं, जबकि जो mark नहीं थे उन्हें precaution के तौर पर बदल देना चाहिए
    एक दूसरी पोस्ट में कहा गया कि इस तरह का hack किसी भी host के साथ हो सकता है, और एक और उल्लेख में ShinyHunters connection की संभावना उठाई गई

    • अगर sensitive mark न किए गए values सच में sensitive नहीं हैं, तो उन्हें बदलने की जरूरत ही क्या है, ऐसा लगा
      और अगर वे ज़रूर बदलने लायक values हैं, तो क्या इसका मतलब यह नहीं कि वे मूलतः sensitive data ही थीं और उन्हें sensitive mark किया जाना चाहिए था?
    • यह Theo कौन है, जिसे इतने लोग बार-बार quote कर रहे हैं, यह जिज्ञासा हुई
      इस समय तक उसकी posts में बहुत ज्यादा ठोस substance दिख नहीं रहा था
  • ऐसी घटनाएँ फिर याद दिलाती हैं कि modern web ecosystem कितनी हद तक single points of failure पर केंद्रित है
    अब तक की disclosure अपेक्षाकृत transparent लगी, लेकिन fully managed PaaS पर पूरी तरह निर्भर रहने के फैसले की risk profile फिर से गिननी पड़ी

  • “कुछ सीमित customers” जैसी अभिव्यक्ति तकनीकी रूप से 99% पर भी लागू हो सकती है, इसलिए यह काफी अस्पष्ट wording लगी

  • यह शक भी हुआ कि कहीं असल में बहुत सारे customers प्रभावित तो नहीं हुए, और बस जिन बड़े customers का जाना मुश्किल है, उन्हीं को subset कहा जा रहा हो

    • यह सिर्फ अनुमान है, लेकिन “limited subset” जैसा वाक्यांश बहुत कम बार अच्छी खबर साबित हुआ है, ऐसा लगा
      आम तौर पर अगर सच में भरोसा दिलाना हो तो “users का 1% से कम” जैसी ठोस संख्या दी जाती है, लेकिन इस बार ऐसा नहीं हुआ
      इसलिए लगा कि या तो visibility अभी कम है, या फिर numbers पसंद नहीं आ रहे
      फिर भी response team कितनी मुश्किल में होगी, यह समझ में आता है, और उम्मीद है कि आगे वे ज्यादा खुले और transparent तरीके से communicate करेंगे
 
click 2026-04-20

यहाँ भी हिंदी अक्षर दिख रहे हैं। हाल के दिनों में openai, claude, google से अलग-अलग, कोरियाई output में हिंदी का मिल जाना काफ़ी बार हो रहा है; क्या कोरियाई dataset की labeling भारतीयों ने की होगी?
चीनी models में कोरियाई जवाबों में चीनी मिल जाने की वजह से मुझे वे पसंद नहीं थे, लेकिन हाल में frontier models बार-बार हिंदी मिला रहे हैं, इसलिए उल्टा चीनी models के प्रति मेरा प्रतिरोध कम हो गया है

 
slowandsnow 2026-04-20

जब भी Claude इस्तेमाल करते हैं, जापानी अक्सर आ जाती है। कल भी ऐसा हुआ था।