Ajna v2 Exploit: बिना Oracle Attack के करीब $775,000 की निकासी

Ajna v2 में 29 अगस्त 2026 को हुआ exploit किसी बाहरी price oracle को corrupt करके नहीं किया गया। उपलब्ध रिपोर्टों के अनुसार, हमलावरों ने protocol की आंतरिक liquidation-accounting व्यवस्था में हेरफेर किया—यानी उसी self-contained सिस्टम में, जिसका इस्तेमाल Ajna collateral, debt और liquidation conditions तय करने के लिए करता है। इस हमले में Ethereum के सात lending pools से करीब $775,000 निकाले गए। 1311

सार्वजनिक जानकारी से हमले की श्रेणी और प्रभावित pools की पहचान होती है, लेकिन हर transaction और state change का पूरी तरह सत्यापित forensic reconstruction अभी उपलब्ध नहीं है। इसलिए हमलावरों के सटीक क्रम के बारे में किए गए दावों को फिलहाल प्रारंभिक समझा जाना चाहिए।

Ajna v2 exploit में क्या हुआ?

रिपोर्टों के मुताबिक, हमले से syrupUSDC, wstETH, rETH, cbETH, WBTC, WETH/USDC और sDAI pools प्रभावित हुए। कुल नुकसान का अनुमान करीब $775,000 है; बाद के एक breakdown में यह राशि लगभग $775,400 बताई गई। इनमें syrupUSDC pool को लगभग $173,700 का सबसे बड़ा नुकसान हुआ। 1913

Ajna ने abnormal fund movements की जांच शुरू करते हुए users को सलाह दी कि वे:

• quote-token funds निकाल लें;
• outstanding loans चुका दें; और
• protocol के साथ आगे कोई interaction न करें। 111435

इन निर्देशों से तत्काल जोखिम का संकेत मिलता था—यानी जांच के दायरे में आई accounting conditions के साथ आगे की activity से अतिरिक्त नुकसान हो सकता था।

निशाना liquidation accounting था, price oracle नहीं

Ajna का design जानबूझकर external price oracles पर निर्भर नहीं करता। अधिकांश DeFi lending protocols collateral prices तय करने के लिए Chainlink जैसी बाहरी services का इस्तेमाल करते हैं, जबकि Ajna lending और liquidation conditions के लिए अपने pools की activity और bucket accounting पर निर्भर करता है। 333

सामान्य liquidation process में debt और collateral को buckets से हटाया जाता है। इससे protocol के internal metrics, जिनमें Lowest Utilized Price (LUP) भी शामिल है, बदलते हैं। किसी loan को evaluate करने के लिए borrower का Threshold Price (TP), Neutral Price (NP) और pool का LUP जैसे variables इस्तेमाल किए जाते हैं। 3437

इस architecture से external oracle manipulation का एक जाना-पहचाना attack surface तो हट जाता है, लेकिन reliable economic accounting की जरूरत खत्म नहीं होती। 29 अगस्त की घटना पर उपलब्ध रिपोर्टों के अनुसार, attacker ने इसी internal liquidation path में हेरफेर किया, जिससे collateral, debt और liquidation-price treatment pools की वास्तविक economic backing से मेल नहीं खा रहे थे। 1311

हालांकि, उपलब्ध रिपोर्टें exploit को high level पर ही बताती हैं। deposits, borrowing, liquidation actions, repayments और withdrawals का वह पूरा क्रम स्वतंत्र रूप से सत्यापित नहीं हुआ है, जिसके कारण अंतिम नुकसान हुआ। इसलिए अधिक सटीक भाषा यह है कि attacker ने internal liquidation accounting का कथित रूप से फायदा उठाया, न कि किसी अपुष्ट transaction narrative को अंतिम तथ्य के रूप में पेश किया जाए।

“Oracle-free” का मतलब attack-proof क्यों नहीं है?

यह घटना एक महत्वपूर्ण फर्क सामने लाती है:

External price feeds हटाने से oracle risk घट सकता है; pricing risk खत्म नहीं होता।

Ajna ने critical assumptions को external data providers के बजाय अपने market structure और liquidation rules में केंद्रित किया। यदि ये rules collateral, debt या liquidation prices की internal representation को इस तरह बदलने दें कि वह वास्तविक economic value से अलग हो जाए, तो नतीजा आर्थिक रूप से oracle attack जैसा गंभीर हो सकता है—भले ही किसी third-party price feed से छेड़छाड़ न हुई हो। 111

DeFi lending systems के लिए यह एक व्यापक सबक है। Security review केवल code vulnerabilities और बाहरी dependencies तक सीमित नहीं होना चाहिए। यह भी जांचना जरूरी है कि borrowing, liquidation और repayment की असामान्य गतिविधियों के दौरान protocol की accounting state वास्तविक economic value से जुड़ी रहती है या नहीं।

Immutability ने emergency response को मुश्किल बनाया

Ajna v2 को immutable बताया गया है। इसका अर्थ है कि इसमें governance body, upgrade path, administrator key या प्रभावित contracts को रोकने वाला centralized mechanism नहीं था। 9

यह design discretionary intervention को सीमित करता है और governance तथा upgrade से जुड़े कुछ जोखिम घटा सकता है। लेकिन इसका दूसरा पहलू भी है: यदि deployed mechanism में खामी हो, तो attack के दौरान team के पास contract को तुरंत pause या patch करने का विकल्प नहीं रहता।

Defimon Alerts ने कहा कि उसने पहली exploit transaction से एक घंटे से अधिक पहले एक prepared attack का पता लगा लिया था और project के Discord channel के जरिए Ajna को चेतावनी दी थी। monitoring firm के अनुसार, team ने प्रतिक्रिया नहीं दी। यह Defimon का दावा है, स्वतंत्र रूप से तय किया गया निष्कर्ष नहीं; इसलिए timing और response को आगे के सबूत आने तक सावधानी से देखा जाना चाहिए। 816

DeFi risk के लिए इसका क्या मतलब है?

Ajna exploit का आकार crypto की सबसे बड़ी चोरी की घटनाओं की तुलना में छोटा था, लेकिन यह दिखाता है कि किसी protocol का जोखिम केवल headline dollar loss या TVL से नहीं समझा जा सकता। TRM Labs के अनुसार, 2026 की पहली छमाही में 207 crypto hacks और exploits दर्ज किए गए—उसके dataset में छह महीने की सबसे बड़ी संख्या। इनमें करीब 125 incidents smart-contract exploits से जुड़े थे। 1829

अलग से, The Defiant ने 2026 की दूसरी तिमाही में लगभग 70 DeFi exploits और $746 million के नुकसान की रिपोर्ट की। अलग-अलग trackers की inclusion criteria अलग होती हैं, इसलिए इन आंकड़ों की सीधी तुलना नहीं की जानी चाहिए। फिर भी, दोनों आंकड़े DeFi के व्यस्त और चुनौतीपूर्ण threat environment की ओर इशारा करते हैं। 23

Ajna की घटना का मुख्य संदेश साफ है: बाहरी oracles से बचने वाला architecture भी एक महत्वपूर्ण internal economic dependency रख सकता है। Oracle-free design, immutability और decentralization कुछ जोखिम कम कर सकते हैं, लेकिन दूसरे जोखिम बढ़ा भी सकते हैं—खासकर तब, जब abnormal accounting शुरू होने के बाद emergency control उपलब्ध न हो।