همه چیز درمورد آسیب پذیری React2Shell در ۲۰۲۵

اگه کمی با دنیای توسعه وب آشنا باشید اسم این آسیب پذیری رو در شبکه های مجازی شنیدید. این باگ توسط Lachlan Davidson به‌صورت Responsible Disclosure در 29 نوامبر 2025 به تیم React گزارش شده و تیم React/Vercel در 3 دسامبر 2025 پچ را منتشر کردن. به نظر من اگه منتشر نمیکردن آسیبش کمتر بود :/ چون طبق معمول افراد بیکار منتظر نشستن تا نهایت سواستفاده رو از چنین آسیب پذیری ها ببرن. فقط چند ساعت بعد از انتشار پچ، exploit های فعال زیادی در اینترنت ظاهر شدن. مهاجمان (از گروه‌های مرتبط با دولت چین مثل Earth Lamia و Jackpot Panda) فوراً شروع به اسکن و حمله کردن. از اجرای کدها از راه دور روی سرور ها تا تبدیل سرور ها به ماینر و … اگه توی لینکدین یه سرچی با عنوان “React2Shell” یا “آسیب‌پذیری CVE-2025-55182 ” کنید، توسعه دهنده ها پست های زیادی با این عنوان ها گذاشتن و هشدار آپدیت سریع پروژه های تحت تاثیر دادن مثل این یکی. حالا با هم بررسی کنیم ببینیم داستان چیه.

آسیب‌پذیری CVE-2025-55182 چیه؟

آسیب پذیری React2Shell یک باگ امنیتی بسیار جدی در React Server Components (RSC) و فریم‌ورک‌هاییست که از آن استفاده میکنن (مثل Next.js)، که به مهاجم اجازه اجرای کد دلخواه روی سرور بدون هیچ احراز هویتی را میده — یعنی Remote Code Execution (RCE). همچنین امکان DoS و افشای کد منبع را ایجاد میکنه. این نقص با شناسه CVE-2025-55182 برای خود React و CVE-2025-66478 برای Next.js ثبت شده و امتیاز CVSS 10.0 (Critical) داره. توسعه دهدگان امتیاز CVSS 10.0 (Critical) رو بهش دادن چون مهاجم بدون نیاز به احراز هویت میتونه حمله رو به راحتی از طریق یک تک درخواست HTTP انجام بده. حمله در واقع با استفاده از ضعف در سیستم «Flight protocol» انجام میشه که شامل مراحل زیر هست:

1. RSC داده‌های دریافتی را نامطمئن پردازش می‌کند
2. مهاجم میتونه داده‌هایی بسازد که منجر به pollute کردن prototype در جاوااسکریپت میشه
3. در نهایت به تابع Function constructor دسترسی و کد دلخواه را اجرا میکنن.

چرا مهاجم تونسته به خود سرور هم به راحتی دسترسی پیدا کنه؟

وقتی وب اپ مشکل امنیتی پیدا کنه یعنی درگاهی به سمت سرور باز شده. هکر فقط با یه درخواست HTTP به خود سرور دسترسی پیدا کنه. که میتونه هر یک از این سناریو ها باشه:

• سناریو اول: اپ در سرور با root اجرا شده (فاجعه کامل) مثلا pm2 start app.js –name app و کل PM2 با root بالا اومده یا node server.js. این یعنی هر دستور داخل اپ برابر با دستور روت (رایج‌ترین اشتباه در سرورهای Node / Next / React)
• سناریو دوم: در خیلی از سرور ها یوزر روت پسورد نداره! که کار هکر رو بسیار ساده میکنه!
• سناریو سوم: کانفیگ بد اپ روی سرور مثلا اگر اپ مستقیم روی host اجرا شده یا بدون Docker دیپلوی شده باشه یا اینکه بدون AppArmor / SELinux کانفیگ شده. در اینصورت exploit اپ = دسترسی مستقیم به سیستم عامل
• سناریو چهارم: Privilege Escalation بعد از ورود!‌ حتی اگر اپ با یوزر عادی اجرا شده باشه درصورتیکه کرنل سیستم عامل قدیمی باشه، SUID binary آسیب‌پذیر باشه یا کرون جاب های سرور writable باشن هکر میتونه نفوذ کنه و سرویس های persistence بسازه که بطور سایلنت در سرور اجرا بشن

در واقع در این نوع آسیب پذیری کلید سرور در اکثر موارد زیر لایه اپلیکیشن قرار گرفته

چه پکیج‌ها و سامانه‌هایی تحت تأثیر هستن؟

هر پکیجی که React Server Components (RSC) را اجرا میکنه، ممکنه در خطر باشه که شامل react-server-dom-webpack ، react-server-dom-parcel و react-server-dom-turbopack میشه. همچنین فریم‌ورک‌هایی که از این پکیج‌ها استفاده میکنن مثل Next.js (App Router) . استفاده از App Router در Next.js به‌طور پیش‌فرض سرور را در معرض این آسیب‌پذیری قرار میده چون App Router وظیفه‌ی اجرای React Server Components (RSC) و Server Actions را داره — همین بخش است که دچار نقص امنیتی است و قابل Exploit شدنه. Next.js از نسخه‌ی 13 به بعد App Router را به‌عنوان روش اصلی مسیریابی معرفی کرده و این بخش Server Components و Server Actions را اجرا میکنه. Server Actions در App Router از React Server Components استفاده می‌کنند تا بخشی از منطق سرور را از کلاینت فراخوانی کنن. همین رفتار است که باعث میشه، حتی اگر شما خودتان صریحاً از Server Actions استفاده نکرده باشید، چون App Router به‌صورت پیش‌فرض RSC را فعال میکنه، وب آپ میتونه آسیب‌پذیر بشه. ورژن های 19.0.0, 19.1.0, 19.1.1, 19.2.0 از کامپوننت React RSC و ورژن های 15.0.0 تا 16.0.6 (تمام زیرنسخه‌ها در این بازه) از کامپوننت Next.js App Router تحت تاثیر این آسیب پذیری هستن.

راه‌حل‌های ارائه شده توسط توسعه دهندگان NEXT ( تیم vercel labs )

به توصیه توسعه دهندگان در گیت هاب باید فوراً پکیج‌های RSC و Next.js را آپدیت کنین. دستور زیر رو اجرا کنین در روت پروژتون:

npx fix-react2shell-next

این دستور پکیج‌های آسیب‌پذیر در package.json را شناسایی و فایل lock را آپدیت می‌کنه . نسخه‌های امن :

react-server-dom-webpack	>=19.0.1
react-server-dom-parcel	>=19.1.2
react-server-dom-turbopack	>=19.2.1
Next.js	15.0.5، 15.1.9، … to 16.0.7

تجربه یکی از قربانی های این آسیب پذیری

در تاریخ ۶ دسامبر ۲۰۲۵، سرور عملیاتی ما از طریق سوءاستفاده از آسیب‌پذیری React2Shell (CVE-2025-55182) دچار یک نقض امنیتی شد که منجر به نصب غیرمجاز نرم‌افزار استخراج ارز دیجیتال شد. این گزارش، جدول زمانی کامل حادثه را از کشف اولیه تا اقدامات اصلاحی و مقاوم‌سازی مستند می‌کند. یک مهاجم از آسیب‌پذیری اجرای کد از راه دور React2Shell (CVE-2025-55182) در برنامه وب ما سوءاستفاده کرد تا به سرور دسترسی غیرمجاز پیدا کند، نرم‌افزار استخراج ارز دیجیتال XMRig را نصب کرد و آن را به عنوان یک سرویس سیستم پایدار پیکربندی کرد. مشخصات این حمله به صورت زیر بوده:

• بردار حمله: React2Shell (CVE-2025-55182) – آسیب‌پذیری اجرای کد از راه دور
• آسیب‌پذیری: RCE بحرانی در برنامه وب مبتنی بر React
• روش بهره‌برداری: تزریق دستور از طریق ورودی کاربر بدون کد امنیتی
• بار داده: XMRig Monero (XMR) cryptocurrency miner v6.24.0
• مکانیسم پایداری: سرویس Systemd (c3pool_miner.service)
• تأثیر: استفاده زیاد از CPU، اتمام منابع سیستم، دسترسی بالقوه به داده‌ها
• روش کشف: تخریب عملکرد (تمام شدن RAM)
• زمان تشخیص: نامشخص (زمان روشن بودن سرور: ۴۳۳ روز)

زمان حمله چه اتفاقی می افتد؟

این حادثه زمانی کشف شد که نظارت روتین سیستم، مصرف غیرعادی منابع را نشون میده. مصرف رم تا ۸۰ درصد بالارفته و سرویس هایی مثل xmrig حدود یک سوم پردارنده رو اشغال میکنن. بدتر از اون اینه که این سرویس ها با دسترسی روت اجرا شدن! با اجرای این دستور میشه اصلاعات بیشتری در مورد پروسس موردنظر گرفت

مشخصات این بدافزار

ویژگی	مقدار	تحلیل
Binary Path	/root/credit-webview/xmrig-6.24.0/xmrig	در دایرکتوری وب اپ نصب میشه
Mining Pool	pool.hashvault.pro:443	Monero (XMR) mining pool over TLS)
Wallet Address	8BWy7p...kPR6e	95-character Monero wallet identifier
Worker Name	ZimbabveDC	Attacker’s identifier for this compromised host
TLS Enabled	Yes (port 443)	Encrypted traffic to evade detection
Process State	Ssl	Running as daemon with session leader status

با جستجوی عبارت ماینر در سرویس های سیستم میشه دید که سرویس c3pool_miner.service توسط هکر ساخته شده

root@ubuntu:~# ls -la /etc/systemd/system/ | grep miner

دسترسی چطور انجام شده؟

در این حمله، مهاجم پس از نفوذ به سرور، فایل باینری XMRig را روی سیستم گذاشته که یک برنامه متن-باز و محبوب برای استخراج ارز دیجیتال مونرو (Monero / XMR) هست. البته این ابزار برای استخراج قانونی استفاده میشه، اما در حملات سایبری سوءاستفاده میشه چون:

• مستقل از وابستگی‌ها است (فایل باینری کامل)
• از پروتکل‌های رمزگذاری شده (TLS) پشتیبانی می‌کند
• عملکرد بالایی برای استخراج CPU دارد
• میتونه به‌صورت stealth و پنهان کار کند

چطور جلوی این حمله گرفته شده؟

قسمت اصلی داستان اینه که چطور سرور را پس از کشف compromise (نفوذ) پاکسازی، تحلیل، و سخت‌سازی کنید تا از تکرار حمله جلوگیری بشه — از مهار فوری تا پیشگیری بلندمدت:

فاز اول مهار فوری فرایندهای مخرب هست . با دستور kill پروسه xmrig از کار انداخته شد. اینجا از سیگنال SIGKILL (-9) استفاده میشه چون میذاره پروسه قبل از بسته شدن خودش را مخفی کنه یا دوباره اجرا بشه. در مرحله بعد توقف و غیرفعال‌سازی سرویس ماینر با دستور ystemctl انجام میشه. در فاز بعدی پاکسازی بدافزار از سرور انجام میشه. در ابتدا باید c3pool_miner.service بطور کلی حذف و بعد کل دایرکتوری malware حذف بشه. با این دستور میشه کل سرور رو با نام این باینری سرچ کرد برای پیدا کردن فایل های مخرب دیگه:

sudo find / -name "*xmrig*" -type f 2>/dev/null

در فاز بعدی باید اتصالات فعال به شبکه چک بشه (اتصال به mining pools ) و اتصال ها به استخر مسدود بشه. همچنین یه لاگ گرفته شده از احراز هویت های غیرمجاز به سرور. درخواست‌های HTTP غیر‌عادی، مخصوصاً آن‌هایی که ممکن است exploit را trigger کرده باشن هم چک شدن.

sudo iptables -A OUTPUT -d pool.hashvault.pro -j DROP

در مرحله بعد dependency های آسیب پذیر شناسایی و اپدیت شدن و در آخر سرور بطور کامل بروزرسانی شده

sudo apt-get update && sudo apt-get upgrade -y

میتونید بطور کامل تر تجربه این نفوذ رو در وبلاگ آقای فرج پور بخونید.

نکات مهم جلوگیری از حملات مشابه

• غیرفعال‌کردن login با root، استفاده از key-based authentication و تغییر پورت پیش‌فرض.
• نصب ابزارهایی مثل fail2ban, rkhunter, aide برای پایش بهتر سیستم.
• فعال‌کردن UFW برای محدود کردن ترافیک ورودی/خروجی.

نکات مهم در دیپلویمنت وب اپ ها

اول اینکه اپلیکیشن وب هرگز نباید دستور سیستم اجرا کند یا به filesystem حساس دسترسی داشته باشد. دوم اینکه برای وب اپ باید یوزر اختصاصی اپ ایجاد بشه بدون دسترسی به shell و home و دیپلویمنت هم باید با همین یوزر انجام بشه

useradd -r -s /usr/sbin/nologin webapp

اپ نباید به /root یا /etc یا /usr/bin و حتی /var/log دسترسی داشته باشه. اپ نباید بتونه به اینترنت آزاد وصل بشه! ( محدودسازی با استفاده از فایروال به عنوان مثال:

ufw default deny outgoing
ufw allow out to 10.0.0.0/8

سکرت های داخل اپ اصلا نباید هارد کد بشن یا از فایل بخونه فقط باید در .env تعریف بشه و دسترسی read accessفقط داشته باشه. مورد بعدی استفاده از AppArmor / SELinux هست که جلوی execution ، write در etc یا network raw رو میگیره. در صورت امکان اپ در داخل داکر دیپلوی بشه که اگر exploit شد داخل container زندانی بمونه. در انتها حتما با یک متخصص شبکه اپ رو تست نفوذ بگیرید ( تست هایی مثل Command Injection – File upload(execution) – SSRF(metadata) )

اگه در حوزه امنیت فعالیت دارید

اگر در حوزه امنیت سایبری فعالیت میکنین، write-up‌ها و گزارش‌های فنی مرتبط با این آسیب‌پذیری‌ها یکی از بهترین راه‌ها برای درک سناریوهای واقعی حمله هست. حتما بخونیدشون. این گزارش‌ها معمولاً زنجیره‌ی کامل حمله (Attack Chain) از Initial Access تا Privilege Escalation و Persistence را عملی توضیح میدن. میتونید این تحلیل‌ها را در وب‌سایت‌هایی مثل HackerOne, GitHub Security Advisories, Exploit-DB, Packet Storm و وبلاگ‌های فنی پژوهشگران امنیتی پیدا کنین. همچنین دنبال‌کردن تجربه‌ها و تحلیل‌های افراد فعال در حوزه امنیت در توییتر (X)، لینکدین و مدیوم کمک میکنه با ترندهای روز، روش‌های جدید سوءاستفاده، اشتباهات رایج تیم‌های فنی و راهکارهای واقعی دفاعی آشنا بشید؛ چیزهایی که معمولاً در مستندات رسمی یا CVEها به‌تنهایی دیده نمیشن. موفق باشید love