CVE-2025-29927 در Next.js: وقتی Middleware می‌تواند امنیت را دور بزند

حتماً تا حالا فکر کرده‌اید Middleware چیست و چرا در وب مهم است؟

Middleware شبیه یک نگهبان در ورودی ساختمان است: هر درخواست (request) قبل از رسیدن به بخش اصلی سایت، باید از آن عبور کند. این نگهبان چک می‌کند آیا شما اجازه دارید وارد شوید یا نه.

حالا تصور کنید همین نگهبان بتواند فریب بخورد! 

این دقیقاً همان چیزی است که CVE-2025-29927 در Next.js انجام می‌دهد: یک هدر کوچک به مهاجم اجازه می‌دهد Middleware را دور بزند و بدون داشتن اجازه، به صفحات محافظت‌شده دسترسی پیدا کند.

توضیح ساده آسیب‌پذیری

فرض کنید شما وارد یک ساختمان اداری می‌شوید و در ورودی، یک نگهبان وجود دارد. این نگهبان از شما کارت شناسایی می‌خواهد تا مطمئن شود فقط افراد مجاز وارد شوند. اگر کارت شما درست باشد، اجازه ورود دارید؛ اگر نه، شما به بیرون هدایت می‌شوید.

در وب، Middleware نقش همین نگهبان را دارد. هر بار که کسی سعی می‌کند به یک صفحه یا مسیر محافظت‌شده برود، Middleware ابتدا بررسی می‌کند:

•  آیا این کاربر لاگین کرده است؟
•  آیا دسترسی کافی دارد؟
•  آیا درخواست از مسیر قانونی آمده است؟

اگر پاسخ «نه» باشد، Middleware کاربر را به صفحه لاگین هدایت می‌کند یا دسترسی را محدود می‌کند.

اما مشکل کجاست؟

در نسخه‌های آسیب‌پذیر Next.js، هدر x-middleware-subrequest شبیه یک برچسب داخلی است که Middleware استفاده می‌کند تا بداند یک درخواست از خودش یا مسیرهای داخلی آمده و از اجرای دوباره جلوگیری کند.

تصور کنید که نگهبان ما در ساختمان، یک کاغذ کوچک دارد که روی آن نوشته شده:

"اگر کسی این برچسب را دارد، فرض می‌کنم او قبلاً چک شده است و اجازه ورود دارد."

اینجاست که مشکل پیش می‌آید: اگر کسی بتواند این برچسب را جعل کند و به خودش بچسباند، نگهبان بدون بررسی کارت شناسایی او را راه می‌دهد. 

در وب، مهاجم می‌تواند با افزودن هدر x-middleware-subrequest با مقدار درست به درخواست، Middleware را فریب دهد و بدون داشتن توکن یا مجوز لازم، وارد صفحات محافظت‌شده شود.

مثال واقعی برای درک بهتر

فرض کنید یک وب‌سایت دارد مسیر /admin را فقط به ادمین‌ها نشان می‌دهد. Middleware سایت این‌طور کار می‌کند:

1. هر درخواستی که به /admin می‌آید را بررسی می‌کند.

2. اگر توکن Authorization نداشته باشد، کاربر را به صفحه ورود می‌فرستد.

3. اگر توکن درست باشد، اجازه دسترسی داده می‌شود.

حالا تصور کنید مهاجم بداند که Middleware به هدر x-middleware-subrequest اعتماد دارد. او می‌تواند درخواست خود را این‌طور بسازد:

با این کار، Middleware فکر می‌کند:

"این درخواست قبلاً بررسی شده، همه چیز اوکی است"

و بدون هیچ چک احراز هویتی، اجازه دسترسی به صفحه /admin داده می‌شود!

چرا این مسئله خطرناک است؟

• حتی بدون داشتن پسورد یا توکن، مهاجم می‌تواند وارد بخش‌های حساس سایت شود.
• هر کاری که کاربران معمولی نباید انجام دهند، حالا امکان‌پذیر است.

مثال عملی کد

فرض کنید Middleware ساده‌ای داریم که فقط کاربران با یک توکن خاص می‌توانند وارد /admin شوند:

توضیح دور زدن Middleware

در حالت عادی، هر کاربر بدون هدر Authorization به صفحه ورود هدایت می‌شود.

اما این نسخه آسیب‌پذیر است به دلیل اعتماد به هدر داخلی x-middleware-subrequest.

اگر در همان درخواست هدر زیر را اضافه کنیم:

Middleware فکر می‌کند:

"این درخواست قبلاً بررسی شده، همه چیز اوکی است"

و چک Authorization نادیده گرفته می‌شود. در نتیجه، درخواست بدون داشتن توکن صحیح به /admin می‌رود و صفحه نمایش داده می‌شود.

راه حل و پیشگیری

چند راه برای جلوگیری از این آسیب‌پذیری وجود دارد:

1.    به‌روزرسانی Next.js

نسخه‌های جدید این مشکل را رفع کرده‌اند:

• Next.js ≥ 15.2.3
• Next.js ≥ 14.2.25
• Next.js ≥ 13.5.9
• Next.js ≥ 12.3.5

2.    حذف یا فیلتر هدر x-middleware-subrequest در لایه شبکه

•    NGINX:

•    Apache:

3.   اعتبارسنجی سروری مستقل

حتی اگر Middleware دور زده شود، APIهای شما باید دوباره بررسی مجوز کنند.

جمع‌بندی

CVE-2025-29927 نشان می‌دهد که حتی فرضیات کوچک، مثل اینکه یک هدر داخلی فقط توسط سیستم ایجاد می‌شود، می‌تواند امنیت سایت را به خطر بیندازد.

نکته مهم: همیشه نسخه‌ی Next.js خود را به‌روز نگه دارید، و هیچ وقت فقط به Middleware برای امنیت اعتماد نکنید.

امیدوارم که مقاله فوق مفید بوده باشه 😊

جلوگیری از چنین حوادث امنیتی نیازمند نگاهی عمیق به کد منبع است. 

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