FOGO Exploit: नेटवर्क सामान्य रहा, लेकिन Foundation वॉलेट से 400 मिलियन टोकन चोरी

29 अगस्त 2026 को Fogo Foundation के एक वॉलेट से लगभग 400 मिलियन FOGO टोकन एक हमलावर के पते पर भेज दिए गए। यह FOGO की शुरुआती कुल supply का करीब 4% और रिपोर्ट की गई circulating supply का 10% से अधिक है। हालांकि, Fogo का blockchain नेटवर्क इस घटना के बाद भी सामान्य रूप से चलता रहा। सार्वजनिक रिपोर्टों से अभी यह तय नहीं होता कि हमलावर ने Foundation वॉलेट तक शुरुआती पहुंच कैसे हासिल की। 412

FOGO में क्या हुआ?

यह breach Fogo Foundation के उस वॉलेट को प्रभावित करता है, जिसमें बड़ी मात्रा में टोकन रखे थे। Foundation ने कहा कि उसने प्रमुख cryptocurrency exchanges को सूचित किया है और funds को track करने, जहां संभव हो वहां deposits या withdrawals रोकने और recovery की कोशिश के लिए law-enforcement agencies तथा blockchain-forensics firms के साथ समन्वय कर रही है। 412

यहां एक अहम अंतर समझना जरूरी है: उपलब्ध रिपोर्टिंग इसे Foundation की custody failure बताती है, न कि Fogo के consensus mechanism या underlying network पर हमला। Fogo के अनुसार blockchain सामान्य रूप से operational रहा। 1215

टोकन ट्रांसफर के बाद FOGO की कीमत लगभग 20% गिरने की खबरें आईं। हालांकि, अलग-अलग exchanges और समय के आधार पर गिरावट का आंकड़ा बदल सकता है। 4

सबसे महत्वपूर्ण forensic सवाल—क्या private key चोरी हुई, operational security में चूक हुई, social engineering का इस्तेमाल हुआ या कोई दूसरा रास्ता अपनाया गया—का अभी सार्वजनिक रूप से पुष्टि किया हुआ उत्तर नहीं है। इसलिए किसी खास attack method को अभी confirmed बताना जल्दबाजी होगी।

Avici/Rain exploit इससे कैसे अलग था?

Avici की घटना Rain के Solana card contract के एक पुराने और vulnerable version से जुड़ी थी। रिपोर्टों के मुताबिक हमलावर ने विशेष रूप से तैयार किए गए signature bundles के जरिए unauthorized collateral-administrator privileges हासिल किए और फिर funds निकाले। यह contract Avici और कुछ अन्य programs में इस्तेमाल हो रहा था। 10

Avici ने बताया कि प्रभावित हिस्सा वह अलग Solana contract था, जिसमें card top-up के बाद के balances रखे जाते थे। यह उपयोगकर्ताओं के self-custodied Solana या EVM wallets से अलग था। कंपनी की reconciliation के अनुसार 1,685 users के कुल $500,859.22 के balances प्रभावित हुए। Rain और Avici ने कहा कि संबंधित contracts को upgrade कर दिया गया है, आगे कोई unauthorized activity नहीं मिली और प्रभावित उपयोगकर्ताओं को पूरी राशि लौटाई जाएगी। 35810

अलग on-chain monitoring में 10,000 SOL को लगभग $1.02 million USDC में बदले जाने, फिर cross-chain bridge के जरिए करीब 418 ETH में बदलने और Tornado Cash के माध्यम से भेजे जाने की जानकारी सामने आई। इन transaction-flow estimates को Avici के confirmed card-balance loss के बराबर नहीं मानना चाहिए, क्योंकि शुरुआती on-chain अनुमान और बाद की user-balance reconciliation घटना के अलग-अलग पहलुओं को मापते हैं। 261446

Avici ने कथित तौर पर FBI के Internet Crime Complaint Center (IC3) में शिकायत भी दर्ज की। हालांकि, उपलब्ध सार्वजनिक सामग्री शिकायत की पूरी जानकारी को स्वतंत्र रूप से verify करने के लिए पर्याप्त primary-source detail नहीं देती। 48

मूल अंतर: custody failure बनाम code failure

दोनों घटनाओं को इस तरह अलग किया जा सकता है:

• FOGO: हमलावर ने Foundation के privileged wallet पर नियंत्रण हासिल किया और बड़ी token allocation ट्रांसफर कर दी। Blockchain नेटवर्क online रहा।
• Avici/Rain: हमलावर ने पुराने smart contract में authorization और signature-validation की कमजोरियों का फायदा उठाकर customer card balances नियंत्रित करने वाले अधिकार हासिल किए।

इनमें से कोई भी घटना यह साबित नहीं करती कि पूरी blockchain अपने-आप विफल हो गई। इसके बजाय, दोनों मामलों ने दिखाया कि blockchain से जुड़े applications, wallets, contracts और operational controls ही वास्तविक attack surface बन सकते हैं।

Term Labs घटना से क्या सीख मिलती है?

23 अगस्त की Term Labs घटना बताती है कि privileged access हमेशा private key या contract administrator से ही नहीं आता। रिपोर्टों के अनुसार, एक हमलावर ने करीब $951 खर्च करके पर्याप्त governance power हासिल की, malicious proposals पास किए और strategy vaults से लगभग $8.5 million निकाल लिए। चोरी की गई assets में करीब 2,843 ETH और 1.68 million USDC शामिल थे। 111

इस घटना में governance voting power खुद एक security boundary बन गई। यदि कोई protocol कम लागत में हासिल की गई majority को permissions बदलने या vaults पर तुरंत नियंत्रण देने की अनुमति देता है, तो governance system व्यवहार में एक administrative key की तरह काम कर सकता है।

इन घटनाओं से सामने आने वाली चार बड़ी सुरक्षा सीख

1. Privileged access को application code जितनी गंभीरता से सुरक्षित करें

Treasury wallet, contract administrator, governance token या migration authority blockchain के consensus layer में किसी गड़बड़ी के बिना भी assets पर नियंत्रण दे सकते हैं। ऐसे privileges को न्यूनतम रखना चाहिए, जहां संभव हो वहां कई पक्षों में बांटना चाहिए, मजबूत signing controls से सुरक्षित करना चाहिए और असामान्य transfers या permission changes की निगरानी करनी चाहिए।

2. पुराने deployments सक्रिय हों तो upgrade अधूरा है

Rain की घटना दिखाती है कि कुछ programs में पुराने contract version के सक्रिय रहने से कितना जोखिम पैदा हो सकता है। सुरक्षित migration के लिए सभी deployments की पूरी inventory, स्पष्ट migration deadline, जहां संभव हो legacy authorities को disable करना और deprecated contracts पर calls की monitoring जरूरी है। 310

3. Audit operational security का विकल्प नहीं है

सामान्य audit compromised treasury key, खराब upgrade management, signature-domain की गलती या ऐसी governance व्यवस्था से नहीं बचा सकता जिसकी voting power सस्ते में खरीदी जा सके। Security reviews में authorization paths, signature validation, upgrade और migration logic, custody procedures तथा governance economics को भी शामिल करना चाहिए—सिर्फ नए contract code को नहीं।

4. घटनाओं की बढ़ती संख्या खुद एक जोखिम है

DeFi का व्यापक माहौल भी कमजोर होता दिख रहा है। The Defiant द्वारा रिपोर्ट किए गए DefiLlama data के अनुसार, Q2 2026 में लगभग 70 DeFi exploits में करीब $746 million चोरी हुआ—यह पिछली quarterly incident-count record से लगभग दोगुना था। 20

अलग-अलग trackers और methodologies के कारण आंकड़ों में अंतर हो सकता है, लेकिन दिशा स्पष्ट है: users और builders को keys, permissions, bridges, governance systems और smart contracts—सभी स्तरों पर बार-बार होने वाली failures का सामना करना पड़ रहा है। 1925

प्रभावित उपयोगकर्ताओं को क्या करना चाहिए?

1. सिर्फ official incident channels पर भरोसा करें। Social-media replies, direct messages या emergency “recovery” forms से आए links पर क्लिक न करें। बड़े exploits के बाद phishing और recovery scams तेजी से बढ़ते हैं।

2. Exposure का भरोसेमंद संकेत हो तभी funds move करें। यदि private key, wallet या संबंधित contract permission के compromise होने की आशंका है, तो assets को नए wallet में transfer करें—बेहतर होगा कि signing के लिए hardware-backed device इस्तेमाल हो। Destination address को स्वतंत्र रूप से verify करें और केवल अपुष्ट अफवाह पर funds न हटाएं।

3. अनजान permissions और token approvals revoke करें। Unfamiliar token approvals, delegated authorities और unlimited allowances की जांच करें, खासकर पुराने या प्रभावित applications से जुड़े permissions की। Revocation tool इस्तेमाल करने से पहले chain और contract address verify करें, क्योंकि नकली “approval revoker” websites भी funds चुरा सकती हैं।

4. Avici users card balances और self-custody wallets में अंतर समझें। रिपोर्ट के अनुसार प्रभावित हिस्सा अलग card-balance contract था। Verified reimbursement instructions का पालन करें, लेकिन seed phrase या private key कभी साझा न करें। 3514

5. Evidence सुरक्षित रखें। Wallet addresses, transaction hashes, screenshots, balances और timestamps सेव करें। ये records exchange freezes, reimbursement claims और law-enforcement reports में मदद कर सकते हैं।

6. Reimbursement मिलने तक उसे pending मानें। Refund का वादा recovered funds के बराबर नहीं है। Assets वास्तव में wallet या account में आने से पहले recovery पूरी मानकर न चलें और किसी भी “asset recovery” service को upfront fee न दें।

FOGO मामले की सबसे बड़ी सीख यह है कि blockchain operational रह सकता है, फिर भी किसी privileged wallet का compromise विनाशकारी नुकसान कर सकता है। Avici/Rain घटना दूसरी चेतावनी देती है: vulnerable contract को पहचानकर upgrade कर देना पर्याप्त नहीं, यदि पुराने deployments और authorization paths अभी भी users को exposed छोड़ते हों। DeFi security इसलिए केवल immutable code पर निर्भर नहीं है; इसके लिए disciplined custody, complete migrations, सीमित permissions और ऐसी governance design भी जरूरी है जिसे सस्ते में कब्जे में न लिया जा सके।