Vercel सुरक्षा जांच केंद्र

 (webmatrices.com)
1 पॉइंट द्वारा GN⁺ 2026-04-23 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • घटना की प्रकृति या प्रगति की पुष्टि करने के लिए कोई सार्थक मुख्य जानकारी उपलब्ध नहीं है
  • Hacker News के शीर्षक में संकेत दिया गया है कि Roblox cheat और एक AI टूल ने Vercel प्लेटफ़ॉर्म को प्रभावित किया
  • मूल शीर्षक Vercel Security Checkpoint के रूप में दिया गया है
  • विशिष्ट कारण, प्रभाव का दायरा और प्रतिक्रिया का तरीका मुख्य पाठ में आधार न होने के कारण सत्यापित नहीं किए जा सकते
  • उपलब्ध जानकारी भर के आधार पर घटना के महत्व या तकनीकी विवरणों का सारांश नहीं दिया जा सकता

कोई सामग्री नहीं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2026-04-23
Hacker News प्रतिक्रियाएँ

  • यह लेख बहुत ज़्यादा AI-जनित जैसा लगा। ऐसा भी लगा कि जानबूझकर थोड़ा अटपटा व्याकरण मिलाकर इसे छिपाने की कोशिश की गई, लेकिन इससे सामग्री की शुद्धता पर असर पड़ता है या नहीं, इस पर मैं निश्चित नहीं हूँ

    • मैं पढ़ते-पढ़ते बीच में ही रुक गया। अब मैं LLM वाली टोन के प्रति इतना संवेदनशील हो गया हूँ कि यह लगभग “ChatGPT, यह लेख पढ़ो और इसे casual अंदाज़ में फिर से लिख दो” स्तर का लगा, और इसमें असली लेखक की आवाज़ लगभग महसूस ही नहीं हुई। ऐसे लेखों के मामले में HN पर जहाँ तक संभव हो, प्राथमिक स्रोत लाना बेहतर है
    • समझ नहीं आता इसे downvote क्यों मिल रहा है। यह लेख AI blog spam के काफ़ी करीब है, और https://www.darkreading.com/application-security/vercel-employees-ai-tool-access-data-breach जैसे लेखों से ज़्यादा तथ्यात्मक जानकारी भी नहीं देता, बल्कि खाली-खाली LLM-स्टाइल अभिव्यक्तियों से भरा लगता है। लोग ऐसे लेख खुशी-खुशी पढ़ रहे हैं, यह थोड़ा उदास करने वाला है
    • मैंने देखा कि लेखक की साइट Vercel पर होस्टेड है। इसलिए लगा कि वह वास्तव में इस मुद्दे के दायरे में था और उसका इसमें हित भी जुड़ा हुआ है। सिर्फ़ इस वजह से भी यह पूरी तरह AI-जनित चीज़ से एक स्तर बेहतर लगता है
    • लेखन शैली साफ़ तौर पर LLM prose जैसी है, लेकिन पूरी तरह वैसी नहीं लगती। शायद कुछ हिस्से ही फिर से लिखे गए हैं। ज़्यादा चिंता की बात यह है कि HN जैसी जगह पर, जहाँ LLM से परिचित लोग बहुत हैं, वहाँ भी ऐसे लेख आराम से निकल जा रहे हैं। मैं नहीं चाहता कि यह मानक बन जाए, लेकिन AI-जनित लेखों को HN पर गंभीर प्रतिक्रियाएँ मिलना पहली बार भी नहीं है, यही बात और परेशान करती है। कोड में AI का उपयोग, अगर इंसान ठीक से verify करे, तो मुझे ठीक लगता है, लेकिन LLM prose का front page पर बढ़ते जाना सच में अच्छा नहीं लग रहा
    • मुझे भी बिल्कुल ऐसा ही लगा। आम लोग इस तरह नहीं लिखते

  • मेरे हिसाब से यहाँ “sensitive” की व्याख्या ग़लत है। मेरी जानकारी में Vercel के env var सेव करते समय सभी encrypted रहते हैं, और sensitive checkbox का मतलब यह है कि developer बाद में UI में उस value को दोबारा नहीं देख सकता। यानी यह write-only के क़रीब का concept है, और app को env var के ज़रिए value देखनी ही होती है, इसलिए app भी उसे न पढ़ सके इस तरह encrypt करना शुरू से ही निरर्थक होगा। अगर checkbox न लगाया जाए, तो project UI में value देखी जा सकती है, और DEFAULT_TIME_ZONE जैसी सामान्य config values के लिए यह ज़्यादा practical है। इसलिए मेरी समझ में sensitive का मतलब encryption नहीं बल्कि UI exposure है। मैं Vercel का कर्मचारी नहीं हूँ, पर थोड़ा इस्तेमाल किया है, और इस हिस्से की आलोचना मुझे strawman argument जैसी लगी

    • सही बात, मैं भी उस हिस्से पर उलझ गया था। जिन env var को program को सच में इस्तेमाल करना है, वे अंततः plaintext injection के रूप में ही जाएँगे। सेव करते समय encryption हो सकती है, लेकिन execution से पहले decryption करनी ही पड़ेगी, और यह Vercel की समस्या नहीं बल्कि सिस्टम architecture की सीमा है। कभी पूरी homomorphic encryption से सुधार हो सकता है, लेकिन पूरे program पर overhead इतना ज़्यादा है कि अभी यह व्यावहारिक नहीं है
    • अक्सर breach होते ही लोग चिल्लाते हैं, “इसे encrypt करना चाहिए था”, लेकिन वे encryption की सीमाएँ न सिद्धांत में समझते हैं न व्यवहार में। Encryption, secure या safe का पर्याय नहीं है
    • मुझे नहीं पता Vercel में यह ठीक-ठीक कैसे काम करता है, लेकिन दूसरे platforms में आम तौर पर इस तरह के label का मतलब logs में masking भी होता है
    • जहाँ मैं काम करता हूँ वहाँ हमने Vault इस्तेमाल करना शुरू किया है, और vault key lookup के लिए key को सामान्य non-hidden env var में रखते हैं। मुझे लगता है यह शायद ज़्यादा मज़बूत architecture है
    • दूसरे cloud platforms भी कुछ ऐसा ही करते हैं। उदाहरण के लिए DigitalOcean भी यही तरीका अपनाता है

  • मैं आसान scapegoat नहीं बनाना चाहता, लेकिन फिर भी यह सवाल तो उठता है कि Context.ai का कर्मचारी work device पर game खेल रहा था, और उस पर संदिग्ध source वाला cheat program भी इंस्टॉल कर लिया। defense in depth और layered security की बात बिल्कुल सही है, लेकिन यहाँ व्यक्तिगत ज़िम्मेदारी भी साफ़ दिखती है। Vercel की गलती को कंपनी और management स्तर की defense failure कहा जा सकता है, लेकिन cheat install करना अलग ही स्तर की गंभीर बात है

    • मेरी राय में AI अपनाने वाली कंपनियों में कुल मिलाकर OpSec स्तर कमज़ोर है। अभी security decision-making का core function नहीं है। 2 साल पहले वाले McDonalds breach को भी देखो, वही पैटर्न दिखता है
    • अभी यह पक्का नहीं है कि उस कर्मचारी ने सचमुच इसे work device पर इंस्टॉल किया था। कम से कम इस लेख में तो नहीं है, और मुझे दूसरे sources में भी नहीं मिला। बहुत-सी कंपनियाँ internal VPN access या कुछ internal systems में direct internet login भी allow करती हैं; यह आदर्श नहीं है, लेकिन सोच से ज़्यादा आम है। इससे Disney hack की याद आती है, जो personal PC पर इंस्टॉल किए गए compromised software से शुरू हुआ था। मैंने खुद देखा है कि बहुत-सी कंपनियों की IT सोच से कहीं ज़्यादा ढीली होती है
    • मैं तो ज़्यादा दोष उस IT department को दूँगा जिसने users को arbitrary software install करने दिया
    • मैं भी पूरी तरह सहमत हूँ। एक ही laptop पर work और personal use दोनों चलाने का विचार ही काफ़ी अव्यावहारिक लगता है। दुनिया की top 10 market cap कंपनियों में से एक में engineers की desk पर internet-बिना work computer और अलग network से जुड़ा internet computer अलग-अलग रखा जाता था। मेरे मुख्य work device में तो sound भी नहीं था। आवाज़ तक नहीं। ज़्यादातर लोग बिना sound वाले main work computer पर भी आराम से काम कर सकते हैं। मैं technology-hater नहीं हूँ, NUC, Raspberry Pi, laptop सब बहुत इस्तेमाल करता हूँ, लेकिन main work device पर YouTube देखना या game खेलना बिल्कुल ज़रूरी नहीं है। meetings के लिए दूसरा laptop, videos के लिए दूसरा laptop काफ़ी है। वही laptop जिसे café भी ले जाओ, office भी ले जाओ, और उसी पर game भी खेलो—मुझे लगता है यही संस्कृति Vercel को डुबोई, और आगे भी बहुत-सी कंपनियों को डुबोएगी
    • मेरे हिसाब से यह कई कारणों में से सिर्फ़ एक है। हाँ, यह बुरा फ़ैसला है, लेकिन दूसरे systems की security सिर्फ़ इस भरोसे पर नहीं टिकनी चाहिए कि “work laptop कभी compromise नहीं होगा।” अगर वही एकमात्र defense line है, तो अंत में समस्या आनी ही है

  • मुझे लगता है इस लेख में कुछ inaccuracies हैं। Vercel env var सभी at rest encrypted होते हैं, और sensitive check का मतलब सेट करने के बाद value दोबारा retrieve न कर पाना है, इसलिए इस जैसी स्थिति में यह उल्टा मददगार होता। और बिना source links के ऐसा लेख पढ़ना भी काफ़ी खटकता है

    • यहाँ UI decision थोड़ा दिलचस्प है। environment variables की list password की तरह छिपी दिखती है और view button भी होता है, इसलिए advisory पढ़ने से पहले sensitive flag की अहमियत तुरंत साफ़ नहीं दिखी। हमारे यहाँ भी कुछ secrets sensitive-mark नहीं थे, इसलिए अब हम rotation में काफ़ी व्यस्त हैं
    • लेकिन कुछ customers के env var सच में expose हुए थे, तो फिर यह सोच भी आती है कि क्या वे unencrypted थे

  • पिछले एक साल में मैंने खुद लगभग 12 AI tools approve किए थे, और उनमें से 9 Google Workspace में सभी emails पढ़ने और पूरे Drive access की permission माँग रहे थे। ऊपर से onboarding के दौरान मैं इतना व्यस्त था कि permissions ठीक से पढ़े बिना सब approve कर दिए। सोचता हूँ क्या tech-savvy लोग भी सच में ऐसा ही करते हैं। मैं तो किसी को email और Google Drive access देना इतना गंभीर मानता हूँ कि रात की नींद उड़ जाए, और permissions भी यथासंभव granular देना चाहता हूँ, unused apps तुरंत revoke करना चाहता हूँ। इस स्तर पर तो मान लेना चाहिए कि emails में NDA वाली बातें और confidential data पहले ही leak हो चुका है

    • मेरे workplace में एक दूसरी team ने खरीदे हुए AI meeting-notes tool को Google Workspace से integrate करने में मदद माँगी थी। vendor ने email और Drive files के read/write के लिए Domain-wide Delegation सेट करने को कहा, और ऐसा करने पर पूरे org के users automatically opt-in हो जाते और वे मना भी नहीं कर सकते थे। इसलिए मैंने vendor से कहा कि एक अलग “कम recommended” flow खोला जाए जिसमें user खुद login करे और OAuth consent screen accept करे। लेकिन पूरे process में vendor और हमारी organization दोनों इसे समय की बर्बादी की तरह लेते रहे। अगर कोई अपनी मर्ज़ी से broad permissions देना चाहता है, तो वह उसकी choice है, लेकिन किसी non-core tool को पूरे staff के लिए बिना opt-out के enable कर देना मुझे अनैतिक लगता है। security concerns तो अपनी जगह हैं ही। उससे भी डरावनी बात यह है कि AI का नाम आते ही लोग सोचना बंद कर देते हैं। 5 साल पहले यही smart लोग ऐसी request नहीं मानते; अब उन्हें लगता है कि सब कर रहे हैं, तो यह ठीक है
    • मैं व्यक्तिगत रूप से ऐसा नहीं करता। कुछ दिन पहले मैंने एक बात पढ़ी थी—“जो लोग सुरक्षित रहना चाहते हैं, वे आख़िरकार Stallman-style monastic computing तक पहुँचते हैं।” https://news.ycombinator.com/item?id=47796469#47797330 यह काफ़ी मज़ेदार भी है और सच भी लगता है। मैं भी अपने personal data पर खुलकर काम करने वाली agent automation के फ़ायदों का लाभ लेना चाहता हूँ, लेकिन अभी खुद को रोके हुए हूँ। कुछ अच्छे features छूटते हैं, इसका अफ़सोस होता है, लेकिन permissions सिर्फ़ आज की समस्या नहीं हैं। एक बार दे दो, तो वे लगभग हमेशा के लिए चली जाती हैं
    • मुझे पूरा यक़ीन है कि ऐसा बहुत आम है। permission fatigue और popup fatigue सचमुच मौजूद हैं। आजकल apps और websites user को उसके असली काम तक पहुँचने से पहले दर्जनों popups दिखाते हैं; उनमें से काफ़ी marketing के लिए होते हैं, कुछ बेवकूफ़ी भरी legal requirements, और सिर्फ़ कुछ ही सच में महत्वपूर्ण। आख़िरकार लोग “ठीक है, जो भी है, आगे बढ़ो” दबा देते हैं और security खिड़की से बाहर चली जाती है। मैं हमेशा यह याद रखता हूँ कि computer security लगभग एक भ्रम है, और network से जुड़े computer का data अर्ध-सार्वजनिक जानकारी जैसा मानना चाहिए। यह बात कि modern infrastructure का अधिकांश हिस्सा internet-connected computers पर चलता है, मानसिक शांति के लिए शायद ज़्यादा गहराई से न सोचना ही बेहतर है
    • हक़ीक़त मुझे यही लगती है। boss कहता है, “आज दोपहर की बड़ी meeting से पहले कुछ जल्दी से बना दो,” engineer setup के दौरान सबको approve कर देता है और सोचता है बाद में साफ़ कर लेंगे। फिर 6 महीने बाद वही hastily-made demo production बन जाता है
    • मैं इसे “व्यस्त था इसलिए पढ़े बिना approve कर दिया” नहीं कहूँगा। असल में onboarding ने permission माँगी, और मना करने का मौका था ही नहीं। मना करो तो app इस्तेमाल ही नहीं कर सकते, यानी यह ज़बरदस्ती है। मुझे लगता है यह concept ही ग़लत है। user “deny” दबाए, तब भी app को यह न बताया जाए कि इनकार हुआ; बस ऐसा लगे कि requested data मौजूद नहीं है। तब app अपनी ज़रूरी permissions माँग सकता है, और user permissions दिए बिना भी app का इस्तेमाल जारी रख सकता है। मेरे हिसाब से वही असली समाधान है

  • मेरा अंदाज़ा है कि यह कोई random Google Workspace app नहीं, बल्कि शायद Gmail access का मामला था। attacker को victim के inbox तक व्यापक access मिला होगा, और फिर उसने magic links या one-time codes से कुछ internal systems में login किया होगा। अगर ऐसा है, तो सवाल उठता है कि 2FA क्यों नहीं था, और शुरू से इतना व्यापक access allow ही क्यों किया गया। अगर यह नहीं, तो दूसरी संभावना यही है कि Google Workspace में API credentials store किए गए हों, जो संभव तो है लेकिन काफ़ी अजीब setup लगता है

  • यह सुनकर हैरानी होती है कि मामला सिर्फ़ Roblox cheat का था। मेरे बेटे का account भी Roblox cheat की वजह से compromise हुआ था, इसलिए मुझे यह गंभीर लगता है; हालाँकि उस बार बस Gamepass cookie चुराकर Minecraft की 4 licenses खरीद ली गई थीं और Microsoft ने जल्दी refund कर दिया था

    • इसका मतलब लगभग ऐसा निकलता है कि Vercel को किशोर script kiddies ने breach कर दिया। लेकिन सकारात्मक पक्ष यह है कि शायद जल्द ही गिरफ्तारी की खबर भी आ सकती है
    • मैं तो पहले यही जानना चाहूँगा कि game cheat चल ही कैसे गया। क्या ऐसी कंपनियों के पास device control नहीं होता, या होता है तो वे ध्यान नहीं देतीं? यह वैसा ही लगता है जैसे employee ने LastPass Plex incident जैसी गलती दोहरा दी हो

  • इस लेख में browser verification failed error दिख रहा है

    • विडंबना यह है कि वह साइट Vercel-hosted है

  • “कितने developers को पता होगा कि वह checkbox मौजूद है, और कितनों ने मान लिया होगा कि DB credentials और API keys by default encrypted हैं” — यह पंक्ति पढ़कर मैंने उल्टा सोचा। अगर secret input field में masking न दिखे, तो मैं save button दबाऊँ ही नहीं। हो सकता है किसी ने यह programmatically डाला हो, लेकिन उस case में भी कम से कम secret flag जैसी कोई चीज़ explicitly set होनी चाहिए थी। Vercel जैसी कंपनी में ऐसा issue आना ही थोड़ा अजीब लगता है

    • ऐसी input fields के लिए default assumption यही होनी चाहिए कि कोई न कोई sensitive information डालेगा। इसलिए default encryption ही एकमात्र उचित विकल्प लगता है
    • जैसे आप bridge engineer से यह नहीं पूछते कि “क्या आपने support reinforcement भूल तो नहीं गए?”, वैसे ही security की कम जानकारी होने पर भी मुझे यह सबसे बुनियादी चीज़ लगती थी। जिन्होंने sensitive जानकारी plaintext में store की और अब उसके नतीजे भुगत रहे हैं, उनके गुस्से को समझ सकता हूँ, लेकिन कहीं न कहीं वे अपनी practices की कीमत भी चुका रहे हैं। इसका मतलब यह नहीं कि सिर्फ़ victim blaming की जाए; Vercel को भी इस बेतुकी स्थिति की ज़िम्मेदारी लेनी चाहिए। फिर भी अंत में FAFO वाली भावना रह जाती है

  • सच कहूँ तो विडंबना यह है कि अब शायद security checks और सख़्त कर दिए गए हैं। जब मैंने पुराने Firefox से मूल लेख पढ़ने की कोशिश की, तो सिर्फ़ Failed to verify your browser, Code 11, और Vercel Security Checkpoint का संदेश मिला। ईमानदारी से कहूँ तो यह काफ़ी परेशान करने वाला था