پژوهشگران امنیتی از شناسایی یک آسیب‌پذیری بحرانی در MongoDB Server خبر داده‌اند که به مهاجمان راه دور اجازه می‌دهد بدون نیاز به نام کاربری و رمز عبور، شرایطی را ایجاد کنند که در زمان جابه‌جایی نقش سرور اصلی (Failover)، یکی از اعضای خوشه دیتابیس از کار بیفتد.
این آسیب‌پذیری با شناسه CVE-2026-118383 ثبت شده و بر اساس استاندارد CVSS نسخه 4.0، امتیاز بحرانی 9.5 از 10 را دریافت کرده است.
مشکل از نوع Use-After-Free است. در این وضعیت، نرم‌افزار به بخشی از حافظه دسترسی پیدا می‌کند که پیش‌تر آزاد شده و دیگر اعتبار ندارد. چنین خطایی می‌تواند باعث توقف ناگهانی فرایند دیتابیس و در شرایط خاص حتی زمینه اجرای کد دلخواه در سطح فرایند سرور را فراهم کند.
نحوه بهره‌برداری از آسیب‌پذیری
بر اساس تحقیقات منتشرشده توسط تیم Datadog Security Labs، مهاجم می‌تواند با ارسال دو درخواست Ping دست‌کاری‌شده و بدون نیاز به احراز هویت، وضعیت خاصی را در حافظه سرور ایجاد کند.
این درخواست‌ها حاوی پارامتری به نام readConcern.afterOpTime هستند که برای انتظار تا رسیدن عملیات تکثیر داده‌ها به یک نقطه مشخص استفاده می‌شود.
ارسال این درخواست‌ها به‌تنهایی باعث از کار افتادن سرور نمی‌شود. در واقع، شرایط حمله زمانی کامل می‌شود که عضو آسیب‌پذیر یک Replica Set در جریان انتخابات داخلی، به‌عنوان سرور اصلی جدید انتخاب شود، در حالی که هنوز تغییرات اخیر را از سایر اعضا دریافت نکرده است.
در مرحله همگام‌سازی باقیمانده داده‌ها، یک اشکال در پاک‌سازی منابع حافظه باعث می‌شود عملیات آزادسازی حافظه به شکل نادرست و بیش از یک بار انجام شود. نتیجه این وضعیت می‌تواند Crash شدن سرور جدید پیش از پذیرش درخواست‌های نوشتن باشد.
نکته مهم این است که فعال بودن قابلیت احراز هویت MongoDB به‌تنهایی مانع این حمله نمی‌شود. همچنین مهاجم نمی‌تواند مستقیماً انتخابات یا عقب‌ماندگی سرور هدف را کنترل کند و وقوع این شرایط به وضعیت داخلی Replica Set وابسته است.
سیستم‌های آسیب‌پذیر
این مشکل سرورهایی را تحت تأثیر قرار می‌دهد که عضو Replica Set هستند. اعضای مربوط به Shardها و Config Serverها در معماری Sharded Cluster نیز در معرض خطر قرار دارند.
در مقابل، نمونه‌های مستقل MongoDB که خارج از ساختار Replica Set اجرا می‌شوند، تحت تأثیر این آسیب‌پذیری نیستند.
نسخه‌های اصلاح‌شده منتشرشده عبارت‌اند از:
- MongoDB 9.0.7
- MongoDB 8.3.16
- MongoDB 8.0.37
- MongoDB 7.0.48
- MongoDB 6.0.30
- MongoDB 5.0.35
- MongoDB 4.4.32
تمام اعضای Replica Set باید به نسخه اصلاح‌شده شاخه مربوط به خود ارتقا پیدا کنند. در سرویس MongoDB Atlas این به‌روزرسانی‌ها طی فرایند نگهداری سرویس انجام می‌شوند، اما مدیران نسخه‌های Self-Managed باید به‌صورت مستقیم نسبت به ارتقای تمام اعضای خوشه اقدام کنند.
توصیه‌های امنیتی
تا زمان نصب نسخه اصلاح‌شده، محدود کردن دسترسی شبکه به سرویس MongoDB و مجاز کردن اتصال فقط از سمت سیستم‌های مورد اعتماد می‌تواند احتمال بهره‌برداری را کاهش دهد. البته این اقدام جایگزین نصب وصله امنیتی نیست.
همچنین توصیه می‌شود مدیران زیرساخت، لاگ‌های MongoDB را از نظر درخواست‌های غیرعادی Ping، رخدادهای مرتبط با فرایند Primary Catch-up و خطاهای حافظه بررسی کنند. از آنجا که درخواست‌های مخرب ممکن است مدت‌ها پیش از وقوع Failover ارسال شده باشند، بررسی لاگ‌های گذشته نیز اهمیت دارد.
این آسیب‌پذیری توسط خود شرکت MongoDB شناسایی شده و این شرکت اعلام کرده تاکنون از هیچ تلاش شناخته‌شده‌ای برای سوءاستفاده از آن اطلاع ندارد.
با توجه به امتیاز بحرانی این نقص و امکان بهره‌برداری بدون احراز هویت، مدیران دیتابیس‌های MongoDB به‌ویژه در محیط‌های Replica Set باید بررسی نسخه و نصب به‌روزرسانی‌های امنیتی را در اولویت قرار دهند.
دیدگاهتان را بنویسید
برای نوشتن دیدگاه باید وارد بشوید.