نسخه‌های قدیمی‌تر Angular SSR از جمله 21.2.0-rc.1، 21.1.5، 20.3.17 و 19.2.21 پیش از رفع حاوی این نقص بودند و اکنون برای این نسخه‌ها پچ منتشر شده است.

خلاصه فنی
– علت: منطق بازسازی URL داخلی در Angular SSR به صورت مستقیم به هِدرهای HTTP کنترل‌شده توسط کاربر (به ویژه هدرهای خانواده میزبان و X-Forwarded-*) اعتماد می‌کرد و آن‌ها را بدون اعتبارسنجی مناسب برای تعیین مبدا پایه برنامه مصرف می‌نمود. بررسی‌های لازم برای دامنه میزبان، پاک‌سازی مسیر و اعتبارسنجی پورت انجام نمی‌شد.
– دو مسیر بهره‌برداری اصلی: وضوح ضمنی URLهای نسبی و ساخت صریح URLها با استفاده از هدرهای کنترل‌شده توسط کاربر.
– پیامدها در صورت بهره‌برداری موفق: امکان ارسال درخواست‌های داخلی دلخواه از سوی سرور (SSRF) فراهم می‌شود که می‌تواند به دورزدن احراز هویت، بررسی شبکه‌های داخلی و افشای اطلاعات محرمانه منجر شود.

شرایط لازم برای آسیب‌پذیر بودن یک برنامه
– استفاده از Angular SSR (Server-Side Rendering).
– ارسال درخواست‌های داخلی با HttpClient با URLهای نسبی یا ساخت دستی URLها در سرور با استفاده از REQUEST و هدرهای Host / X-Forwarded-* بدون اعتبارسنجی.
– دسترسی مستقیم به سرور برنامه بدون وجود پروکسی جلویی که هدرهای ورودی را پاک‌سازی یا اعتبارسنجی کند (مثلاً تنظیمات نادرست در Cloud، CDN یا Load Balancer).

نسخه‌های دارای پچ
– نسخه‌های حاوی پچ: 21.2.0-rc.1، 21.1.5، 20.3.17 و 19.2.21. توصیه می‌شود به این یا نسخه‌های بعدی به‌روزرسانی کنید.

توصیه‌های عملی برای کاهش خطر و رفع
1. به‌روزرسانی
– اولویت اول: ارتقاء Angular SSR به نسخه‌های وصله‌شده ذکرشده یا نسخه‌های جدیدتر.

2. اگر امکان ارتقاء فوری نیست — راه‌حل موقت
– در فایل سرور اصلی (معمولاً server.ts) میان‌افزاری (middleware) پیاده‌سازی کنید که:
– تنها پورت‌های عددی معتبر و فهرست‌شده را بپذیرد.
– نام‌های میزبان را با whitelist بررسی کند یا الگوهای امن (مثلاً دامنه‌های مشخص) را اعمال نماید.
– هدرهای X-Forwarded-* و Host را قبل از استفاده پاک‌سازی یا اعتبارسنجی کند.
– به صورت کلی از استفاده مستقیم از req.headers برای ساختن URL خودداری کنید.

3. بهترین رویه‌های توسعه
– برای مسیرهای پایه API از متغیرهای قابل‌اعتماد (مانند محیطی / environment variables یا تنظیمات سرور که توسط تیم زیرساخت تعیین شده) استفاده کنید؛ به هدرهای ورودی اعتماد نکنید.
– اگر برنامه نیازمند تشخیص منبع درخواست است، این کار را فقط با فهرست کردن پروکسی‌های قابل‌اعتماد و اعتبارسنجی آن‌ها انجام دهید.
– تست‌های امنیتی (از جمله تست‌های SSRF) را در زنجیره CI/CD خود اضافه کنید.

4. تنظیمات زیرساخت
– پروکسی‌ها، CDNها و Load Balancerها را طوری پیکربندی کنید که هدرهای ورودی حساس را پاک یا بازنویسی کنند مگر اینکه از مبدا آن‌ها اطمینان کامل داشته باشید.
– دسترسی به سرور رندر سمت سرور را تا حد امکان محدود کنید (مثلاً فقط از طریق پروکسی‌های معتبر).

اطلاعات تکمیلی و ردیابی
– CVE-2026-27739 به برخی CWEها مرتبط است و می‌تواند با الگوهای حمله ثبت‌شده در CAPEC تحلیل و دسته‌بندی شود؛ این روابط به تحلیلگران کمک می‌کند تا درک بهتری از شیوه‌های احتمالی سوءاستفاده و کنترل‌های جلوگیری به‌دست آورند.
– محققان و نگهدارندگان امنیتی معمولاً مخازن GitHub را برای یافتن اکسپلویت‌های اثبات مفهوم (PoC) پایش می‌کنند؛ نمونه‌هایی از PoCها و سوءاستفاده‌های عمومی ممکن است در GitHub منتشر شوند که دنبال کردن آن‌ها برای شناسایی ریسک عملی مفید است.
– پوشش خبری و مقالات فنی درباره این آسیب‌پذیری منتشر شده‌اند و همچنین تاریخچه تغییرات مربوط به CVE در دسترس است تا تکامل آلودگی و اصلاحات را پیگیری کنید.
– برای دریافت گزارش‌ها، لینک‌ها و ابزارهای عملی مرتبط با CVE-2026-27739 می‌توانید به صفحات رفرنس امنیتی و منابع مرکزی مانند CVEFeed مراجعه کنید. داشبوردهای CVEFeed را می‌توان برای دریافت اعلان‌ها و گزارش‌های متناسب با نیازهای مانیتورینگ شما سفارشی‌سازی کرد.

چک‌لیست فوری برای تیم‌ها
– آیا پروژه شما از Angular SSR استفاده می‌کند؟ در غیر این صورت احتمالاً آسیب‌پذیری کمتر است.
– آیا در کدهای سرور از HttpClient با URLهای نسبی استفاده شده یا URLها از هدرهای Host / X-Forwarded-* ساخته می‌شوند؟
– آیا پروکسی‌ها و زیرساخت شما هدرهای ورودی را پاک‌سازی یا اعتبارسنجی می‌کنند؟
– اگر پاسخ به هر یک از موارد بالا مثبت است، همین امروز اقدام به اعمال پچ یا اجرای میان‌افزار محافظتی نمایید و تست‌های SSRF را اجرا کنید.

نتیجه‌گیری
CVE-2026-27739 یک SSRF جدی است که ناشی از اعتماد مستقیم به هدرهای کنترل‌شده توسط کاربر در فرآیند بازسازی URL در Angular SSR می‌باشد. به‌روزرسانی به نسخه‌های دارای پچ ساده‌ترین و مطمئن‌ترین راه‌حل است؛ در غیاب امکان ارتقاء فوری، پیاده‌سازی میان‌افزار معتبر و جلوگیری از استفاده از req.headers برای ساخت URL ضروری است. مانیتورینگ مخازن عمومی، اخبار و داشبوردهای CVE به شناسایی اکسپلویت‌های عملی و کاهش خطر کمک خواهد کرد.