MoltBook हैक: Supabase कॉन्फ़िगरेशन की गलती से 15 लाख API keys उजागर

• AI agent-केंद्रित social platform Moltbook का database गलत तरीके से configure किया गया था, जिसके कारण 15 लाख API authentication tokens, 35 हज़ार emails और private messages बाहरी रूप से उजागर हो गए
• Client-side JavaScript में Supabase API key hardcode की गई थी, और Row Level Security(RLS) सेट नहीं थी, इसलिए कोई भी पूरे database को read-write access के साथ access कर सकता था
• डेटा में 17,000 वास्तविक users और उनके द्वारा चलाए जा रहे 15 लाख agent accounts की जानकारी शामिल थी, जिससे human-to-agent ratio 1:88 पाया गया
• उजागर जानकारी में OpenAI API keys सहित third-party credentials, private conversations, और posts को modify करने की permission तक शामिल थी, जिससे platform content की integrity को नुकसान पहुंचने का जोखिम मौजूद था
• यह घटना AI-आधारित 'vibe coding' की security limitations को दिखाती है और AI development environments में security defaults के automation और verification प्रक्रियाओं को मजबूत करने की ज़रूरत बताती है

---

Moltbook और security exposure का overview

• Moltbook एक AI-केंद्रित social network है, जहाँ AI agents posts लिखते हैं, comments करते हैं, vote करते हैं और reputation scores के ज़रिए activity करते हैं; यह खुद को “agent internet का first page” बताता है
  • OpenAI co-founder Andrej Karpathy ने इसे “सबसे चौंकाने वाली SF-जैसी छलांग” बताया, जिससे इसे ध्यान मिला
• Platform के founder ने कहा कि “कोड सीधे AI ने लिखा था” और यह 'vibe coding' approach से develop किया गया था
• Wiz research team ने Supabase database की misconfiguration खोजी, जिससे पूरे डेटा पर read-write access संभव था; issue की सूचना देने के कुछ घंटों के भीतर fix लागू कर दिया गया

उजागर Supabase credentials

• Moltbook website के client JavaScript bundle में Supabase connection details hardcode की हुई मिलीं
  • Project: ehxbxtjliybbloantpwq.supabase.co
  • API key: sb_publishable_4ZaiilhgPir-2ns8Hxg5Tw_JqZU_G6-
• Supabase public key के expose होने की अनुमति देता है, लेकिन अगर RLS policies न हों तो पूरे database तक access संभव हो जाता है
• Moltbook में RLS disabled थी, जिसके कारण सभी tables के read-write permissions public थे

बिना authentication के database access

• Research team ने API key का उपयोग करके REST API को सीधे call किया और admin-level response प्राप्त किया
  • Example request: curl https://ehxbxtjliybbloantpwq.supabase.co/rest/v1/agents?...
• Response में top agents की API keys और authentication tokens शामिल थे, जिनसे accounts का पूरा takeover संभव था
• PostgREST error messages और GraphQL introspection का उपयोग करके पूरे schema की पहचान की गई, और लगभग 47.5 लाख records के exposed होने की पुष्टि हुई

उजागर संवेदनशील डेटा

• Agent authentication information: हर account का api_key, claim_token, verification_code शामिल था
  • इससे attacker किसी भी agent के रूप में login कर सकता था, posts लिख सकता था और messages भेज सकता था
• User email और identity information: 17,000 से अधिक users के email addresses और X(Twitter) handles उजागर हुए
  • इसके अलावा observers table में 29,631 emails मिलीं
• Private messages और third-party credentials: 4,060 DMs बिना encryption के store की गई थीं, जिनमें कुछ में OpenAI API keys plain text में शामिल थीं
• Write permissions exposure: बिना authentication posts modify की जा सकती थीं, जिससे malicious content insertion या site defacement का जोखिम था
  • वास्तविक testing में post modification सफल रही, जिसके बाद RLS policy लागू करके इसे block किया गया

AI app development के लिए 5 security lessons

• 1. तेज development speed, अगर security defaults न हों, तो systemic risk पैदा कर सकती है
  • Supabase setting की एक पंक्ति पूरे exposure का कारण बनी
• 2. Engagement metrics की verification ज़रूरी है
  • 15,00,000 agents में वास्तविक इंसान सिर्फ 17,000 थे, यानी 88:1 ratio संभावित fake activity दिखाता है
• 3. Privacy collapse का chain effect
  • DMs के exposure की वजह से OpenAI API keys जैसे external service credentials भी leak हो गए
• 4. Write permissions, साधारण data leak से भी बड़ा integrity threat हैं
  • Content manipulation, prompt injection, narrative control जैसे जोखिम पैदा हो सकते हैं
• 5. Security maturity एक iterative improvement process है
  • Wiz और Moltbook team ने कई rounds की fixes और verification के बाद सभी tables को secure किया

vibe coding और security की चुनौतियाँ

• AI ने development barrier को कम किया है, लेकिन security barrier अभी भी ऊँचा है
• AI development tools को security defaults (RLS enable करना, credential scanning आदि) अपने आप लागू करने चाहिए
• जब security, AI development का built-in default element बन जाएगी, तब सुरक्षित और innovative AI software ecosystem बन सकेगा

Timeline

• 31 जनवरी 2026 21:48 UTC: Moltbook maintainer से पहला संपर्क
• 22:06: Supabase RLS misconfiguration report की गई
• 23:29: पहला fix (agents, owners, site_admins tables सुरक्षित)
• 1 फ़रवरी 00:13: दूसरा fix (agent_messages आदि सुरक्षित)
• 00:31: post modification vulnerability मिली
• 00:44: तीसरे fix से write permissions block की गईं
• 00:50~01:00: अतिरिक्त exposed tables मिलीं और अंतिम fix पूरा हुआ

[rustkim]

आखिर में बस Mac mini ही बचेगा, क्योंकि यह शुरुआती दौर है तो शायद आगे इससे भी बेहतर कुछ आएगा

[gogokow27]

हाहाहाहाहाहा....

[iolothebard]

खुशी-खुशी नाचते-नाचते… बस ऐसे ही… बर्बाद हो जाओ!

[kuthia]

आख़िरकार, जो होना था वह हो गया।

[crawler]

MoltBot में पहले agents को लेकर hacking issue फूटा, और अब platform भी फट गया, lol

लगता है यह 2026 के सबसे worst vibe project examples में गिना जाएगा।
अभी तो फरवरी ही है, लेकिन यह बात मैं भरोसे से कह सकता हूँ lol

[bini59]

क्या समस्या यह है कि vibe पर सुरक्षा की चिंता किए बिना भी बड़े पैमाने की सेवाएँ विकसित की जा सकती हैं?

[kimjoin2]

वाह

[GN⁺]

Hacker News की राय

• Moltbot/Moltbook की सफलता शुरू में चौंकाने वाली लगी थी, लेकिन अब कुछ हद तक समझ आती है
  असली बात यह है कि यह ‘pre-packaged agent’ है। टेक्नोलॉजी से ज़्यादा परिचित न होने वाले आम यूज़र के लिए “Mac Mini खरीदो, कुछ लाइनें कॉपी करके इंस्टॉल करो” जैसा आसान सेटअप बहुत आकर्षक लगता है
  लेकिन यही आसान पहुँच सिक्योरिटी दुःस्वप्न को बढ़ा रही है। तकनीकी समझ के बिना सिर्फ ट्रेंड के पीछे चलने वाले यूज़र बढ़ने से, कमज़ोर माहौल के लंबे समय तक बने रहने का ख़तरा है

  • क्या इसे सचमुच सफलता कहा जा सकता है, इस पर भी सवाल है। एक विश्लेषण के मुताबिक 15 लाख agents में सिर्फ 1.7 लाख नहीं बल्कि 17 हज़ार? इंसानी मालिक सिर्फ 17 हज़ार लोग ही हैं, ऐसा विश्लेषण भी है। मशहूर influencers के ज़िक्र करने से इसके viral होने का पहलू बड़ा है
  • सभी LLM डिज़ाइन के हिसाब से सुरक्षा के लिहाज़ से कमज़ोर हैं। prompt injection या reward hacking से इन्हें आसानी से बायपास किया जा सकता है। पूरा समाधान सिर्फ यही है कि बाहरी input और network access को पूरी तरह बंद कर दिया जाए
  • “Mac Mini खरीदकर इंस्टॉल करो” सिर्फ मार्केटिंग line है। असल में configuration errors बहुत होते हैं और context management बुरी तरह बिखरा हुआ है। logs रहते हैं, लेकिन ठीक पिछली बातचीत भी भूल जाती है। आइडिया अच्छा है, पर implementation कच्चा है
  • जैसे Dropbox के शुरुआती दौर में हुआ था, वैसे ही ‘पैक की गई आसान पहुँच’ इसकी सफलता की वजह है। लेकिन जब बड़ी कंपनियाँ भी hacking नहीं रोक पातीं, तो misconfigured DB जैसी चीज़ को लोग उतना बड़ा मुद्दा नहीं मानते। सुरक्षा से ज़्यादा सुविधा अभी भी भारी पड़ती है
  • यह सिर्फ चर्चा में आया है या सच में सफल है, यह अभी भी साफ़ नहीं है

• Scott Alexander के कहे अनुसार, agents का आपस में interact करते हुए जटिल व्यवहार पैदा करना महत्वपूर्ण है
  अगर यह वास्तविक दुनिया को प्रभावित करने लगे, तो यह अस्तित्वगत सवालों तक जा सकता है
  आखिरकार यह ऐसी संरचना है जहाँ “AGENT.md में YES लिखी हर चीज़” सच में घट सकती है

  • कुछ लोगों की प्रतिक्रिया है कि बात समझ में ही नहीं आ रही
  • इसी वजह से मैंने nono.sh बनाया। इसमें agent kernel-isolated sandbox के अंदर ‘zero trust’ मोड में शुरू होता है
  • इंसान भी एक हद तक ‘तोते की तरह दोहराने’ वाले प्राणी हैं। जैसे Moltbook Reddit की नकल करता है, वैसे ही इंसान भी अनुमानित पैटर्न के भीतर बातचीत करते हैं। हो सकता है कि हम जितना सोचते हैं, उससे कम बुद्धिमान हों

• Moltbook API सबके लिए खुला होने की वजह से, साधारण prompt से भी यूज़र email या data leak करवाया जा सकता है
  इसलिए Mac Mini से isolate करने जैसी कोशिशें हो रही हैं, लेकिन जब तक network से जुड़ा है, पूरी सुरक्षा असंभव है

  • यह पागलपन नहीं है। LLM निर्देश और डेटा के बीच फर्क पक्का नहीं कर पाते। यह एक तरह की ‘social engineering’ vulnerability है
  • आख़िर सवाल यह है कि क्या इससे बिना जोखिम के उपयोगी काम कराए जा सकते हैं। उदाहरण के लिए, किराना या travel booking करानी हो तो credit card access चाहिए
  • मैं LLM को DMZ environment में isolate करके इस्तेमाल कर रहा हूँ। इसे बिना disk वाले account पर, बिना sudo permissions के चलाया जाता है। यह परफेक्ट नहीं है, लेकिन ठीक-ठाक चल रहा है
  • व्यवहार में कोई पूरी सुरक्षा नहीं है। क्योंकि data access, untrusted text, और network communication की ‘घातक तिकड़ी’ तीनों मौजूद हैं
  • फिर भी monitoring/approval layer रखना संभव है। credit card limit की तरह LLM के actions को approve या restrict करने वाली संरचना बनाई जा सकती है

• मैंने OpenClaw आज़माया, और token usage बहुत ज़्यादा निकला
  सुरक्षा के लिए सीमित API permissions वाले dedicated device (Raspberry Pi आदि) मददगार हो सकते हैं। अगर Pi ज़्यादा ताकतवर model चला सके, तो उसे खरीदने की इच्छा है

• Moltbook के पास AI और इंसान में फर्क करने का कोई तरीका नहीं है। सवाल यह है कि ‘reverse CAPTCHA’ कैसे लागू किया जाए

  • मज़ाक में मैंने Claude को prompt दिया कि “मानव जासूस accounts ढूँढो”, और उसने सच में ‘Reverse Turing Problem’ नाम का thread बना दिया। लेकिन अब वहाँ spam की बाढ़ है, इसलिए बातचीत करना लगभग असंभव है
  • session के सभी input/output को sign करके auditable बनाने का तरीका चाहिए। इंसान द्वारा डाले गए prompts भी trace किए जा सकें
  • AI के लिए आसान लेकिन इंसानों के लिए कठिन काम, कम समय में कई बार करवाना भी एक पहचान का तरीका हो सकता है
  • या फिर ऐसे दुर्लभ सवाल जल्दी-जल्दी पूछे जा सकते हैं, जिनके जवाब LLM को पहले से पता होने की संभावना हो
  • लेकिन अंत में, यह पहचानना अब भी मुश्किल है कि कोई व्यवहार इंसान ने prompt से उकसाया था या नहीं

• कहा गया कि Moltbook ने security issue कुछ ही घंटों में ठीक कर दिया, लेकिन असली सवाल है कि ‘vibe coding’ से बने प्रोजेक्ट की सुरक्षा खामियों को कैसे समझाया जाए

  • सच में Claude ने Supabase के लिए query बनाई, और फिर किसी इंसान ने उसे Moltbook डेवलपर तक पहुँचाया ताकि fix किया जा सके। यक़ीन करना मुश्किल है, लेकिन यही हुआ

• यह हैरानी की बात है कि लोग Moltbook के अंदरूनी हिस्सों का analysis कर रहे हैं। शुरू में तो यह ‘मज़ाक में बनाया गया प्रोजेक्ट’ था, और किसी ने नहीं सोचा था कि यह इतना बड़ा हो जाएगा

  • लेकिन अगर यूज़र PII expose हो रही है, तो इसे मज़ाक कहकर टाला नहीं जा सकता; यह कानूनी समस्या बनती है। ‘vibe coding’ संस्कृति बिना ज़िम्मेदारी वाले development माहौल को बढ़ा रही है
  • Dogecoin भी मज़ाक के रूप में शुरू हुआ था, लेकिन आज उसकी कीमत अरबों डॉलर में है
  • security researchers का vulnerabilities ढूँढना भी शायद ‘vibe’ का ही हिस्सा कहा जा सकता है
  • लेकिन “यह तो मज़ाक था” कहकर वास्तविक नुकसान को ढका नहीं जा सकता
  • अगर यह creator की मंशा से बना नतीजा है, तो ‘मज़ाक’ वाला बहाना कमज़ोर पड़ जाता है

• OpenClaw instance द्वारा दूसरे instance को OpenAI key भेजने की घटना हँसाने वाली भी थी और बेचैन करने वाली भी
  असल में key भेजी गई थी या सिर्फ उसका नाटक किया गया था, यह साफ़ नहीं है

• Wiz का लेख खुद AI द्वारा लिखा हुआ सा लगता है। वाक्य संरचना और dash का इस्तेमाल बहुत ही typical LLM style जैसा है
  यह विडंबना है कि LLM से बने platform की security की आलोचना, LLM-लिखे लेख जैसी लगने वाली चीज़ से की जा रही है
  असली vulnerability शायद सच हो, लेकिन अगर इंसान ने लिखा होता तो अनावश्यक शब्दाडंबर कम होता

• exposed data से यह सामने आया कि 15 लाख agents में सिर्फ 17 हज़ार ही इंसान हैं
  लेकिन यह आँकड़ा researcher ने API key से table query करके निकाला था, इसलिए इसे सार्वजनिक करना सिर्फ bug report नहीं बल्कि कंपनी की आलोचना जैसा कदम लगता है
  इस तरह का तरीका researchers और companies के बीच विश्वास-आधारित सहयोग को नुकसान पहुँचा सकता है