از قطعی AWS تا React2Shell؛ ۲۰۲۵ سال انفجار آسیب‌پذیری‌ها

اختلال بزرگ AWS در پاییز ۲۰۲۵ که به خطای DNS گره خورد، و همچنین مجموعه آسیب‌پذیری‌های React Server Components و Next.js (از React2Shell تا DoS و افشای کد) نشان داد «پایداری سرویس» دیگر فقط موضوع سرور و اپلیکیشن نیست؛ لایه‌های زیرساختی مثل DNS و پروتکل‌های میانی، می‌توانند مانیتورینگ، گزارش رخداد و حتی دسترسی کاربر به سرویس را یکجا از کار بیندازند. هم‌زمان، حفره‌های مهم در فریم‌ورک‌هایی مثل Django و Frappe نیز دوباره نقش SQL Injection و خطاهای اعتبارسنجی را در تهدیدات روز برجسته کردند.

سال ۲۰۲۵ برای امنیت سایبری، سال «شوک‌های هم‌زمان» بود: از یک‌سو قطعی‌ها و اختلال‌های بزرگ در سرویس‌های ابری، و از سوی دیگر، موج سوءاستفاده سریع از آسیب‌پذیری‌های بحرانی که فاصله بین «افشا» تا «Exploit/کدمخرب در عمل» را به چند ساعت کاهش داد.

۱) وقتی اینترنت می‌لرزد: چرا DNS حیاتی‌تر از چیزی است که تصور می‌شود

در اختلال گسترده AWS که گزارش‌های رسانه‌ای آن را به خطای مرتبط با DNS گره زدند، مشکل فقط «از کار افتادن چند سرویس» نبود؛ در چنین سناریوهایی اگر Resolution مختل شود، سرویس‌ها حتی ممکن است نتوانند به Endpointهای مانیتورینگ و Incident Reporting خودشان هم برسند. یعنی حلقه بازخوردِ تشخیص و اعلام خرابی هم می‌شکند و شدت اختلال از نگاه کاربر و تیم عملیات چند برابر دیده می‌شود. 

DNS فقط یک سرویس «نام به IP» نیست؛ بخشی از اعتماد دیجیتال، دسترس‌پذیری، و حتی کارکرد درست سامانه‌های امنیتی و گواهی‌هاست.

۲) دو لایه متفاوت، دو نقطه شکست: Recursive در برابر Authoritative

DNS در عمل دو نقش مکمل دارد:

• Recursive Resolver که به نمایندگی از کاربر/شبکه شما جست‌وجو می‌کند (عموماً ISP، شبکه سازمان، یا ارائه‌دهندگان DNS).
• Authoritative DNS که «پاسخ قطعی» رکوردهای دامنه را نگه می‌دارد.

اگر Authoritative سالم باشد ولی Recursive دچار اختلال شود، کاربر باز هم به مقصد نمی‌رسد. این تفاوت در برنامه‌ریزی تاب‌آوری مهم است: داشتن HA در Authoritative کافی نیست؛ برای Resolver هم باید سناریوی Redundancy داشته باشید.

۳) React2Shell و موج Next.js: چرا زنجیره تأمین وب، میدان مین شد

در اواخر ۲۰۲۵، آسیب‌پذیری‌های React Server Components (RSC) به یکی از حساس‌ترین پرونده‌های سال تبدیل شد؛ چون هم «سطح استفاده» بالا است، هم «سطح دسترسی» در سمت سرور خطرناک‌تر از باگ‌های صرفاً کلاینتی است.

۳.۱) CVE-2025-66478 (Downstream در Next.js) و الزام به Patch

در بولتن امنیتی Next.js اعلام شد که یک نقص بحرانی در پروتکل RSC می‌تواند در شرایط مشخص به Remote Code Execution در محیط‌های Patchنشده منجر شود و برای آن «Workaround» قابل اتکا وجود ندارد؛ راهکار، ارتقا به نسخه‌های Patch‌شده هر شاخه است. همچنین ابزار npx fix-react2shell-next برای بررسی نسخه‌ها و اعمال ارتقای توصیه‌شده ارائه شد. 

۳.۲) آپدیت ۱۱ دسامبر ۲۰۲۵: دو نقص جدید (بدون RCE) اما پرریسک

Next.js در ۱۱ دسامبر ۲۰۲۵ اعلام کرد که هنگام بررسی Patchها، دو آسیب‌پذیری دیگر در RSC شناسایی شده است:

• DoS با شدت بالا که با یک درخواست HTTP دست‌کاری‌شده می‌تواند سرور را وارد حلقه بی‌نهایت کند. نکته مهم: «Fix اولیه کامل نبود» و Fix کامل با CVE-2025-67779 ارائه شد؛ یعنی اگر قبلاً فقط به نسخه‌های اولیه ارتقا داده‌اید، باید دوباره به نسخه‌های Patch نهایی ارتقا دهید. 
• افشای کد (Source Code Exposure) با شدت متوسط که می‌تواند خروجی کامپایل‌شده Server Functionهای دیگر را برگرداند و در صورت Inline شدن مقادیر حساس در کد، ریسک افشای منطق/اطلاعات را بالا ببرد. 

این پرونده نشان داد «Patch کردن» فقط یک بار انجام نمی‌شود؛ گاهی Patch اولیه ناقص است و چرخه Patch باید با رصد بولتن‌های تکمیلی ادامه پیدا کند.

۴) SQL Injection هنوز زنده است: Django و Frappe

در کنار RSC، حفره‌های کلاسیک‌تر هم در ۲۰۲۵ فعال بودند؛ مخصوصاً در لایه ORM و Endpointها.

۴.۱) Django: تزریق SQL از مسیر alias ستون‌ها

Django اعلام کرد در شاخه‌های مشخصی، کلاس FilteredRelation می‌تواند از مسیر alias ستون‌ها و در سناریوی استفاده از QuerySet.annotate یا QuerySet.alias روی PostgreSQL، در معرض SQL Injection قرار گیرد (CWE-89) و نسخه‌های امن برای شاخه‌ها منتشر شد. 

۴.۲) Frappe: SQL Injection خطامحور به‌دلیل اعتبارسنجی ناکافی

در advisory امنیتی Frappe نیز اشاره شده پیش از نسخه‌های اصلاحی (۱۵.۸۶.۰ و ۱۴.۹۹.۲)، یک Endpoint به دلیل اعتبارسنجی ناکافی پارامترها در معرض Error-based SQL Injection بوده و با ارتقا به نسخه‌های اصلاحی، مشکل رفع می‌شود. 

۵) «۲۰ آسیب‌پذیری پرتکرار ۲۰۲۵» یعنی چه برای بازار ایران؟

برای بازار ایران (شرکت نرم‌افزاری، فروشگاه اینترنتی، رسانه‌ها، و سرویس‌های B2B) پیام روشن است:

1. Patch Management باید شتاب‌گرفته و مرحله‌بندی‌شده باشد (به‌خصوص برای اجزای اینترنت‌فیسینگ).
2. DNS Resilience باید جزو طراحی اصلی باشد (Resolver جایگزین، Anycast/Geo، مانیتورینگ مستقل از DNS داخلی).
3. سیاست‌های Secret Management باید سخت‌گیرانه‌تر شود (Secrets داخل کد نگذارید؛ از env/runtime استفاده شود). 
4. کنترل‌های جبرانی (WAF، Rate Limit، IDS/IPS، جداسازی شبکه، Least Privilege) باید هم‌زمان با Patch اجرا شوند، نه بعد از آن.

۶) چک‌لیست اقدام فوری برای مدیران فنی و تیم‌های عملیات

• فهرست سرویس‌های Next.js (App Router/RSC) را استخراج و نسخه‌ها را Audit نمایید؛ سپس فقط بر اساس شاخه، به نسخه‌های Patch‌شده ارتقا دهید. 
• اگر قبلاً روی Fixهای اولیه DoS ارتقا داده‌اید، ارتقای مجدد طبق نسخه‌های نهایی را انجام دهید (پرونده CVE-2025-67779). 
• برای DNS: حداقل دو Resolver (داخلی/خارجی) با Failover تست‌شده داشته باشید و مانیتورینگ را طوری طراحی کنید که در سناریوی اختلال DNS هم «قابل گزارش» بماند. 
• سرویس‌های Django و Frappe را از نظر نسخه و الگوهای استفاده حساس (annotate/alias/endpointهای آسیب‌پذیر) بررسی و Patch نمایید.