iteride/cve-2025-29927CVE-2025-29927 के लिए गहन विश्लेषण और PoC, x-middleware-subrequest हेडर के माध्यम से Next.js मिडलवेयर प्राधिकरण बाईपास। परीक्षण के लिए Nuclei टेम्पलेट और बड़े पैमाने पर स्कैनिंग स्क्रिप्ट शामिल है।
यह दस्तावेज़ Next.js फ्रेमवर्क में Middleware तंत्र को प्रभावित करने वाली भेद्यता CVE-2025-29927 के अध्ययन को प्रस्तुत करता है।
Next.js, Vercel द्वारा React-आधारित एप्लिकेशन विकसित करने के लिए एक लोकप्रिय ओपन-सोर्स फ्रेमवर्क है। यह सर्वर-साइड रेंडरिंग, स्टैटिक जनरेशन और रूटिंग, रीडायरेक्ट, सुरक्षा हेडर और एक्सेस अधिकार जाँच के लिए उपयोग किए जाने वाले मिडलवेयर (middleware) की एक लचीली प्रणाली का समर्थन करता है।
मार्च 2025 में, एक गंभीर भेद्यता CVE-2025-29927 की पहचान की गई, जो आंतरिक उप-अनुरोधों के सेवा हेडर के प्रसंस्करण से संबंधित है।
समस्या का सार—HTTP हेडर x-middleware-subrequest में एक विशेष मान डालकर, उन एप्लिकेशनों में प्राधिकरण जाँच को बायपास करने की संभावना है, जहाँ एक्सेस नियंत्रण केवल मिडलवेयर में लागू किया गया है। यदि सुरक्षा केवल मिडलवेयर पर निर्भर है, तो हमलावर संरक्षित रूट या डेटा तक पहुँच प्राप्त कर सकता है।
प्रभावित Next.js संस्करण और सुधार (सार्वजनिक स्रोतों और आधिकारिक सामग्रियों के अनुसार):
सुधार रिलीज़ 12.3.5 / 13.5.9 / 14.2.25 / 15.2.3 में उपलब्ध हैं।
Next.js का व्यापक रूप से प्रोडक्शन में उपयोग किया जाता है; मिडलवेयर स्तर (अक्सर प्रमाणीकरण/प्राधिकरण और सुरक्षा नीति के लिए उपयोग किया जाता है) को प्रभावित करने वाली भेद्यता उच्च व्यावहारिक जोखिम उत्पन्न करती है।
चरण-दर-चरण भेद्यता का विश्लेषण करना और अनुसंधान का पूरा चक्र तैयार करना:
सामग्री का संग्रह और संरचना।
CVE-2025-29927 पर सार्वजनिक स्रोतों को व्यवस्थित करना; दोष का सार, ट्रिगर स्थितियाँ और पुष्टि किए गए संस्करण/पैच प्रस्तुत करना।
CPE और कॉन्फ़िगरेशन शर्तों का निर्धारण।
CPE/संस्करणों की सूची प्रदान करना और उन कॉन्फ़िगरेशनों का वर्णन करना जिनमें भेद्यता दोहराई जाती है (उदाहरण के लिए, self-hosted डिप्लॉय और मिडलवेयर स्तर पर प्राधिकरण)।
सुरक्षित प्रदर्शन।
एक परीक्षण वातावरण (बिना विनाशकारी कार्यों के) पर एक दोहराने योग्य डेमो तैयार करना, जो कमजोर संस्करणों में मिडलवेयर को बायपास करने के तथ्य की पुष्टि करता है।
बड़े पैमाने पर जाँच की विधियाँ।
तीन सुरक्षित दृष्टिकोणों का वर्णन और कार्यान्वयन:
मूल कारण। Next.js में सेवा हेडर x-middleware-subrequest का उपयोग आंतरिक उप-अनुरोधों को ट्रैक करने और मिडलवेयर में पुनरावृत्ति को रोकने के लिए किया जाता है। कमजोर शाखाओं में, बाहरी क्लाइंट इस हेडर को "अपेक्षित" मान के साथ डाल सकते हैं—और रनटाइम मिडलवेयर के निष्पादन को छोड़ देता है, अनुरोध को सीधे रूट हैंडलर को अग्रेषित करता है।
हेडर की भूमिका। हेडर x-middleware-subrequest मूल रूप से एक आंतरिक संकेतक के रूप में डिज़ाइन किया गया था कि वर्तमान HTTP अनुरोध फ्रेमवर्क द्वारा एक मध्यवर्ती उप-अनुरोध के रूप में शुरू किया गया है, न कि सीधे उपयोगकर्ता द्वारा।
यह Next.js के आंतरिक तंत्र के सही संचालन के लिए आवश्यक है: रूटिंग के अलावा, यह फ्लैग प्रत्येक कॉल किए गए मध्यवर्ती स्तर को "चिह्नित" करके अनंत पुनरावृत्ति से बचने में मदद करता है।
लेकिन इसी तर्क ने अनजाने में सुरक्षा में एक छेद पैदा किया: क्लाइंट द्वारा स्वयं इस तरह के हेडर को जोड़ने पर, सिस्टम अपने अनुरोध को आंतरिक मान सकता है और इस प्रकार प्राधिकरण जाँच को दरकिनार कर सकता है।
तर्क का विकास।
NVD के वर्तमान रिकॉर्ड Vercel Next.js उत्पाद को लक्ष्य सॉफ़्टवेयर node.js के साथ इंगित करते हैं। कमजोर शाखाओं के लिए निम्नलिखित कॉन्फ़िगरेशन लागू होते हैं (संस्करण श्रेणियाँ NVD में CPE-कॉन्फ़िगरेशन स्तर पर निर्दिष्ट हैं):
| CPE URI | कमजोर संस्करण श्रेणी |
|---|---|
cpe:2.3:a:vercel:next.js:*:*:*:*:*:node.js:*:* | 11.1.4 ≤ v < 12.3.5 |
cpe:2.3:a:vercel:next.js:*:*:*:*:*:node.js:*:* | 13.0.0 ≤ v < 13.5.9 |
cpe:2.3:a:vercel:next.js:*:*:*:*:*:node.js:*:* | 14.0.0 ≤ v < 14.2.25 |
cpe:2.3:a:vercel:next.js:*:*:*:*:*:node.js:*:* | 15.0.0 ≤ v < 15.2.3 |
टिप्पणी: CVE के विवरण में यह भी उल्लेख है कि सामान्यतः "11.1.4 से 12.3.5 / 13.5.9 / 14.2.25 / 15.2.3 तक" भेद्यता नीचे दी गई शर्तों के पूरा होने पर दोहराई जाती है।
next start, output: 'standalone' के साथ बिल्ड) या कोई भी वातावरण जहाँ मिडलवेयर इनकमिंग अनुरोधों पर परिधि फ़िल्टरिंग के बिना निष्पादित होता है।x-middleware-subrequest वाले उपयोगकर्ता अनुरोधों को अस्वीकार करते हैं (जैसे, WAF नियम)।x-middleware-subrequest का आंतरिक तंत्रमिडलवेयर कोड की अनंत पुनरावृत्ति को रोकने के लिए, रनटाइम एक सेवा हेडर बनाता और पढ़ता है:
: द्वारा अलग किए गए तत्वों वाली स्ट्रिंग के रूप में व्याख्यायित किया जाता है—"उप-अनुरोधों" की एक सरणी प्राप्त होती है।NextResponse.next() के माध्यम से तुरंत छोड़ देता था),x-middleware-subrequest-id) जोड़ा गया है, जो वर्तमान प्रक्रिया सत्र से जुड़ा है; यदि यह मेल नहीं खाता है, तो इनकमिंग x-middleware-subrequest सर्वर साइड पर साफ़ कर दिया जाता है।हमलावर लक्ष्य Next.js एप्लिकेशन पर एक HTTP अनुरोध भेजता है, जिसमें सेवा हेडर x-middleware-subrequest जोड़ा जाता है।
मान में मिडलवेयर फ़ाइल का पथ इंगित किया जाता है—उदाहरण के लिए pages/_middleware, middleware या src/middleware।
आवश्यक मान उपयोग किए गए Next.js संस्करण और प्रोजेक्ट संरचना पर निर्भर करता है।
जब ऐसा अनुरोध एप्लिकेशन तक पहुँचता है, तो फ्रेमवर्क का आंतरिक तर्क इसे आंतरिक उप-अनुरोध के रूप में मानता है और मान लेता है कि मध्यवर्ती स्तर पहले ही निष्पादित हो चुका है।
परिणामस्वरूप, प्रमाणीकरण और प्राधिकरण जाँच, जो सामान्यतः मिडलवेयर में होती हैं, वास्तव में छोड़ दी जाती हैं।
महत्वपूर्ण: यह सामग्री केवल पैच की जाँच और बंद परीक्षण वातावरण में जोखिम मॉडलिंग के लिए दी गई है।
उत्पादन बुनियादी ढाँचे में कोई भी जाँच केवल संसाधन स्वामी की अनुमति से संभव है।
Next.js आंतरिक उप-अनुरोधों को चिह्नित करने और मिडलवेयर के पुनरावर्ती प्रारंभ को रोकने के लिए सेवा हेडर x-middleware-subrequest का उपयोग करता है।
अनुरोध को संसाधित करते समय, हेडर का मान : वर्ण द्वारा विभाजित किया जाता है और वर्तमान मिडलवेयर के नाम से तुलना की जाती है।
नए संस्करणों में गहराई सीमा (MAX_RECURSION_DEPTH, सामान्यतः 5) जोड़ी गई है।
यदि शर्त (नाम का मिलान या सीमा तक पहुँचना) पूरी होती है, तो Next.js मिडलवेयर को छोड़ देता है और अनुरोध को आगे भेजता है।
हमलावर एक आंतरिक उप-अनुरोध का अनुकरण करते हुए हेडर का सही मान बना सकता है।