سه حفره امنیتی بیت‌کوین پس از ۱۳ ماه افشا شد

بیت‌کوین Core سه حفره امنیتی را فاش کرد؛ تاخیر در اعلام جزئیات

بیت‌کوین Core روز سه‌شنبه جزئیات سه حفره امنیتی را منتشر کرد که همگی در اکتبر ۲۰۲۵ وصله شده بودند، اما ۱۳ ماه طول کشید تا جزئیات آن‌ها به صورت عمومی اعلام شود. یکی از این حفره‌ها به هزاران گره (node) اصلی شبکه که از طریق Tor قابل دسترسی بودند، اجازه می‌داد تا تمام اتصالات ورودی ناشناس از طریق Tor را به عنوان کامپیوترهای قابل اعتماد تلقی کنند. حفره امنیتی پرخطر دیگری باعث می‌شد گره‌های استخراج‌کننده تا زمان راه‌اندازی مجدد، قادر به تولید بلوک‌های معتبر نباشند. حفره سوم نیز می‌توانست به گره‌های همتا (peer) مخرب اجازه دهد تا پردازش بلوک‌ها را به مدت ۱۰ دقیقه متوقف کنند و این عمل را به طور نامحدود تکرار کنند.

بیت‌کوین Core در ۱۰ نوامبر سه اعلامیه امنیتی منتشر کرد. هر سه حفره امنیتی در نسخه اکتبر ۲۰۲۵ وصله شده بودند، اما ۱۳ ماه طول کشید تا جزئیات آن‌ها به صورت عمومی اعلام شود. یکی از این حفره‌ها که به راحتی قابل دست‌کم گرفتن است، باعث می‌شد هزاران گره اصلی شبکه که از طریق Tor قابل دسترسی بودند، هر اتصال ورودی ناشناس از طریق Tor را به عنوان یک اتصال داخلی تلقی کنند.

نقش گره‌ها را ابتدا بررسی کنیم. گره‌ها کامپیوترهایی هستند که تراکنش‌های بیت‌کوین را بررسی، فوروارد و زنجیره بلوکی کامل را ذخیره می‌کنند. این گره‌ها میزان ترافیک ورودی از اتصالات خارجی را محدود می‌کنند تا از غرق شدن گره‌ها جلوگیری شود. تنظیمات whitelist در Bitcoin Core این محدودیت‌ها را برای اتصالات مورد اعتماد اپراتورها، مانند سایر دستگاه‌ها در همان شبکه محلی، کاهش می‌دهد.

مشکل از آنجا ناشی می‌شود که سازندگان، Bitcoin Core را همراه با Tor بسته‌بندی کرده‌اند. Tor برای پنهان کردن آدرس‌های شبکه استفاده می‌شود و اتصالات ورودی از طریق Tor، از دید گره، دارای آدرس IP برنامه Tor هستند که معمولاً در همان دستگاه گره و در همان شبکه محلی قرار دارد. تا زمانی که این آدرس در محدوده IP مشخص شده در whitelist قرار گیرد، بازدیدکننده خارجی نیز مجوزهای مورد اعتماد را به ارث می‌برد. طبق این اعلامیه، نتیجه این بود که “هزاران گره اصلی شبکه که از طریق Tor قابل دسترسی بودند، تمام اتصالات ورودی Tor را در لیست سفید قرار دادند.” گره‌هایی که whitelist تنظیم نکرده بودند، از ابتدا تحت تأثیر قرار نگرفتند.

این حفره که با کد CVE-2025-62860 شناسایی شده و با ریسک متوسط ارزیابی شده است، در ۱۲ سپتامبر ۲۰۲۵ توسط Martin Zumsande و Antoine Poinsot گزارش شد. Zumsande سه روز بعد وصله را ارسال کرد و اتصالات ورودی Tor را هنگام اعمال مجوزهای whitelist مستثنی نمود. این وصله در نسخه‌های ۲۸.۳، ۲۹.۲ و ۳۰.۰ گنجانده شد؛ پس از نسخه ۳۰.۰، اتصالات ورودی از طریق آدرس‌های پیاز (onion addresses) هرگز در لیست سفید قرار نمی‌گیرند. Poinsot همچنین در ۱۹ سپتامبر به صورت خصوصی به فروشندگان نرم‌افزار تحت تأثیر اطلاع داد که چگونه با این مشکل برخورد کنند، اما اعلامیه نامی از این فروشندگان نبرد.

حفره دوم، CVE-2025-62861 با ریسک بالا، مربوط به نحوه پردازش گره‌ها در زنجیره‌های رقیب است. هنگامی که شبکه یک زنجیره را رها می‌کند، تراکنش‌های موجود در بلوک‌های رها شده دوباره به استخر تراکنش‌های در انتظار (mempool) اضافه می‌شوند و به طور عمدی از سیاست‌های ضد اسپم و توپولوژی عبور می‌کنند تا تراکنش‌های تأیید شده را به طور دقیق بازگردانند. اما قوانین اخراج همتا که در نسخه ۲۸.۰ معرفی شد، از این معافیت مستثنی نشد: تراکنش‌های TRUC طبق مقررات BIP 431، تنها می‌توانند یک والد تأیید نشده و یک فرزند تأیید نشده داشته باشند؛ هنگامی که یک تراکنش جدید باعث می‌شود یک والد TRUC، دومین فرزند تأیید نشده را داشته باشد، Core فرزند قبلی را به عنوان یک شیء قابل جایگزینی اخراج می‌کند. این منطق در هنگام بازگردانی زنجیره (reorg) نیز فعال می‌شود و در نتیجه ترکیبی از تراکنش‌ها ایجاد می‌شود که در بلوک معتبر است اما در mempool قابل بازسازی نیست.

پیامد آن مشخص است: گره‌ها سعی می‌کنند بلوک‌هایی را با تراکنش‌هایی که “ورودی آن‌ها دیگر وجود ندارد” ایجاد کنند و سپس توسط بررسی‌های اعتبار خودشان رد می‌شوند. گره‌های استخراج‌کننده تحت تأثیر، تا قبل از راه‌اندازی مجدد، قادر به تولید هیچ بلوک معتبری نخواهند بود. Bitcoin Core این مورد را پرخطر طبقه‌بندی کرده است و دامنه تأثیر آن شامل نسخه‌های ۲۸.۰ تا ۲۸.۲ و ۲۹.۰ تا ۲۹.۱ می‌شود؛ نسخه‌های پس از ۳۰.۰ مشکلی ندارند. Niklas Goegge در ۲۶ سپتامبر ۲۰۲۵ این مورد را گزارش کرد و اعلامیه هیچ حمله واقعی را ثبت نکرده است.

حفره سوم، CVE-2025-62859 با ریسک متوسط، از طریق فرآیند بازسازی بلوک‌های فشرده (compact block) عمل می‌کند. طبق توضیحات اعلامیه، گره پس از بازسازی بلوک فشرده، وضعیت دانلود را پاک می‌کند و سپس مولیتی شاهد (witness malleation) را بررسی می‌کند؛ اگر این بررسی با شکست مواجه شود، گره با استفاده از GETDATA از همان گره همتا، بلوک کامل را درخواست می‌کند و این درخواست دارای یک مهلت ۱۰ دقیقه‌ای است. یک گره همتای مخرب با اعلام زودهنگام یک بلوک فشرده می‌تواند گره آسیب‌پذیر را در این ۱۰ دقیقه متوقف کند.

مشکل تکرارپذیری آن است. اگر مهاجم به سه اتصال پهنای باند بالای گره آسیب‌پذیر دسترسی داشته باشد، یا اگر قربانی از تنظیمات -blocksonly برای پردازش بلوک‌ها استفاده کند، این توقف می‌تواند به طور نامحدود تکرار شود. این حفره که توسط Eugene Siegel در ۲۸ آوریل ۲۰۲۵ گزارش شد، اولین حفره از سه حفره کشف شده بود و در نسخه‌های ۳۰.۰ (۱۰ اکتبر) و ۲۹.۲ (۱۴ اکتبر) وصله شد.

روال Bitcoin Core این است که جزئیات حفره‌های امنیتی با ریسک متوسط و بالا، دو هفته پس از پایان پشتیبانی آخرین نسخه تحت تأثیر، منتشر می‌شود. آخرین نسخه تحت تأثیر در این دور، ۲۹.x بود که پشتیبانی آن در ۲۷ اکتبر ۲۰۲۶ به پایان رسید و دو هفته بعد، در ۱۰ نوامبر، روز انتشار این اعلامیه بود. این فاصله زمانی یک اشتباه نیست، بلکه فرصتی برای اپراتورها جهت ارتقاء است.

با این حال، این برنامه در حال تغییر است. Core در اکتبر ۲۰۲۶ قوانین را تغییر داد و برای حفره‌های امنیتی که به راحتی قابل کشف مجدد هستند، از جمله مواردی که با یک دستور ساده برای مدل‌های هوش مصنوعی قابل بازیابی هستند، اعلامیه انتشار را همزمان با انتشار وصله اعلام کرد. این سه CVE همچنان از برنامه زمانی طولانی‌تر قبلی پیروی می‌کنند، با این استدلال که در دسته جدید قرار نمی‌گیرند.

با در نظر گرفتن این سه مورد در کنار هم، سیگنال واضح است: نقاط ضعف واقعی بیت‌کوین نه در قوانین اجماع، بلکه در جزئیات پیاده‌سازی و استقرار نرم‌افزار گره‌ها نهفته است. هیچ یک از این سه حفره امنیتی نمی‌تواند منجر به سرقت سکه یا دو بار خرج کردن شود، اما هر کدام می‌توانند گره‌ها را از کار بیندازند، استخراج‌کنندگان را از تولید بلوک باز دارند، یا حفاظت از حریم خصوصی کاربران Tor را مستقیماً مختل کنند. در مقایسه با حفره امنیتی حافظه در ماه مه ۲۰۲۶ که امکان اجرای کد از راه دور را فراهم می‌کرد، سطح ریسک این حفره‌ها پایین‌تر است، اما دامنه تأثیر آن‌ها گسترده‌تر است، زیرا نقص لیست سفید Tor نه به دلیل تنظیمات مخرب، بلکه به دلیل بسته‌بندی سازندگان طبق دستورالعمل‌ها رخ داده است.

نکته قابل توجه در اینجا نوع ریشه مشکل است. این یک خطای محاسباتی در کد نیست، بلکه عدم تطابق بین مقادیر پیش‌فرض و توپولوژی استقرار است: whitelist قرار بود دستگاه‌های خودی را مورد اعتماد قرار دهد، اما برنامه Tor به طور تصادفی در آن آدرس قرار گرفت و در نتیجه کل اتصال خارجی مورد اعتماد قرار گرفت. چنین نقصی در تست‌های فازی یا ممیزی کد یافت نمی‌شود، بلکه در نحوه نصب واقعی در دنیای واقعی ظاهر می‌شود و عدم نام بردن از هیچ یک از فروشندگان بسته‌بندی در اعلامیه، مسئولیت بررسی را به جامعه واگذار می‌کند.

در ادامه سه نکته برای مشاهده وجود دارد. اول، تعداد گره‌های فعال در نسخه‌های ۲۸.x و ۲۹.۰، ۲۹.۱، که میزان واقعی در معرض خطر حفره پرخطر را تعیین می‌کند. دوم، اینکه آیا بسته‌های نصب که Core و Tor را با هم بسته‌بندی می‌کنند، مقادیر پیش‌فرض خود را تغییر داده‌اند یا خیر؛ این موضوع بدون اعلام عمومی نیاز به بررسی دارد. سوم، با توجه به اینکه هوش مصنوعی کشف مجدد حفره‌های قدیمی را ارزان کرده است، سنت “ابتدا وصله کن، ۱۳ ماه صبر کن و سپس اعلام کن” در پروژه‌های متن‌باز تا چه زمانی می‌تواند ادامه یابد؛ Core قبلاً یک بار قوانین خود را برای این منظور تغییر داده است و پروژه‌های دیگر احتمالاً به زودی با همین انتخاب روبرو خواهند شد.