path-to-regexp कई रूट पैरामीटर के माध्यम से रेगुलर एक्सप्रेशन डिनायल ऑफ सर्विस (Regular Expression Denial of Service) के लिए असुरक्षित

### प्रभाव एक खराब रेगुलर एक्सप्रेशन (regular expression) तब जेनरेट होता है जब आपके पास एक ही सेगमेंट के भीतर तीन या अधिक पैरामीटर होते हैं, जो किसी ऐसी चीज से अलग होते हैं जो पीरियड (`.`) नहीं है। उदाहरण के लिए, `/:a-:b-:c` या `/:a-:b-:c-:d`। `path-to-regexp@0.1.12` में जोड़ा गया बैकट्रैक प्रोटेक्शन (backtrack protection) केवल दो पैरामीटर के लिए अस्पष्टता को रोकता है। तीन या अधिक के साथ, जेनरेट किया गया लुकहेड (lookahead) सिंगल सेपरेटर कैरेक्टर (single separator character) को ब्लॉक नहीं करता है, इसलिए कैप्चर ग्रुप (capture group) ओवरलैप होते हैं और कैटास्ट्रोफिक बैकट्रैकिंग (catastrophic backtracking) का कारण बनते हैं। ### पैच [path-to-regexp@0.1.13](https://github.com/pillarjs/path-to-regexp/releases/tag/v.0.1.13) में अपग्रेड करें रूट डेफिनिशन (route definition) में कस्टम रेगएक्स पैटर्न (custom regex pattern) (जैसे, `/:a-:b([^-/]+)-:c([^-/]+)`) प्रभावित नहीं होते हैं क्योंकि वे डिफ़ॉल्ट कैप्चर ग्रुप (default capture group) को ओवरराइड करते हैं। ### समाधान सभी संस्करणों को एक सिंगल सेगमेंट में पहले के बाद पैरामीटर के लिए एक कस्टम रेगुलर एक्सप्रेशन (custom regular expression) प्रदान करके पैच किया जा सकता है। जब तक कस्टम रेगुलर एक्सप्रेशन (custom regular expression) पैरामीटर से पहले टेक्स्ट से मेल नहीं खाता है, तब तक आप सुरक्षित रहेंगे। उदाहरण के लिए, `/:a-:b-:c` को `/:a-:b([^-/]+)-:c([^-/]+)` में बदलें। यदि पाथ (path) को फिर से नहीं लिखा जा सकता है और संस्करणों को अपग्रेड नहीं किया जा सकता है, तो एक और विकल्प यूआरएल (URL) की लंबाई को सीमित करना है। ### संदर्भ - [GHSA-9wv6-86v2-598j](https://githu