آپدیت امنیتی Next.js ژوئیه 2026؛ 9 آسیب پذیری و نسخه امن

اگر پروژه Next.js شما هنوز روی نسخه ای قبل از 15.5.21 یا 16.2.11 است، این انتشار امنیتی را نباید مثل یک Patch معمولی در Backlog رها کنید. در این راهنما مشخص می کنیم چه نسخه ای مقصد ارتقاست، کدام الگوهای معماری ریسک را بیشتر می کنند و چگونه بدون ایجاد Regression در Server Actions، Middleware، Rewriteها، Cache و Image Optimization ارتقا را به Production برسانید.

خلاصه نسخه های امن و تصمیم سریع

اولین تصمیم باید از روی نسخه نصب شده گرفته شود، نه از روی این که تصور می کنید قابلیت آسیب پذیر را استفاده نمی کنید. انتشار رسمی Next.js صریحاً دو نسخه 16.2.11 و 15.5.21 را به عنوان مقصد معرفی می کند. اگر روی 16.x هستید، حرکت به 16.2.11 کم ریسک ترین مسیر Patch است. اگر هنوز روی 15.x هستید، 15.5.21 خط Maintenance LTS را پوشش می دهد. پروژه های قدیمی تر 13 و 14 باید برنامه ارتقای Major/Minor جدی داشته باشند؛ تکیه بر این که «فعلاً Rewrite پویا نداریم» جای Patch را نمی گیرد، چون الگوی کد و مسیر Deploy در طول عمر سرویس تغییر می کند.

نکته عملی این است که «نسخه Package» تنها نقطه کنترل نیست. اگر Image یا Container قدیمی همچنان در Registry، Preview Environment یا Rollback Slot شما قابل اجرا باشد، نسخه آسیب پذیر عملاً هنوز بخشی از سطح حمله است. بنابراین Definition of Done این Patch باید شامل Build artifact، کانتینر، Preview Deploy، Lambda/Function bundle و هر Rollback image قابل فعال سازی باشد.

چه چیزی در این انتشار امنیتی مهم است؟

ارزش این بسته در تعداد CVEها نیست؛ در پراکندگی سطح حمله است. مجموعه رسمی چهار High و پنج Medium را پوشش می دهد و نشان می دهد لایه های Routing، Server Actions، Cache و پردازش ورودی در یک Framework Full-stack چگونه به هم متصل اند. یکی از نمونه های مهم، SSRF در Rewrite یا Redirectهایی است که Host مقصد را از ورودی کاربر می سازند. Advisory رسمی توضیح می دهد که در الگوهای آسیب پذیر، مهاجم می تواند مقصد را به Host دلخواه تغییر دهد و در حالت Rewrite باعث شود سرور Next.js به مقصد داخلی یا خارجی درخواست بزند. این دقیقاً همان جایی است که یک قابلیت ظاهراً ساده Routing می تواند به Cloud Metadata یا سرویس داخلی برسد.

جزئیات این مورد در Advisory رسمی SSRF مربوط به Rewriteها آمده است. نسخه های آسیب پذیر این Advisory از 12.0.0 تا قبل از 15.5.21 و از 16.0.0 تا قبل از 16.2.11 را شامل می شود. Workaround رسمی در صورت ناتوانی در Patch، حذف Hostname پویا از ورودی کنترل شده توسط کاربر یا محدودکردن مقدار به کاراکترهای امن Hostname است. این Workaround باید فقط پل موقت تا ارتقا باشد، نه راهکار دائمی.

نمونه مهم دیگر افشای شناسه های داخلی Server Function در App Router است. در پروژه هایی که Server Actions یا Cache Components دارند، نباید تصور کرد چون صفحه نیازمند Login است، شناسه یا Endpoint داخلی نیز خودبه خود Secret محسوب می شود. معماری امن باید Authorization را در نقطه اجرای Action یا منطق Domain دوباره اعمال کند. شناسه Action، نام فایل، Route یا مخفی بودن Client Artifact نباید مرز امنیتی باشد. این اصل حتی بعد از Patch هم ارزش معماری دارد.

نمونه الگوی پرریسک در Rewrite

module.exports = {
  async rewrites() {
    return [{
      source: '/:tenant',
      destination: 'https://:tenant.api.example.com',
    }]
  },
}

اگر مقدار tenant مستقیماً از Path وارد Host مقصد شود، Validation ضعیف می تواند فضای Hostname را از محدوده مورد انتظار خارج کند. راه بهتر این است که Tenant را ابتدا به یک شناسه داخلی معتبر نگاشت کنید و مقصد را از Allowlist بسازید؛ یعنی داده کاربر فقط یک Key باشد، نه بخشی آزاد از URL نهایی. این تغییر علاوه بر CVE فعلی، خطاهای SSRF آینده و اشتباهات Multi-tenant Routing را هم کاهش می دهد.

چه پروژه هایی بیشتر در معرض ریسک اند؟

ریسک واقعی به Feature Usage و مدل Hosting بستگی دارد. Self-hostedها، Custom Serverها، پروژه هایی که Rewrite خارجی دارند، اپ هایی با Server Actions و سامانه هایی که Authorization را عمدتاً در Middleware متمرکز کرده اند باید زودتر بررسی شوند. اما «Vercel-hosted هستیم» یا «این Feature را نداریم» نباید نتیجه بررسی را به صفر تقلیل دهد. انتشار امنیتی یک بسته مشترک است و بعضی مشکلات می توانند فقط در مسیرهای خاص ظاهر شوند. هدف Inventory این است که قبل از ارتقا بدانید چه Regressionهایی را باید تست کنید، نه این که بهانه ای برای عقب انداختن Patch پیدا کنید.

• فایل `next.config.*` را برای `rewrites()`، `redirects()`، `images.remotePatterns` و تنظیمات i18n بررسی کنید.
• استفاده از `use server`، Server Actions، `use cache` و Cache Components را با جست وجوی Repository فهرست کنید.
• مشخص کنید Authorization در Middleware/Proxy است یا در Route/Action نیز کنترل می شود.
• Deployهای Self-hosted، Container، Serverless و Preview را جداگانه Inventory کنید.
• هر سرویس داخلی که Origin Next.js اجازه Egress به آن دارد در Threat Model SSRF وارد کنید.

در سازمان های بزرگ، این Inventory را به یک Query قابل تکرار تبدیل کنید. برای مثال SBOM یا lockfileهای همه Repositoryها را روی نسخه `next` جست وجو کنید، سپس خروجی را با Exposure Context ترکیب کنید. تیم Security به فهرست «کدام Repo آسیب پذیر است» نیاز دارد؛ تیم Platform علاوه بر آن باید بداند کدام Deploy هنوز روی artifact قدیمی است. این دو فهرست معمولاً یکسان نیستند.

نقشه ارتقای امن بدون قطع سرویس

ارتقای Framework امنیتی باید کوچک و قابل بازگشت بماند. از Upgrade همزمان چند Dependency بزرگ خودداری کنید. ابتدا Branch اختصاصی بسازید، فقط Next.js و Dependencyهای الزامی آن را به نسخه امن ببرید، lockfile را Commit کنید و Build Production بگیرید. بعد مسیرهای SSR، RSC، Server Actions، API Route، Middleware و Image را Smoke Test کنید. اگر Monorepo دارید، اطمینان بگیرید Packageهای داخلی نسخه Next.js متفاوت و حل شده توسط Hoisting ندارند؛ نسخه Runtime در Artifact نهایی مهم است، نه فقط نسخه ای که در package.json ریشه می بینید.

npm install next@16.2.11
npm ls next
npm run build
npm test

برای شاخه 15، به جای دستور بالا از `next@15.5.21` استفاده کنید. `npm ls next` یا ابزار متناظر pnpm/yarn کمک می کند نسخه های چندگانه پنهان شوند. سپس image تازه را با Tag جدید بسازید و در Canary درصد کوچکی از Traffic را عبور دهید. اگر پروژه Cache حساس دارد، Warm-up و رفتار Revalidation را زیر بار واقعی بررسی کنید. Rollback باید به Artifact امن قبلی برگردد؛ Rollback به نسخه آسیب پذیر صرفاً بازیابی سرویس نیست و باید به عنوان پذیرش موقت ریسک ثبت شود.

1. نسخه فعلی و همه Artifactهای قابل اجرا را ثبت کنید.
2. Dependency را فقط تا نسخه Patch امن ارتقا دهید.
3. Build Production و تست های Routing/Action/Cache را اجرا کنید.
4. Canary را با Logging و Error Rate روشن منتشر کنید.
5. Preview Deployهای قدیمی و Branch Deployهای عمومی را حذف یا Rebuild کنید.
6. پس از تثبیت، نسخه آسیب پذیر را از Rollback policy خارج کنید.

بعد از ارتقا دقیقاً چه چیزی را تست کنیم؟

تست موفق `next build` کافی نیست. در SSRF، رفتار مهم در Runtime و روی Requestهای خاص دیده می شود. برای Rewriteها یک Matrix از Tenant معتبر، Tenant نامعتبر، Host Header غیرمنتظره و URL Encoding بسازید و انتظار داشته باشید مقصد خارج Allowlist هرگز فراخوانی نشود. برای Server Actions، دسترسی Anonymous و User با Role اشتباه را تست کنید. برای Cache، پاسخ های حساس با Bodyهای متفاوت نباید بین درخواست ها مخلوط شوند. برای Image Optimization نیز URLهای Remote مجاز و نامجاز و SVGهای ورودی را زیر محدودیت CPU/Timeout بررسی کنید.

Observability را قبل از Deploy تنظیم کنید: افزایش 5xx، Timeout، CPU، Memory، Egress به مقصدهای ناشناس، Cache hit غیرعادی و درخواست به Metadata Endpoint باید Alert داشته باشد. در Cloud، Egress log یا Firewall log اغلب بهترین نشانه SSRF است. در App، log کردن Raw Secret یا Body برای Debug ممنوع است؛ به جای آن شناسه Request، Route، Destination Host طبقه بندی شده و نتیجه Validation را ثبت کنید. این داده هم برای Verification و هم برای Incident Response مفید است.

تکلیف پروژه های Next.js 13 و 14 چیست؟

اگر اپ شما روی 13 یا 14 است، این انتشار یک علامت عملی برای پایان دادن به بدهی ارتقاست. راه درست این نیست که Patchهای پراکنده را دستی Backport کنید، مگر این که تیمی با توان نگهداری Fork امنیتی داشته باشید. Framework full-stack مجموعه ای از رفتارهای Routing، Compiler، React و Runtime را هماهنگ می کند؛ Backport تک Commit می تواند Patch ظاهری بسازد اما Assurance پشتیبانی رسمی را ندارد. برای سرویس حیاتی، یک شاخه مهاجرت به 15.5.21 یا ترجیحاً 16.2.11 با تست Contract و Snapshot ایجاد کنید.

مهاجرت را به دو مرحله تقسیم کنید: اول Compatibility، بعد Modernization. در مرحله اول هدف فقط رسیدن به نسخه پشتیبانی شده با حداقل تغییر Behavior است. تغییرات معماری، Cache جدید، Turbopack یا Refactor Router را به Sprint بعد ببرید. این جداسازی زمان تشخیص Regression را کوتاه می کند و اگر خطا رخ دهد، علت بین Patch امنیتی و بازطراحی محصول گم نمی شود. برای سازمانی که چند ده Next.js App دارد، این الگو تفاوت بین یک Campaign قابل مدیریت و ماه ها Migration آشفته است.

اگر احتمال می دهیم نسخه آسیب پذیر Exploit شده چه کنیم؟

بازه Exposure را از اولین Deploy نسخه آسیب پذیر تا Deploy نسخه امن تعیین کنید. Access Log، Reverse Proxy، WAF، Egress، Cloud Metadata Access و Audit Log سرویس های داخلی را همبسته کنید. اگر SSRF می توانسته به Credential موقت دسترسی پیدا کند، Rotate کردن Token یا Role Session را طبق مدل Cloud انجام دهید. اگر Authorization روی Middleware بوده، دسترسی به Resource حساس را با User/Request ID بازبینی کنید. سپس Artifactهای قدیمی و Preview Deployها را ببندید تا مهاجم نتواند از یک Endpoint فراموش شده دوباره وارد شود.

پرسش های متداول

نسخه امن Next.js بعد از انتشار ژوئیه 2026 چیست؟

برای شاخه Active LTS نسخه 16.2.11 و برای Maintenance LTS نسخه 15.5.21 مقصد اعلام شده در انتشار رسمی هستند.

آیا فقط Self-hostedها باید آپدیت کنند؟

خیر. میزان اثر هر CVE به Hosting و Feature Usage بستگی دارد، اما توصیه عملی این است که همه پروژه های روی نسخه های آسیب پذیر به نسخه Patch شده ارتقا دهند.

اگر روی Next.js 14 باشیم چه کنیم؟

به جای ماندن روی شاخه قدیمی، برنامه ارتقا به نسخه پشتیبانی شده بسازید و Compatibility را از Refactorهای معماری جدا کنید.

آیا Middleware برای Authorization کافی است؟

بهتر است کنترل دسترسی در Route، Server Action یا Domain هم enforce شود؛ Middleware نباید تنها مرز امنیتی برای عملیات حساس باشد.

بعد از Patch باید Deploy Previewها را هم بررسی کنیم؟

بله. هر Preview یا Branch Deploy عمومی که Artifact قدیمی دارد می تواند سطح حمله مستقل ایجاد کند و باید حذف یا Rebuild شود.

منابع و جمع بندی

مرجع نسخه ها و تعداد آسیب پذیری ها صفحه رسمی اخبار Next.js است. برای نمونه فنی SSRF از Advisory رسمی GHSA-p9j2-gv94-2wf4 و برای افشای Server Function از Advisory رسمی GHSA-955p-x3mx-jcvp استفاده شده است. نتیجه اجرایی ساده است: نسخه را به Patch امن برسانید، Artifactهای قدیمی را از دسترس خارج کنید و Verification را روی مسیرهای Runtime انجام دهید، نه فقط روی Build.

چک لیست اجرایی تیم

• Owner مشخص برای Patch و یک Deadline کوتاه تعیین کنید؛ Security Patch بدون Owner در صف کارهای عادی گم می شود.
• نسخه Next.js را در package manager، lockfile، container image و SBOM تطبیق دهید تا اختلاف محیط توسعه و Production آشکار شود.
• تمام `rewrites` و `redirects` خارجی را از نظر Host پویا و داده کنترل شده توسط کاربر بازبینی کنید.
• برای Server Actions کنترل Authorization در خود Action یا Service Layer را تست کنید و به مخفی بودن شناسه Action تکیه نکنید.
• قواعد Egress را طوری محدود کنید که Web App اصولاً نتواند به Metadata و شبکه های حساس غیرضروری دسترسی داشته باشد.
• Canary را با Error Rate، Latency، CPU و Memory مقایسه کنید و فقط نبود Exception را معیار سلامت ندانید.
• پیش از حذف نسخه قبلی، Rollback امن و آزمایش شده بسازید؛ Rollback نباید به نسخه دارای CVE بازگردد.
• پس از انتشار، Dependency Scanner را دوباره اجرا کنید تا False Negative ناشی از Cache یا SBOM قدیمی باقی نماند.
• Preview URLها، Staging عمومی و Branch Deployهایی را که دیگر Owner ندارند از DNS یا Provider حذف کنید.
• نتیجه Patch، تست ها و Exposure Assessment را در Ticket امنیتی ثبت کنید تا Audit بعدی قابل اثبات باشد.