Cosmos Labs: سوءاستفاده از نقص مدیریت موجودی در Cosmos EVM

Cosmos Labs گزارش داده نقص بحرانی در ماژول مشترک Cosmos EVM بین 20 تا 25 اوت 2026 باعث خالی‌شدن وجوه در شش بلاک‌چین شده است. این آسیب‌پذیری با شناسهٔ GHSA-7g4w-cg88-2cq2 توسط تیم ارزیابی شده و توسط Cosmos Labs «بحرانی» توصیف گردیده؛ تا زمان انتشار گزارش هیچ شناسهٔ CVE یا امتیاز CVSS رسمی ثبت نشده بود.

نسخه‌های آسیب‌پذیر و نسخه‌های دارای اصلاح

  • نسخه‌های آسیب‌پذیر: < 0.6.2 و >= 0.7.0 < 0.7.2
  • نسخه‌های حاوی اصلاح: v0.6.2 و v0.7.2 — اصلاح رسمی در تاریخ 19 اوت منتشر شده است.

درخواست فوری برای اپراتورها

اپراتورهای زنجیره‌های مبتنی بر Cosmos EVM باید فوراً به یکی از نسخه‌های فوق یا ورژن‌های بعدی ارتقا دهند. این ارتقا «تغییر حالت» است و نیازمند هماهنگی شبکه‌ای است. اپراتورهایی که امکان ارتقای فوری ندارند، باید تولید بلاک را متوقف کنند تا از اجرای ارتقای حاکمیتی پراکنده و پرخطر جلوگیری شود؛ هیچ راهکار صرفاً پیکربندی برای رفع این نقص وجود ندارد.

چگونگی عملکرد نقص

نقص هنگام تطبیق وضعیت بین Ethereum Virtual Machine (EVM) و ماژول x/bank از Cosmos SDK رخ می‌دهد. شرح فنی به صورت خلاصه:

  • EVM StateDB تنها موجودی قابل‌صرف حساب را نگهداری می‌کند، در حالی که حساب‌های vesting در حالت SDK دو مقدار دارند: موجودی قابل‌صرف و موجودی قفل‌شده.
  • قابلیت‌های x/staking و پری‌کامپایل استیکینگ به بخشی از موجودی قفل‌شده اجازهٔ واگذاری (delegate) می‌دهد.
  • اگر یک حساب vesting بیش از موجودی قابل‌صرف خود واگذار کند، مقدار نوشته‌شده بازگشتی پس از واگذاری از موجودی قابل‌صرف کسر می‌شود؛ این کسر بدون بررسی انجام شده و مقدار به حدود 2^256 پیچ می‌خورد (wrap می‌شود).
  • در مرحلهٔ تطبیق وضعیت، بر اساس دلتا عملیات mint یا burn انجام می‌شود؛ مهاجم می‌تواند از حساب پیچ‌خوردهٔ خود مقدار محدودی خارج کند یا با ارسال مقدار 2^256 منهای موجودی به حساب قربانی، باعث سوزانده‌شدن دارایی واقعی او شود.

رفتار نهایی بسته به شاخهٔ نرم‌افزاری متفاوت است: شاخه‌های 0.6.x عملیات mint/burn را روی دفتر کل SDK انجام می‌دهند که ممکن است منجر به سرریز عرضه و توقف زنجیره شود؛ شاخه‌های 0.7.x موجودی‌ها را مستقیماً در x/bank تنظیم می‌کنند و برخی تغییرات پس از تبدیل uint256 به int256 باقی می‌مانند.

دلایل تأخیر در انتشار پچ و نقش فرایند «پچ بی‌صدا»

نقص ابتدا در 25 آوریل از طریق برنامهٔ جایزهٔ باگ گزارش شد و آن زمان تیم نتوانست آن را روی شبکه‌های با 18 دسیمال بازتولید کند؛ بنابراین به‌اشتباه نتیجه‌گیری شد که تنها شبکه‌های غیر-18 دسیمال در خطر هستند. تا 13 اوت مشخص شد همهٔ زنجیره‌ها آسیب‌پذیرند، اما به‌جای توزیع خصوصی پچ از کانال‌های امن، اصلاح از طریق فرایند عمومی «پچ بی‌صدا» ارسال شد؛ فرایندی که برای مسائل بدون ریسک از دست رفتن وجوه طراحی شده است.

این تصمیم با سیاست رسمی شرکت ناسازگار بود. سیاست می‌گوید وقتی مشکل خطری فوری یا سراسر شبکه‌ای دارد، باید اصلاح به‌صورت خصوصی یا از طریق ارتقای هماهنگ توزیع شود. Cosmos Labs پس از رخداد این تصمیم را نادرست ارزیابی کرده است.

اقدامات فنی پیشنهادی برای اپراتورها

اقدامات پیشنهادی در اطلاعیه رسمی شامل موارد زیر است؛ تیم‌های فنی و امنیتی باید بلافاصله آنها را بررسی و اجرا کنند:

  • ارتقا به v0.6.2 یا v0.7.2 یا نسخه‌های بعدی به‌صورت یک ارتقای هماهنگ‌شده شبکه (تغییر حالت).
  • توقف شبکه برای زنجیره‌هایی که نمی‌توانند فوراً ارتقا کنند؛ توقف (halt) بهتر از اجرای ارتقای حاکمیتی پراکنده است.
  • بستن پیش‌شرط با رد کردن پیام‌های MsgCreateVestingAccount، MsgCreatePermanentLockedAccount و MsgCreatePeriodicVestingAccount در ante handler؛ حساب‌های vesting موجود در genesis تحت تأثیر قرار نگرفته‌اند.
  • بازبینی مسیرهای کد و اجرای تست روی فورک محلی برای شناسایی نسخه‌های مخفی یا تکراری آسیب‌پذیر.
  • اعمال دو اصلاح کلیدی: اسنپ‌شاتِ موجودی قفل‌شده و نگهبان حساب ماژول (Module account guard). توجه شود که نگهبان حساب ماژول ممکن است تماس‌های EVM از حساب‌های ماژول را مختل کند.
  • تماس با کانال امنیتی Cosmos Labs برای هماهنگی و دریافت راهنمایی فنی؛ گزارش شده یازده پیاده‌سازی Cosmos EVM در زمان حادثه در کانال‌های امنیتی ثبت‌نام نکرده بودند.

پیامدها و توصیه‌های راهبردی

حادثه نشان می‌دهد همبستگی اجزا در اکوسیستم بلاک‌چین — به‌ویژه تطبیق وضعیت بین EVM و ماژول‌های SDK — می‌تواند ضعف‌های ظریف اما ویرانگری به‌وجود آورد. اپراتورها باید روندهای اعلان، ثبت در کانال‌های امنیتی و رویه‌های توزیع پچ را بازبینی کنند و ثبت در کانال‌های امنیتی را به یک الزام عملیاتی تبدیل نمایند.

منابع مرجع برای مطالعه بیشتر: Ethereum Virtual Machine و Cosmos.

توصیهٔ نهایی برای تیم‌های فنی: ارتقاها و تغییرات پیشنهادی را فوراً اعمال کنید و فرایندهای توزیع پچ‌ را طوری بازطراحی کنید که هشدارهای مرتبط با خطر از دست رفتن وجوه به‌صورت خصوصی و هماهنگ مدیریت شوند؛ در غیاب این اصلاحات، احتمال تکرار سوءاستفاده‌ها بالا خواهد ماند.