Redis، یکی از پرکاربردترین پایگاه‌داده‌های حافظه‌ای در جهان، به‌تازگی با یک آسیب‌پذیری بحرانی روبه‌رو شده است که بیش از ۱۳ سال در کد منبع آن وجود داشته است.
این نقص امنیتی با شناسه CVE-2025-49844 و نام مستعار RediShell توسط تیم تحقیقاتی شرکت Wiz Research شناسایی و در تاریخ ۳ اکتبر ۲۰۲۵ افشا شد.
شدت این آسیب‌پذیری طبق استاندارد CVSS 3.1 برابر با 10.0 ارزیابی شده یعنی در بالاترین سطح خطر ممکن.
🏛️ مروری کوتاه بر تاریخچه Redis
Redis (مخفف Remote Dictionary Server) یکی از محبوب‌ترین پایگاه‌داده‌های متن‌باز In-Memory است که نخستین بار در سال ۲۰۰۹ توسط Salvatore Sanfilippo توسعه یافت. این پروژه با هدف ارائه یک دیتابیس سریع، سبک و مناسب برای ذخیره‌سازی موقت داده‌ها، کشینگ و پردازش بلادرنگ طراحی شد و به‌سرعت جایگاه ویژه‌ای در میان توسعه‌دهندگان، شرکت‌های فناوری و زیرساخت‌های ابری یافت.
Redis به زبان C نوشته شده و از ساختارهای داده‌ای پیشرفته مانند Strings، Hashes، Lists، Sets و Sorted Sets پشتیبانی می‌کند.
در طول بیش از یک دهه، این فناوری به بخشی حیاتی از اکوسیستم DevOps، Cloud Computing، Big Data و Microservices تبدیل شده است.
با این حال، درست همان‌طور که محبوبیت و کاربرد Redis رشد کرد، سطح حملات و آسیب‌پذیری‌های امنیتی مرتبط با آن نیز افزایش یافت. موضوعی که در سال ۲۰۲۵ با کشف باگ ۱۳ ساله CVE-2025-49844 (RediShell) بار دیگر اهمیت امنیت در توسعه و نگهداری نرم‌افزارهای متن‌باز را یادآور شد.
🔍 ماهیت آسیب‌پذیری CVE-2025-49844
این آسیب‌پذیری در ماژول Lua scripting engine Redis قرار دارد. در شرایط خاص، مهاجمی که به سرور Redis دسترسی احراز هویت‌شده دارد، می‌تواند از طریق اجرای یک اسکریپت Lua دست‌کاری‌شده، منجر به شرایط use-after-free در حافظه شود.
این وضعیت به مهاجم اجازه می‌دهد تا کد دلخواه را در محیط میزبان Redis اجرا کند. در نتیجه منجر به Remote Code Execution (RCE) و کنترل کامل بر روی سیستم شود.
از آن‌جا که Redis معمولاً در محیط‌های DevOps، caching، queue management و microservices به‌صورت گسترده به‌کار می‌رود، احتمال بهره‌برداری از این نقص در محیط‌های سازمانی بالا است.
⚙️ نسخه‌های آسیب‌پذیر و وصله‌های امنیتی
تمام نسخه‌های Redis که از Lua scripting پشتیبانی می‌کنند، در معرض خطر این آسیب‌پذیری هستند.
توسعه‌دهندگان Redis در پاسخ به این کشف، وصله‌هایی در نسخه‌های زیر منتشر کرده‌اند:
- Redis 6.2.20
- Redis 7.2.11
- Redis 7.4.6
- Redis 8.0.4
- Redis 8.2.2
به‌روزرسانی به یکی از نسخه‌های فوق تنها روش قطعی برای رفع آسیب‌پذیری است.
🧱 اثر و سطح خطر در محیط‌های واقعی
مطالعه‌ی Wiz و داده‌های Shodan نشان می‌دهد که بیش از ۳۳۰٬۰۰۰ نمونه Redis در سطح اینترنت در دسترس عموم قرار دارند و از این میان حدود ۶۰٬۰۰۰ نمونه بدون هیچ مکانیزم احراز هویت فعالی اجرا می‌شوند.
در چنین شرایطی، مهاجم در صورت دسترسی به نمونه‌ای از Redis حتی در شبکه داخلی سازمان می‌تواند با اجرای یک اسکریپت ساده، کنترل سیستم را در دست گیرد، داده‌ها را استخراج کرده یا به عنوان نقطه‌ی ورود به شبکه استفاده کند.
🧩اقدامات کاهش خطر (Mitigation)
تا پیش از نصب وصله‌های رسمی، اقدامات زیر برای کاهش خطر توصیه می‌شود:
غیرفعال‌سازی اجرای Lua برای کاربران غیرمجاز
با استفاده از تنظیمات ACL، دستورات EVAL و EVALSHA را فقط برای کاربران مطمئن فعال نگه دارید.
محدودسازی دسترسی شبکه‌ای Redis
اطمینان حاصل کنید که Redis تنها از طریق شبکه داخلی در دسترس است و پورت 6379 در معرض اینترنت عمومی نیست.
پایش فعالیت‌های غیرمعمول
بررسی لاگ‌ها برای شناسایی دستورات Lua غیرمنتظره یا رفتارهای مشکوک حافظه.
استفاده از نسخه‌های patchشده
نسخه‌های جدید منتشرشده در اکتبر ۲۰۲۵ شامل اصلاح کامل کد در ماژول Lua هستند.
🔬 تحلیل فنی مختصر
باگ در مدیریت حافظه‌ی Redis هنگام اجرای تابع lua_gc (مربوط به garbage collection در Lua) رخ می‌دهد. در صورت استفاده‌ی نادرست از این تابع در هنگام آزادسازی اشیای داخلی Redis، یک freed pointer ممکن است مجدداً فراخوانی شود. حالتی که در امنیت نرم‌افزار با عنوان Use-After-Free شناخته می‌شود.
این نقص، در صورت ترکیب با payload دقیق، می‌تواند منجر به اجرای arbitrary code شود.
🧠 پیامدهای امنیتی
وجود این آسیب‌پذیری در ابزاری با عمر طولانی مانند Redis، نشان می‌دهد حتی پروژه‌های متن‌باز با جامعه‌ی توسعه‌دهندگان فعال نیز ممکن است آسیب‌پذیری‌های مزمن و نهفته داشته باشند. این کشف همچنین اهمیت اجرای تست‌های امنیتی پیشرفته مانند fuzzing، static analysis و code auditing را در چرخه توسعه نرم‌افزارهای حیاتی یادآور می‌شود.
🛡️ جمع‌بندی
آسیب‌پذیری RediShell (CVE-2025-49844) نمونه‌ای از یک تهدید دیرپا و پرخطر است که می‌تواند پیامدهای گسترده‌ای برای سازمان‌های وابسته به Redis در زیرساخت‌های ابری و DevOps داشته باشد.
تیم‌های امنیتی باید فوراً Redis را به نسخه‌های جدید ارتقا دهند، اجرای اسکریپت Lua را محدود سازند و دسترسی سرویس را صرفاً به شبکه‌های داخلی مقید کنند.
