رفتن به محتوا
triplem.dev
بلاگNext.js

انتشار امنیتی سپتامبر ۲۰۲۶ در Next.js: چه چیزی را باید وصله کنید و چه کسانی در معرض خطرند

۶ دقیقه مطالعه
Next.js
security

در ده روز گذشته دو اطلاعیه امنیتی از تیم Next.js منتشر شد. به‌روزرسانی خارج از برنامه ۲۲ سپتامبر یک مشکل بحرانی در وابستگی بالادستی را رفع کرد. انتشار امنیتی سپتامبر ۲۰۲۶ که امروز آمد، دسته برنامه‌ریزی‌شده‌ی هفت رفع آسیب‌پذیری است. نسخه‌های وصله‌شده‌ی فعلی 16.3.8 (Active LTS) و 15.5.27 (Maintenance LTS) هستند.

bash
npm install next@16.3.8   # for 16.3
npm install next@15.5.27  # for 15.5

بیشتر این مشکلات به یک قابلیت یا نوع میزبانی خاص وابسته‌اند؛ پس پرسش مفید این است که کدام‌یک شامل حال شما می‌شود.

رفع خارج از برنامه: ImageResponse روی Node.js

در ۲۲ سپتامبر نسخه‌های 16.3.6 و 15.5.26 منتشر شدند. این نسخه‌ها وابستگی‌های بالادستی، از جمله Satori، را ارتقا می‌دهند تا یک مشکل اجرای کد از راه دور (RCE) با شدت بحرانی بسته شود (advisory GHSA-vcvr-r3jv-pc5j).

  • پیاده‌سازی Node.js در ImageResponse از next/og را تحت تأثیر قرار می‌دهد.
  • نسخه‌های >=16.2.0 <16.3.6 آسیب‌پذیرند.
  • escape نادرست در خروجی SVG که Satori تولید می‌کند، در شرایط خاص و به‌دلیل آسیب‌پذیری در وابستگی‌های دیگر، می‌تواند به RCE برسد.
  • پیاده‌سازی Edge در ImageResponse تحت تأثیر نیست.
  • نسخه 15.5.26 سخت‌سازی مرتبط دارد، اما خود RCE روی 15.x اثر ندارد.

اگر تصاویر OG را در یک route handler روی Node.js تولید می‌کنید، این اولویت اول شماست. رفتن به 16.3.8 یا 15.5.27 آن را پوشش می‌دهد، چون هر دو از نسخه‌های رفع‌شده جدیدترند.

دسته‌ی سپتامبر، بر اساس میزان مواجهه

طبق پست انتشار، این دسته شامل یک مورد با شدت بالا، پنج مورد متوسط و یک مورد کم است. گروه‌بندی بر اساس پیش‌شرط لازم، تشخیص سریع را ممکن می‌کند.

از next/image با تصاویر راه‌دور استفاده می‌کنید

SSRF در بهینه‌سازی تصویر (بالا، CVE-2026-94483). یک URL تحت کنترل مهاجم که در فهرست مجاز باشد، هنگام بهینه‌سازی تصویر می‌تواند به server-side request forgery منجر شود، مثلاً به سمت بازه‌های IP خصوصی. پست می‌گوید اگر images.remotePatterns را پیکربندی نکرده باشید، تحت تأثیر نیستید.

ts
// next.config.ts — this is the setting that determines exposure
const config = {
    images: {
        remotePatterns: [{ protocol: "https", hostname: "cdn.example.com" }],
    },
};
export default config;

در اینجا همین فهرست مجاز است که شما را آسیب‌پذیر می‌کند، پس آن را بازبینی کنید. هر ورودی‌ای که به میزبانی اشاره کند که کاربران می‌توانند روی محتوایش اثر بگذارند یا به چیزی داخلی resolve شود، حتی بعد از وصله هم نگاه دوباره می‌خواهد.

Pages Router را با SSG یا ISR خودمیزبان اجرا می‌کنید

دو مشکل cache poisoning با شدت متوسط:

  • CVE-2026-94543: ورودی کش یک صفحه می‌تواند با محتوای مسیری دیگر جایگزین شود و هر بازدیدکننده تا زمان revalidate محتوای اشتباه می‌گیرد. این مورد برای برنامه‌های Pages Router خودمیزبان با SSG/ISR است. پست می‌گوید استقرار روی Vercel تحت تأثیر نیست.
  • CVE-2026-94484: ترکیب یک صفحه‌ی catch-all در سطح ریشه با مسیرهای SSG یا ISR اجازه می‌دهد یک درخواست دست‌ساز و بدون احراز هویت کش پاسخ مشترک را مسموم کند؛ نتیجه می‌تواند جایگزینی محتوا بین کاربران و اختلال سرویس ماندگار باشد.

مورد دوم به شکل مسیرها مربوط است، نه میزبانی: دنبال catch-all سطح ریشه مثل pages/[...slug].tsx در کنار مسیرهای تولیدشده‌ی ایستا بگردید.

از Cache Components یا use cache استفاده می‌کنید

دو مشکل با شدت متوسط، هر دو در مدل کش جدیدتر:

  • use cache تودرتو و root params (GHSA-h694-7cp9-m8p3). وقتی Cache Components روشن است، تابع 'use cache' که تابع 'use cache' دیگری را صدا می‌زند و آن یک root param می‌خواند، ممکن است کلید اشتباه بگیرد. کلید تابع بیرونی root param را ندارد، پس محتوای ساخته‌شده برای یک مقدار می‌تواند برای مقدار دیگر سرو شود. پست تصریح می‌کند مقادیر نشت‌کرده قابل کنترل توسط مهاجم نیستند.
  • نشت Draft Mode (CVE-2026-94544). پرشدن‌های در حال انتظار use cache بین درخواست‌هایی با کلید یکسان به اشتراک گذاشته می‌شود، بدون آنکه Draft Mode از درخواست عادی تفکیک شود. یک درخواست عادی که با درخواست پیش‌نمایش یک ویراستار هم‌پوشانی داشته باشد، می‌تواند بدون احراز هویت محتوای منتشرنشده را بگیرد. اگر آن درخواست صفحه را prerender کند، محتوای پیش‌نویس می‌تواند ذخیره و تا revalidate بعدی به بازدیدکنندگان بعدی سرو شود. اگر Cache Components (یا experimental.useCache) را فعال کرده‌اید و پیش‌نمایش‌های Draft Mode دارید که توابع کش‌شده‌شان محتوای وابسته به پیش‌نویس برمی‌گردانند، تحت تأثیرید.

برای سایت‌های متکی بر CMS، مورد Draft Mode واقع‌بینانه‌ترین ریسک تولیدی این دسته است. محرکش هم‌پوشانی زمانی بین پیش‌نمایش ویراستار و درخواست عمومی است؛ باگی که در تست هرگز دیده نمی‌شود.

با webpack بیلد می‌کنید و از metadata image route استفاده می‌کنید

CVE-2026-94485 (متوسط). در برنامه‌های App Router که با webpack بیلد می‌شوند، routeهای opengraph-image و twitter-image گزینه‌ی dynamicParams را نادیده می‌گیرند. کسی می‌تواند URL تصویر متادیتا را برای segmentهای داینامیکی که عمداً از generateStaticParams() کنار گذاشته‌اید درخواست کند. بیلدهای Turbopack تحت تأثیر نیستند.

ts
// app/posts/[slug]/page.tsx
export const dynamicParams = false; // intended to 404 unknown slugs

export function generateStaticParams() {
    return [{ slug: "public-post" }];
}
// Before the fix (webpack only), opengraph-image for an unlisted slug could still respond.

وقتی slugهای فهرست‌نشده دلیل دارند، مثلاً پست‌های منتشرنشده‌ای که عنوانشان در تصویر OG تولیدی می‌آید، این مورد اهمیت پیدا می‌کند.

next dev اجرا می‌کنید

افشای اطلاعات در endpoint مربوط به MCP (کم، CVE-2026-94486). سرور توسعه یک endpoint از Model Context Protocol ارائه می‌دهد که بررسی نمی‌کند درخواست از کدام وب‌سایت آمده است. یک صفحه‌ی مخرب که توسعه‌دهنده باز می‌کند می‌تواند مسیر پروژه روی دیسک، تکه‌کدهای گزارش خطا، فهرست routeها و لاگ‌های توسعه را بخواند. فقط next dev تحت تأثیر است؛ محیط production این endpoint را سرو نمی‌کند.

شدت پایین است، اما مدل تهدید قابل توجه است: سطح حمله مرورگر شماست، نه سرور. هر تبی که هنگام اجرای dev server باز باشد می‌تواند localhost را کاوش کند. همین استدلال برای ابزارهای توسعه‌ی دیگری که endpoint محلی ارائه می‌دهند، از جمله ابزارهای توسعه با کمک هوش مصنوعی، صادق است.

نکات عملی ارتقا

  1. اول ارتقا، بعد triage. هر دو شاخه نسخه‌ی رفع‌شده دارند و پست تغییر ناسازگاری فهرست نکرده، پس patch bump ارزان‌ترین مسیر است. در هیچ‌یک از دو پست یادداشت مهاجرت ندیدم؛ lockfile را بررسی و CI معمول را قبل از انتشار اجرا کنید.
  2. اگر در معرض بودید، بعد از وصله کش را پاک کنید. مشکلات cache poisoning ورودی‌های بد را تا revalidate نگه می‌دارند. متن advisory می‌گوید صفحات آسیب‌دیده تا آن زمان محتوای اشتباه سرو می‌کنند؛ پس اگر خودمیزبان هستید و نسخه‌ی آسیب‌پذیر اجرا کرده‌اید، کش ISR/داده را purge کنید و منتظر نمانید.
  3. هر دو شاخه را بررسی کنید. اگر روی 15.x هستید هدف 15.5.27 است، نه 16.x. اگر روی 16.x قدیمی‌تر هستید، به 16.3.8 بروید.
  4. «تحت تأثیر نیستم» را دائمی فرض نکنید. چند مورد به یک تنظیم وابسته‌اند (remotePatterns، webpack در برابر Turbopack، Cache Components). اگر هنوز روی نسخه‌ی قدیمی باشید، تغییر بعدی پیکربندی می‌تواند شما را به گروه آسیب‌پذیر ببرد.

مصالحه‌ها و نکات احتیاطی

  • من پست انتشار را خلاصه می‌کنم، نه advisoryهای GitHub را؛ پیش از قضاوت درباره‌ی ایمن بودن یک استقرار قدیمی‌تر، بازه‌ی دقیق نسخه‌های آسیب‌پذیر را در صفحات GHSA لینک‌شده ببینید. پست انتشار فقط برای مشکل ImageResponse بازه‌ی نسخه می‌دهد.
  • پست می‌گوید رفع یک مشکل بحرانی و یک مشکل با شدت بالا به‌دلیل تأخیر وابستگی‌های بالادستی عقب افتاده بود. بخش impact آن یک مورد با شدت بالا و هیچ مورد بحرانی فهرست نمی‌کند؛ برای هر خبر بعدی کانال‌های تیم را دنبال کنید.
  • دست‌کم برای مشکل cache poisoning در Pages Router، که پست صریحاً استقرار Vercel را مستثنا می‌کند، بار مواجهه بیشتر روی خودمیزبان‌هاست تا برنامه‌های میزبانی‌شده روی Vercel.

منابع