स्रोतों की जाँच 23 अक्टूबर, 2026 तक की गई (UTC) कवरेज अवधि: 25 जुलाई-23 अक्टूबर, 2026, सितंबर से अक्टूबर तक नई घोषणाओं और उसके बाद के पैच पर ध्यान केंद्रित। दर्शक: इंजीनियर और सुरक्षा उत्तरदाता जो Node.js, Java, Python सेवाओं, कंटेनरों का रखरखाव करते हैं, पाइपलाइन और विकास वातावरण बनाते हैं।

यह आलेख Node.js, Java, और Python रनटाइम, मानक लाइब्रेरी और सामान्य सर्वर फ्रेमवर्क और निर्भरता में हाल के महत्वपूर्ण सुरक्षा जोखिमों का सारांश देता है, और प्रभाव गुंजाइश, निश्चित संस्करण, अस्थायी शमन उपाय, पैच चयन और सत्यापन विधियां प्रदान करता है।

घटक संस्करणों, सक्षम सुविधाओं और सुलभ प्रवेश बिंदुओं पर प्रभाव का आकलन करें। असुरक्षा के तथ्य आधिकारिक सलाह से आते हैं; तारीखें सार्वजनिक प्रकटीकरण को संदर्भित करती हैं जब तक कि पहले के पैच रिलीज़ को स्पष्ट रूप से नोट नहीं किया गया हो। हम अपुष्ट शोषण स्थितियों, CVSS स्कोर या जंगली शोषण का अनुमान नहीं लगाते हैं। परिनियोजन सलाह को कार्यान्वयन मार्गदर्शन के रूप में पहचाना जाता है।

TL;DR: सुधारात्मक प्राथमिकताएँ

  1. पहले उस रनटाइम को अपडेट करें जो वास्तव में सेवा को होस्ट करता है। संबंधित Node.js शाखा को कम से कम 22.23.4 / 24.22.1 / 26.12.1 पर अपडेट करें। Node 24 का उपयोग करने वाली सेवाएँ उसी प्रमुख संस्करण या बाद के संस्करणमें24.22.1 में अपग्रेड हो सकती हैं जिसमें समान फ़िक्सेस शामिल हैं। S1S2
  2. अपडेट Node एप्लिकेशन निर्भरता को अलग से। Next.js के लिए, अपग्रेड बेसलाइन के रूप में 15.5.28 / 16.4.1 का उपयोग करें; स्वतंत्र रूप से React Server Components का उपयोग करते समय, वास्तविक स्थापित react-server-dom-* पैकेज की जाँच करें। केवल Node बाइनरी को अपडेट करने से इन फ्रेमवर्क कमजोरियों को कवर नहीं किया जाता है। S8S9S10S11S12
  3. Java: अपडेट के दोनों दौर को कवर करें। 20 अक्टूबर CPU और 21 अक्टूबर CVE-2026-91403 आपातकालीन प्रमाणपत्र-ट्रस्ट फिक्स दोनों को कवर करने वाला एक विक्रेता बिल्ड स्थापित करें। Oracle JDK 11-27 आउट-ऑफ-बैंड संस्करणों के लिए अनुभाग 2.2 देखें; अन्य वितरणों को उनके स्वयं के सुरक्षा पैकेजों और पूर्ण बिल्ड नंबरों के विरुद्ध सत्यापित करें। संबंधित Tomcat शाखा को 9.0.123 / 10.1.61 / 11.0.27 पर अपडेट करें। S16S17S18S20S21S22S23
  4. Python : दुभाषिया, एप्लिकेशन पैकेज और प्रमाणपत्र पैकेज को अलग से अपडेट करें। खंड देखें 2.3 दुभाषिया आधार रेखाओं के लिए; certifi की सिफारिश की ≥ 2026.10.19 , pip ≥ 26.2.2 , उपयोग करते समय uv ≥ 0.13.4 . प्रत्येक मौजूदा वेनव की जाँच की जानी चाहिए। के लिए wrap_bio() संबंधित कोड, सही और गैर-रिक्त server_hostname भी पारित किया जाना चाहिए. S29 S30 S31 S33 S35 S36 S37
  5. यदि तत्काल अपग्रेड असंभव है, तो संबंधित प्रवेश बिंदुओं पर एक्सपोज़र कम करें। अविश्वसनीय Brotli डिकोडिंग, प्रभावित छवि/पेजिंग/संग्रह प्रसंस्करण को रोकने और समस्याग्रस्त LDAP या प्रमाणीकरण प्रविष्टियों को अलग करने को प्राथमिकता दें; TLS प्रमाणपत्रों और होस्टनामों को सत्यापित रखना। इनबाउंड WAF आउटबाउंड पथों को कवर नहीं कर सकता है जैसे कि दुर्भावनापूर्ण संपीड़ित प्रतिक्रियाएँ खींचने वाले एप्लिकेशन। S3S11S25S27S30S32
  6. पुनर्निर्माण करें, पुरानी प्रक्रियाओं को बदलें, और वास्तविक सेवा पथों के माध्यम से सत्यापित करें। लॉक फ़ाइल और छवि डाइजेस्ट को सहेजें, एप्लिकेशन और छवि का पुनर्निर्माण करें, सभी श्रमिकों/JVM/कंटेनरों के लिए प्रतिस्थापन रोल आउट करें; वास्तविक प्रक्रिया, निर्भरता वृक्ष, ट्रस्ट स्टोर और व्यवसाय प्रतिगमन परीक्षण की जाँच करें। केवल एक नया कमांड-लाइन संस्करण यह स्थापित नहीं करता है कि निवारण पूरा हो गया है।
  7. यदि LiteLLM 1.107.0 स्थापित या चलाया गया था, तो घटना-प्रतिक्रिया प्रक्रियाओं का पालन करें। परियोजना ने 21 अक्टूबर को रिलीज समझौते की पुष्टि की। प्रभावित वातावरण को अलग करें, एक स्वच्छ वातावरण से जांच करें, उजागर क्रेडेंशियल्स को पुनर्निर्माण और घुमाएं। पहले जाँच के लिए संदिग्ध वातावरण में Python/pip प्रारंभ न करें। विवरण के लिए धारा 9 देखें. S41

1. भेद्यता अवलोकन और जोखिम मूल्यांकन

1.1 वास्तविक एक्सपोज़र द्वारा निवारण को प्राथमिकता दें

नीचे दी गई परिनियोजन प्राथमिकताएँ कार्यान्वयन मार्गदर्शन हैं। गंभीरता लेबल प्रत्येक विक्रेता का अनुसरण करते हैं, जिसमें Apache की Important रेटिंग शामिल है। CVSS 3.1 और 4.0 अलग-अलग स्कोरिंग सिस्टम हैं; मुद्दों को केवल स्कोर के आधार पर रैंक न करें।

पारिस्थितिकी तंत्र/परतप्रमुख मुद्देआधिकारिक ग्रेड या सत्यापित स्कोरप्राथमिकता तैनाती
Node.js मूल निर्भरताCVE-2026-111497: Brotli सीमा से बाहर लिखा गया है, और RCE का जोखिम हैNode:Highबाहरी अनुरोध निकाय या बाहरी प्रतिक्रिया में Brotli डेटा S1S3 को डिकोड करें
Node.js TLS / DNSCVE-2026-105482, 105483, 106069: पार्सिंग और पहचान सत्यापन असंगत हैंHighURL क्रॉल, प्रॉक्सी, Webhook, गतिशील लक्ष्य पता S1S5S6
Node.js HTTP/2CVE-2026-56846, 56848: मेमोरी समाप्त हो गई और UAFHighNode सीधे अविश्वसनीय HTTP/2 ट्रैफ़िक S7 को संभालता है
React / Next.jsRSC / use cache typed arrays RCECritical;CVSS 4.0 9.5सर्वर RSC, संबंधित कैश घटक और डेटा पथ S9S10
Next.js छवि अनुकूलनCVE-2026-96889: SVG इमेज प्रोसेसिंग RCECritical;CVSS 4.0 9.5glibc Linux पर उदाहरण जो अविश्वसनीय छवियों को संभाल सकते हैं S11
Next.js Server Actionsविशेष रूप से तैयार किए गए अनुरोध के कारण CPU समाप्त हो जाता हैHigh;CVSS 4.0 8.2App Router और कम से कम एक Server Action S12
Java TLS ट्रस्टCVE-2026-91403: प्रभावित मध्यवर्ती CA पर भरोसा करना जारी रखेंCVSS 3.1 9.1प्रभावित विश्वास श्रृंखला का उपयोग करते हुए TLS/API परिदृश्य S17
TomcatJNDIRealm प्रमाणीकरण बायपास, HTTP/2 क्रॉस-अनुरोध मिश्रण, AJP प्रतिक्रिया रिसावImportantRealm / Connector / async Servlet पथ S21S22S23 के अनुरूप
Spring for GraphQLCVE-2026-59285: पेजिंग डिसेरिएलाइज़ेशन RCEHighJackson 2 + Connection पेजिंग + एक्सप्लॉइटेबल क्लासपाथ S25
Spring SecurityCVE-2026-59270: एंबेडेड LDAP ज्ञात प्रबंधन पहचान उजागरCriticalएंबेडेड LDAP सक्षम है और श्रवण पोर्ट हमलावर S27 तक पहुंच योग्य है
CPython sslCVE-2026-19445: SNI स्विचिंग संदर्भ परिणाम UAF मेंCriticalPython स्वयं TLS को समाप्त करता है, और संदर्भ जीवन चक्र स्थिति S29 को पूरा करता है
CPython sslCVE-2026-19553: होस्टनाम गुम होने पर सत्यापन छोड़ेंHighwrap_bio() / संबंधित asyncio कॉल में अपेक्षित होस्टनाम गायब है S30
CPython tarfileCVE-2026-82049: हार्ड लिंक और प्रतीकात्मक लिंक संयोजन बाईपासHighस्वचालित रूप से अविश्वसनीय टार संग्रह S32 निकालें
Django / GeoDjangoCVE-2026-15307: स्थानिक क्वेरी लेखन फ़ाइल, SSRF, शर्त RCE के तहतHighस्थानिक प्रश्न या संबंधित प्रशासन इंटरफ़ेस अविश्वसनीय इनपुट S38 स्वीकार करते हैं
Python प्रमाणपत्र निर्भरताcertifi: emSign संबंधित प्रमाणपत्र अविश्वासCritical; GHSA, कोई ज्ञात नहीं CVETLS क्लाइंट और पैकेज प्रबंधन टूल S36S37 अभी भी प्रभावित CA bundle का उपयोग कर रहा है

संक्षिप्त रूप: RCE का अर्थ है रिमोट कोड निष्पादन, UAF का अर्थ है उपयोग-बाद-मुक्त, और SSRF का अर्थ है सर्वर-साइड अनुरोध जालसाजी। RCE की प्रत्यक्ष अनुमतियाँ आमतौर पर एप्लिकेशन को होस्ट करने वाली प्रक्रिया की अनुमतियाँ होती हैं और स्वचालित रूप से रूट अनुमतियों के बराबर नहीं हो सकती हैं।

अनुशंसित अनुक्रम: पहले RCE को संभालता है, जो बाहरी रूप से पहुंच योग्य है और शर्तों, प्रमाणीकरण बाईपास, क्रॉस-उपयोगकर्ता डेटा रिसाव और प्रमाणपत्र प्रमाणीकरण मुद्दों को पूरा करता है; उसी समय, सार्वजनिक-सामना वाले DoS प्रवेश बिंदु के लिए अपडेट शेड्यूल करें। शोषणशीलता साबित करने के लिए उत्पादन में आक्रमण पेलोड चलाने की आवश्यकता नहीं है। निर्भरताएँ मौजूद हैं, कोड पथ पहुंच योग्य हैं, और हमले की स्थितियाँ पूरी होती हैं। ये तीन मुद्दे हैं जिनकी अलग से जाँच करने की आवश्यकता है।

1.2 तीन आसानी से भ्रमित होने वाली सीमाएँ

  • रनटाइम और निर्भरता को अलग से अपग्रेड करें। Node, JDK, CPython के लिए सुरक्षा अपडेट स्वचालित रूप से Next.js, Spring, Django के स्टैंडअलोन इंस्टॉलेशन की मरम्मत नहीं करता है। certifi या मूल एक्सटेंशन।
  • उपचार सीमा वर्तमान परिनियोजन बेसलाइन से अलग है। अगस्त में भेद्यता के लिए पहला पैच सितंबर से अक्टूबर तक नए मुद्दों को कवर करने की गारंटी नहीं देता है; धारा 2 कार्यान्वयन लक्ष्य के रूप में सत्यापित अनुवर्ती अद्यतनों का उपयोग करती है।
  • वास्तविक आपूर्ति-श्रृंखला समझौते से भेद्यता को अलग करें। सामान्य कमजोरियों के लिए, पैच भविष्य के हमले के रास्तों को खत्म कर देते हैं; जब दुर्भावनापूर्ण पैकेज चलाए गए हों, तो साख और दृढ़ता के प्रभाव की जांच की जानी चाहिए। धारा 9 की LiteLLM आधिकारिक तौर पर पुष्टि की गई घटना है। S41

जंगल में शोषण की पुष्टि हुई है या नहीं, यह आधिकारिक खुलासे पर आधारित होना चाहिए। विक्रेता ने शोषण गतिविधियों का उल्लेख नहीं किया और यह साबित नहीं कर सका कि कोई हमला नहीं हुआ है; वास्तविक हमले की सतह के आधार पर उपचार किया जाना चाहिए।

2. निश्चित संस्करण और परिनियोजन बेसलाइन की त्वरित जांच

संदर्भ: 2.1 Node.js、React、Next.js

घटक/शाखाअनुशंसित संस्करण बेसलाइनउपयोग के लिए निर्देश
Node.js 22.x22.23.421 अक्टूबर को सुरक्षा रिलीज़ S1S2
Node.js 24.x24.22.124.x शाखा पर लागू होता है; 24.22.0 में 21 अक्टूबर का सुरक्षा पैच S1S2 शामिल नहीं है
Node.js 26.x26.12.1एक ही बैच में सुरक्षा रिलीज़ S1S2
Node.js 20 और पहले की अपस्ट्रीम शाखाएँकिसी समर्थित शाखा में स्थानांतरित करेंNode 20 इस अपस्ट्रीम फिक्स को स्वीकार नहीं करता है; विक्रेता द्वारा विस्तारित समर्थन को अलग से S3 सत्यापित किया जाना चाहिए
Next.js 15.x15.5.2814 अक्टूबर को अपडेट किया गया S8
Next.js 16.x16.4.1उपरोक्त S8 के समान
स्टैंडअलोन RSC 19.0 / 19.1 / 19.2 / 19.3 शाखा19.0.9 / 19.1.10 / 19.2.9 / 19.3.1तीन react-server-dom-* पैकेजों को अलग से जांचें; केवल शीर्ष परत react S10 को न देखें
Next ने वास्तव में sharp लोड किया≥0.35.5SVG भेद्यता के लिए आधिकारिक अस्थायी सुधार स्थितियाँ; अन्य Next.js पैच S11 को प्रतिस्थापित नहीं करता है

Node आधिकारिक तौर पर अक्टूबर भेद्यता के लिए प्रभावित रखरखाव शाखाओं को सूचीबद्ध करता है, लेकिन आइटम द्वारा शुरू में पेश किए गए पैच संस्करण आइटम प्रदान नहीं करता है, इसलिए प्रत्येक भेद्यता का सटीक प्रारंभिक संस्करण केवल रखरखाव शाखा सीमा के आधार पर निर्धारित नहीं किया जा सकता है। परिनियोजन करते समय, उसी शाखा के उपरोक्त संस्करण या उसके बाद के संस्करण का उपयोग करने को प्राथमिकता दें जिसमें समान सुधार शामिल होने की पुष्टि की गई हो।

2.2 Java: अक्टूबर CPU प्लस आउट-ऑफ-बैंड प्रमाणपत्र अपडेट

यह तालिका Oracle JDK पर लागू होती है। दूसरा कॉलम केवल 20 अक्टूबर CPU को कवर करता है; तीसरे में 21 अक्टूबर की आउट-ऑफ़-बैंड रिलीज़ शामिल है। अकेले CPU संस्करण यहां चर्चा किए गए सभी Java जोखिमों को कवर नहीं करते हैं। S16S17S18

शाखा20 अक्टूबर CPUOracle 21 अक्टूबर को बैंड से रिलीज़ हुआ
1111.0.3311.0.33.0.2
1717.0.2117.0.21.0.2
2121.0.1321.0.13.0.2
2525.0.525.0.5.0.2
2727.0.127.0.1.0.2
88u511सार्वजनिक रिलीज़ तालिका अभी भी 8u511 दिखाती है; विशिष्ट सुरक्षा निर्माण और विश्वास श्रृंखला की मरम्मत की जाँच की जानी चाहिए, और केवल लघु संस्करण संख्या के आधार पर इसका निर्धारण नहीं किया जा सकता है

**Java 8 को पूर्ण बिल्ड जानकारी के विरुद्ध जाँचने की आवश्यकता है:**Oracle अलर्ट 8u511 को प्रभावित संस्करण के रूप में सूचीबद्ध करता है, और रिलीज़ सूची उसी संक्षिप्त नाम के साथ बाद के अपडेट को सूचीबद्ध करती है। केवल “8u511” लघु संस्करण संख्या के आधार पर पैच स्थिति को अलग नहीं किया जा सकता है। आपको विशिष्ट सुरक्षा निर्माण और विश्वास श्रृंखला सुधारों की पुष्टि करनी चाहिए। S17S18

Temurin, Corretto, Zulu, Microsoft Build of OpenJDK, रिलीज संस्करण OpenJDK, आदि, उनकी संबंधित घोषणाओं और पूर्ण पैकेज/बिल्ड नंबरों के अनुसार जांचें। उदाहरण के लिए, का आधिकारिक रिलीज रिकॉर्ड Adoptium बताता है कि संबंधित बिल्ड को eMudhra फिक्स जोड़ने के लिए दोबारा पैक किया गया है; अपस्ट्रीम संस्करण के समान नाम का मतलब यह नहीं है कि पैकेज सामग्री समान है। Oracle के लिए .0.2 प्रत्यय नियम अन्य प्रकाशकों पर यांत्रिक रूप से लागू नहीं किए जा सकते। S20

Java अनुप्रयोग घटकअनुशंसित संस्करण बेसलाइनटिप्पणियाँ
Tomcat 9 / 10.1 / 119.0.123 / 10.1.61 / 11.0.27शाखा दर शाखा जांचें; Tomcat 10.0 ने रखरखाव बंद कर दिया है S21S22S23
Spring for GraphQL 2.0.x2.0.5(OSS)वाणिज्यिक समर्थन भी 2.0.4.1 S25 है
Spring Security 7.1 / 7.07.1.1 / 7.0.7(OSS)अगस्त में घोषित न्यूनतम फिक्स संस्करण के अनुरूप; आपको तैनाती से पहले अगले सुरक्षा बुलेटिन S27S28 की जांच करनी होगी
Spring Security 6.5 / 6.4 / 5.8 / 5.76.5.12 / 6.4.19 / 5.8.28 / 5.7.26घोषणा को व्यावसायिक समर्थन फ़िक्स के रूप में सूचीबद्ध किया गया है; माइग्रेशन का मूल्यांकन तब किया जाता है जब कोई संगत समर्थन नहीं होता है, और यह नहीं माना जा सकता है कि Maven Central मुफ्त में उपलब्ध है S27

Spring अपग्रेड को प्रोजेक्ट के Spring Boot BOM, Java न्यूनतम संस्करण और संगतता लाइनों का सम्मान करना चाहिए। केवल पैच प्राप्त करने के लिए सभी Spring मॉड्यूल को सीधे एक ही नंबर पर बाध्य न करें।

2.3 CPython, Django और प्रमाणपत्र निर्भरताएँ

नीचे दी गई तालिका का दूसरा कॉलम सितंबर में सामने आए TLS मुद्दे पर केंद्रित है; tarfile के लिए शाखा अंतर अनुभाग 5.3. में दिखाए गए हैं 21 अक्टूबर की रिलीज़ ने बंडल प्रमाणपत्र टूलींग को भी अपडेट किया है, इसलिए अंतिम कॉलम में बाद की तैनाती बेसलाइन शामिल हैं। S29S30S33S35

CPython शाखासितंबर सुरक्षा बैच न्यूनतम संस्करणअनुशंसित परिनियोजन बेसलाइन
3.103.10.22अपस्ट्रीम से अंतिम रिलीज़, EOL; माइग्रेशन की व्यवस्था करें या रिलीज़ एक्सटेंशन समर्थन S34 को सत्यापित करें
3.113.11.173.11.17, और प्रत्येक वातावरण में pip/certifi को व्यक्तिगत रूप से अपडेट करें
3.123.12.153.12.15, और प्रत्येक वातावरण में pip/certifi को व्यक्तिगत रूप से अपडेट करें
3.133.13.163.13.17
3.143.14.83.14.9
3.15अंतिम 3.15.0 रिलीज़ में TLS फिक्स S31S47 दोनों शामिल हैं3.15.1

3.11 और 3.12 के अपस्ट्रीम सुरक्षा संस्करण केवल स्रोत कोड में जारी किए जा सकते हैं; ऑपरेटिंग सिस्टम पैकेज का उपयोग करते समय, विक्रेता की बैकपोर्ट सलाह और पूर्ण पैकेज संस्करण की जांच करें, और सिस्टम Python को स्व-संकलित संस्करण के साथ जबरन बदलने की कोई आवश्यकता नहीं है। S33S34

स्वतंत्र निर्भरताअनुशंसित संस्करण बेसलाइनविवरण
Django 5.2 / 6.0 / 6.15.2.18 / 6.0.9 / 6.1.26 अक्टूबर को अगला सुधार S38S39 शामिल करें
certifi≥2026.10.19GHSA प्रारंभिक पैच .18 है; PSF अप्रभावित प्रमाणपत्रों के लिए अनुकूलता बनाए रखने के लिए .19 की अनुशंसा करता है S36S37
pip≥26.2.2certifi की अंतर्निहित प्रतिलिपि को अलग से अद्यतन करने की आवश्यकता है S35S37
uv (यदि उपयोग किया गया हो)≥0.13.4वास्तविक इंस्टॉलेशन विधि के अनुसार S37 को अपडेट करें

ये बेसलाइन सूचीबद्ध फ़िक्सेस को कवर करती हैं। tar_filter में एक और मध्यम-गंभीरता समस्या का खुलासा 22 अक्टूबर को किया गया था। 23 अक्टूबर, 2026 तक, इस फिक्स वाले आधिकारिक रखरखाव संस्करण की अभी तक पुष्टि नहीं की गई है; इसलिए, 3.13.17 / 3.14.9 / 3.15.1 को सभी टैरिफ़ मुद्दों को कवर करने वाला नहीं माना जा सकता है। अनुभाग 5.4. S40 देखें

2.4 वितरण बैकपोर्ट का सत्यापन

Ubuntu, Debian, RHEL और अन्य सॉफ्टवेयर पैकेजों पर लागू कार्यान्वयन सिद्धांत:

  1. ऑपरेटिंग सिस्टम संस्करण, रिपॉजिटरी स्रोत, पूर्ण पैकेज संस्करण और विक्रेता सुरक्षा बुलेटिन नंबर रिकॉर्ड करें।
  2. पुष्टि करें कि सलाह विशिष्ट CVE को कवर करती है और प्रासंगिक वितरण रिलीज़ के लिए एक निश्चित पैकेज की पहचान करती है।
  3. वास्तविक चल रही प्रक्रिया द्वारा लोड की गई बायनेरिज़/लाइब्रेरी की तुलना करें, न कि केवल अपस्ट्रीम लघु संस्करण की।
  4. जब विक्रेता पैच का कोई सबूत नहीं है, तो इसे “पुष्टि होने के लिए” छोड़ दें और इसे एकमात्र निष्कर्ष के रूप में न लें कि संस्करण संख्या पुरानी या नई दिखती है।

apt/RPM पैकेज संस्करणों और विभिन्न वितरणों की बैकपोर्ट रणनीतियों में अंतर हैं। प्रत्येक वितरण का सुरक्षा बुलेटिन और पूर्ण पैकेज संस्करण प्रबल होना चाहिए।

3. Node.js / JavaScript पारिस्थितिकी तंत्र: कारणों का विश्लेषण और निवारण

3.1 CVE-2026-111497: Brotli देशी डिकोडर सीमा से बाहर लिखें

प्रकटीकरण: 2026-10-21; Node आधिकारिक ग्रेड: High। Node 22.x, 24.x, 26.x के प्रभावित बिल्ड को पैच अनुभाग 2.1 स्थापित करने की आवश्यकता है। Node घोषणा में संख्यात्मक CVSS स्कोर सूचीबद्ध नहीं है। S1

विकृत Brotli संपीड़ित स्ट्रीम को संभालते समय मूल डिकोडिंग तर्क में समस्या उत्पन्न होती है, जिससे आउट-ऑफ-बाउंड लेखन हो सकता है। Vercel का आधिकारिक विवरण पुष्टि करता है कि अनुसंधान प्रदर्शन में प्रक्रिया मेमोरी लीक और कमांड निष्पादन शामिल है। कोई हमलावर डिकोडर तक पहुंच सकता है या नहीं, यह इस बात पर निर्भर करता है कि एप्लिकेशन या निर्भरता वास्तव में उसके द्वारा नियंत्रित डेटा को डिकोड करती है या नहीं। S3

दोनों दिशाओं की एक ही समय में जाँच की जानी चाहिए:

  • inबाउंड: फ्रेमवर्क या मिडलवेयर उपयोगकर्ता द्वारा सबमिट किए गए Brotli अनुरोध निकाय को स्वचालित रूप से डीकंप्रेस करता है।
  • **आउटबाउंड:**HTTP क्लाइंट, इमेज ग्रैबर्स आदि हमलावर-नियंत्रणीय स्रोतों तक पहुंचते हैं और लौटाई गई सामग्री को स्वचालित रूप से डीकंप्रेस करते हैं।

ब्राउज़रों को भेजी गई प्रतिक्रियाओं के Brotli संपीड़न को अक्षम करने से डिकोडिंग प्रविष्टि बिंदु नहीं हटता है। इनबाउंड WAF सुरक्षा बाहरी प्रतिक्रियाओं को लाने और डिकोड करने वाले अनुप्रयोगों को भी कवर नहीं करती है। S3

**पैच दिशा:**Node Brotli अपस्ट्रीम फिक्स को मूल निर्भरता में ले जाएं, और अवैध डिकोडिंग स्थिति जांच और त्रुटि प्रसार को पूरक करें। स्व-संकलित संस्करण बनाए रखते समय, आपको आधिकारिक सुरक्षा रिलीज़ या मिलान शाखा के पूर्ण पैच का उपयोग करना चाहिए। आप केवल JavaScript पैकेज का संस्करण विवरण नहीं बदल सकते। S4

अंतरिम कार्यान्वयन सुझाव: अनावश्यक अविश्वसनीय Brotli डिकोडिंग रोकें; मिडलवेयर और HTTP क्लाइंट के स्वचालित डीकंप्रेसन व्यवहार की जाँच करें; यदि व्यवसाय को इस प्रारूप को स्वीकार करना है, तो पैच किए गए वातावरण में प्रसंस्करण को जल्द से जल्द पूरा करें। Accept-Encoding को समायोजित करना केवल बातचीत का एक कार्य है और इसे सबूत के रूप में अकेले नहीं खड़ा किया जाना चाहिए कि एक दुर्भावनापूर्ण प्रतिक्रिया को अवरुद्ध कर दिया गया है।

3.2 TLS / DNS तीन High: सत्यापन वस्तु वास्तविक लक्ष्य के साथ असंगत है

इन तीनों का खुलासा 21 अक्टूबर को किया गया, जिसमें अनुभाग 2.1. S1 में आधिकारिक अपग्रेड सीमा निर्धारित की गई थी।

पहचानकर्तामुद्दे की पुष्टि हो गईप्रभावित शाखाएँ
CVE-2026-105482dns.resolve NUL वाले नामों का संक्षिप्तीकरण22.x / 24.x / 26.x
CVE-2026-105483IP पूर्ण-चौड़ाई वाले संख्यात्मक रूप में प्रमाणपत्र होस्टनाम सत्यापन को बायपास करने का कारण बनता है24.x / 26.x
CVE-2026-106069होस्टनाम जिसे मोटे तौर पर IP के रूप में व्याख्या किया जा सकता है, जिसके परिणामस्वरूप TLS सत्यापन बाईपास होता है22.x / 24.x / 26.x

DNS समस्या का सार यह है कि ऊपरी परत द्वारा जांची गई स्ट्रिंग वास्तव में निचली परत द्वारा पार्स किए गए नाम से भिन्न है। आधिकारिक पैच पार्सिंग प्रविष्टि पर NUL को अस्वीकार करता है और प्रतिगमन कवरेज जोड़ता है। S6

TLS दो आइटमों में नाम सामान्यीकरण, IP व्याख्या की स्थिरता और प्रमाणपत्र मिलान शामिल है। पैच करें ताकि गैर-मानक IP इनपुट को अस्वीकार कर दिया जाए या प्रमाणपत्र डोमेन पहचान के साथ वास्तविक IP एंडपॉइंट को भ्रमित करने से बचने के लिए सही ढंग से प्रबंधित किया जाए। S5

के लिए वास्तविक समस्या निवारण सुझाव: प्राप्तकर्ता उपयोगकर्ता URL, डायनेमिक प्रॉक्सी लक्ष्य या Webhook पते के कोड की जांच करने को प्राथमिकता देता है; एकीकृत मानकीकरण और अनुमति सूची निर्णय, NUL/नियंत्रण वर्णों को अस्वीकार करता है, कानूनी IPv4, IPv6 की पुष्टि करता है और अंतर्राष्ट्रीयकृत डोमेन नाम अभी भी काम करते हैं। क्या SSRF को आगे बनाया जा सकता है, इसके लिए लिंक साक्ष्य के आवेदन की आवश्यकता होती है, जिसे सीधे CVE नाम से नहीं निकाला जा सकता है।

अपग्रेड के बाद चेकसम त्रुटियों को खत्म करने के लिए NODE_TLS_REJECT_UNAUTHORIZED=0 या rejectUnauthorized: false का उपयोग न करें। पता, प्रमाणपत्र और व्यवसाय कॉन्फ़िगरेशन को सही किया जाना चाहिए।

3.3 जुलाई HTTP/2 High-जोखिम और अनुमति मॉडल मुद्दे

जुलाई में उजागर किए गए निम्नलिखित मुद्दों को अभी भी जांच में शामिल करने की आवश्यकता है। तैनाती करते समय अनुभाग 2.1 में सीधे अक्टूबर सुरक्षा संस्करण बेसलाइन का उपयोग करने की अनुशंसा की जाती है। S7

CVEकारण और प्रभावपहला निश्चित संस्करण
CVE-2026-56846बरकरार रखा गया HTTP/2 header ब्लॉक maxSessionMemory बजट में उचित रूप से शामिल नहीं है और मेमोरी समाप्त कर सकता है; प्रभाव 22.x / 24.x22.23.2 / 24.18.1
CVE-2026-56848HTTP/2 पैकेट संग्रह के दौरान प्रेषण पथ में फिर से प्रवेश करता है, जिससे ढेर UAF बनता है; प्रभाव 22.x / 24.x / 26.x22.23.2 / 24.18.1 / 26.5.1
CVE-2026-58043--permission पथ उपसर्ग सीमा मिलान बहुत चौड़ा है, और अनुमत सूची के बाहर की फ़ाइलों तक पहुँचा जा सकता है।उपरोक्त तीन रखरखाव लाइनों के समान

ये तीनों आधिकारिक तौर पर High हैं। पहले दो आइटम यह जाँचने को प्राथमिकता देते हैं कि क्या HTTP/2 को Node द्वारा ही संसाधित किया गया है; अनुमति मॉडल का उपयोग करते समय और इस सीमा पर भरोसा करते समय तीसरे आइटम का केवल संगत अर्थ होता है। सभी अनुमति मॉडल आइटम को नेटवर्क RCE के रूप में वर्णित नहीं किया जा सकता है जिसके लिए प्रमाणीकरण की आवश्यकता नहीं है। S7

एक अलग, अद्यतन प्रॉक्सी पर HTTP/2 को अस्थायी रूप से समाप्त करना और बैकएंड स्रोतों को सीमित करना एक्सपोज़र को कम करने के लिए एक तैनाती विकल्प है; संसाधन कोटा केवल संसाधन समाप्ति के परिणामों को नियंत्रित कर सकता है और UAF को पैच नहीं कर सकता है।

3.4 अक्टूबर React / Next.js: दो आइटम RCE और एक आइटम DoS

A. RSC / में RCE use cache फ़ंक्शन टाइप किए गए ऐरे लौटाते हैं

सार्वजनिक दिनांक: 2026-10-14; Critical, CVSS 4.0 9.5. आधिकारिक सलाहकार पहचानकर्ता:

  • React:GHSA-xqc2-xf4c-x3h3。
  • Next.js:GHSA-673q-mjm6-r5xr。S9S10

React अपस्ट्रीम समस्या में हमलावर-नियंत्रणीय मानों के साथ संयुक्त कई टाइप किए गए एरे शामिल हैं RSC प्रतिक्रिया। तीन प्रभावित हुए react-server-dom-* पैकेज संस्करण हैं 19.0.0 — 19.0.8 , 19.1.0 — 19.1.9 , 19.2.0 — 19.2.8 , 19.3.0 ; अध्याय अनुभाग देखें 2.1. शुद्ध ब्राउज़र-पक्ष React , या ऐसे एप्लिकेशन जो समर्थन करने वाले फ़्रेमवर्क/प्लग-इन का उपयोग नहीं करते हैं RSC बिल्कुल भी, इस मद के दायरे में नहीं आते। S10

Next.js डाउनस्ट्रीम घोषणा सूचियाँ 16.0.0—16.4.0, 16.4.1 में संशोधित; परिदृश्य App Router, Cache Components, और use cache फ़ंक्शंस है जो एकाधिक टाइप किए गए सरणी लौटाते हैं। कोई आधिकारिक विश्वसनीय सामान्य समाधान नहीं है, और प्रभावित संस्करणों के उपयोगकर्ताओं को समय पर अपग्रेड करना आवश्यक है। प्रसंस्करण समाप्त करने के लिए केवल “यह फ़ंक्शन मौजूद नहीं है” के लिए मैन्युअल खोजों पर निर्भर रहना उचित नहीं है। S9

संदर्भ: B. SVG Image Optimization RCE

CVE-2026-96889/GHSA-2464-fhr4-w9xw, 2026-10-14, Critical, CVSS 4.0 9.5। The समस्या छवि अनुकूलन के लिए उपयोग की जाने वाली अपस्ट्रीम मूल लाइब्रेरी में होती है। अधिकारियों ने बताया कि RCE जोखिम glibc Linux परिदृश्य में मौजूद है। S11

आधिकारिक संस्करण फ़ील्ड हैं:

  • >=10.0.0 <=15.5.27;
  • >16.0.0 <=16.4.0。

अधिकारी 16.x शाखा के लिए >16.0.0 की सख्त निचली सीमा का उपयोग करता है, लेकिन यह रेंज स्टेटमेंट यह साबित करने के लिए पर्याप्त नहीं है कि 16.0.0 सुरक्षित है। वास्तविक उन्नयन लक्ष्य समान रूप से 15.5.28 / 16.4.1 है। S11

आधिकारिक अस्थायी समाधान यह सुनिश्चित करना है कि Next वास्तव में तेज ≥0.35.5 लोड हो। लॉक फ़ाइलें, नेस्टेड निर्भरताएँ और परिनियोजन छवियाँ अभी भी पुराने उदाहरण रख सकती हैं, इसलिए केवल शीर्ष स्तर पर sharp निर्भरता का एक नया संस्करण जोड़ना पर्याप्त नहीं है, अंतिम निर्भरता ट्री की जाँच की जानी चाहिए और उसे फिर से बनाया जाना चाहिए। S11

C. Server Actions CPU समाप्त हो गया

GHSA-p3m5-59mp-jv5r , 2026-10-14, High , CVSS 4.0 8.2 . Next को प्रभावित करता है 13.0.0 — 15.5.27 , 16.0.0 — 16.4.0 , ठीक करता है 15.5.28 / 16.4.1 . शर्तें हैं App Router और कम से कम एक Server Action ; दुर्भावनापूर्ण अनुरोध रख सकते हैं CPU लंबे समय तक कब्जा कर लिया, उसी प्रक्रिया में बाद के अनुरोधों को अवरुद्ध कर दिया। के साथ अनुप्रयोग Pages Router या बिना Server Actions इससे प्रभावित नहीं हैं. S12

ऐसा कोई आधिकारिक समाधान नहीं है जो अपग्रेड की जगह ले सके। दर सीमा, समवर्ती सीमा और संसाधन कोटा क्षति को कम कर सकते हैं, लेकिन पैच सत्यापन के लिए निष्कर्ष के रूप में उपयोग नहीं किया जा सकता है।

3.5 पहले Next.js उसी विंडो में गंभीर समस्या

निम्नलिखित आइटमों का उद्देश्य लापता तैनाती से बचना है जो अभी भी अगस्त-सितंबर से पहले के संस्करणों पर अटके हुए हैं; अभी तालिका में पुराने फिक्स थ्रेशोल्ड तक जाने की अनुशंसा नहीं की जाती है।

दिनांकपहचानकर्ता/परिदृश्यपहला सुधार; वर्तमान कार्रवाई
2026-08-25GHSA-2xp9-vwfh-vxw4: AVIF छवि अनुकूलन मूल पुस्तकालय RCE, Critical15.5.24 / 16.3.3; अब 15.5.28 / 16.4.1 S13
2026-08-25CVE-2026-75604: RCE, Critical जब Pages Router और App Router का उपयोग Windows पर एक साथ किया जाता है, और Cache Components सक्षम नहीं है; संस्करण >=13.4.0 <15.5.24, >=16.0.0 <16.3.315.5.24 / 16.3.3; Linux/macOS इस विशिष्ट Windows समस्या S14 से प्रभावित नहीं हैं
2026-09-22GHSA-vcvr-r3jv-pc5j: next/og में Node छवि-जनरेशन पथ अविश्वसनीय SVG, Critical को संसाधित करता है; 16.2.0—16.3.516.3.6; Edge कार्यान्वयन इस मुद्दे के दायरे से बाहर है, और 15.x इस RCE S15 के लिए प्रभावित शाखा नहीं है

4. Java इकोसिस्टम: रनटाइम ट्रस्ट, कंटेनर और फ्रेमवर्क को अलग से संभाला जाता है

4.1 JDK: नियमित CPU और CVE-2026-91403 दो स्तरीय अपडेट हैं

20 अक्टूबर को Oracle CPU के लिए Java SE जोखिम मैट्रिक्स में 55 नए सुरक्षा पैच सूचीबद्ध हैं, जिनमें से 49 को प्रमाणीकरण के बिना नेटवर्क पर शोषण योग्य के रूप में चिह्नित किया गया है। इसका मतलब यह नहीं है कि 55 Critical हैं, न ही इसका मतलब यह है कि प्रत्येक Java वेब सेवा के लिए 49 सीधे शोषण योग्य RCE पथ हैं; इसे मैट्रिक्स में घटकों, एपीआई, उपयोगकर्ता इंटरैक्शन और परिनियोजन स्थितियों के संयोजन के साथ समझा जाना चाहिए। S16

अगले दिन का CVE-2026-91403 (CVSS 3.1 9.1) एक अन्य प्रकार के जोखिम से संबंधित है: eMudhra घटना से संबंधित मध्यवर्ती CA का एक सेट जिस पर अब भरोसा नहीं किया जाता है। यह TLS सहकर्मी प्रमाणीकरण और संचार गोपनीयता/अखंडता को प्रभावित करता है और इसे JVM मेमोरी भ्रष्टाचार भेद्यता के रूप में वर्णित नहीं किया जा सकता है। S17

Oracle सलाहकार 20 अक्टूबर को जारी संस्करण को प्रभावित के रूप में सूचीबद्ध करता है, इसलिए 21 अक्टूबर को आउट-ऑफ-बैंड अपडेट को भी इंस्टॉल करने की आवश्यकता है। विशिष्ट संस्करण के लिए अनुभाग 2.2 देखें। GraalVM में संबंधित प्रभावित उत्पाद भी हैं, और निश्चित संस्करण इसके विशेष सुरक्षा बुलेटिन के अधीन होना चाहिए। S17S18

अस्थायी आधिकारिक उपाय: पहले बैकअप लें, और फिर प्रत्येक वास्तव में उपयोग किए गए ट्रस्टस्टोर से निर्दिष्ट रूट प्रमाणपत्र हटा दें:

  • emSign ECC Root CA - G3, Oracle उर्फ emsigneccrootcag3 [jdk]।
  • AAA Certificate Services, Oracle उर्फ comodoaaaca [jdk]। S19

JDK 11 और बाद का, आधिकारिक उदाहरण है:

keytool -delete -cacerts -alias "emsigneccrootcag3 [jdk]"
keytool -delete -cacerts -alias "comodoaaaca [jdk]"

इन आदेशों के लिए लक्ष्य JDKसेkeytool का उपयोग करें और पुष्टि करें कि वे एप्लिकेशन के वास्तविक ट्रस्ट स्टोर पर काम कर रहे हैं। Java 8 jre/lib/security/cacerts के अनुरूप पथ का उपयोग करता है; ट्रस्टस्टोर को अनुकूलित करने का काम अलग से किया जाना चाहिए, और अन्य प्रकाशकों के उपनाम अलग-अलग हो सकते हैं। रूट प्रमाणपत्र को हटाने से अस्वीकृति का दायरा बढ़ जाएगा, और वैध सेवा प्रमाणपत्र श्रृंखलाओं का प्रतिगमन-परीक्षण होगा। S19

अधिकारी निरस्तीकरण जाँच को सक्षम करने का विकल्प भी प्रदान करता है, लेकिन प्रभाव वास्तविक TLS कार्यान्वयन, निरस्तीकरण सेवा की पहुंच और विफलता रणनीति पर निर्भर करता है। सामान्य तैनाती के लिए, दो JVM स्विचों को सबूत के रूप में मानने से बचने के लिए पूर्ण विक्रेता अद्यतन स्थापित करने को प्राथमिकता दें कि सभी TLS लाइब्रेरीज़ को ठीक कर दिया गया है।

4.2 Tomcat: प्रमाणीकरण बायपास और क्रॉस-यूज़र अनुरोध अलगाव

निम्नलिखित तीन आइटम 2026-10-20 पर प्रकाशित किए गए थे; मरम्मत किए गए संस्करण की प्रविष्टि अक्टूबर 12 दिनांकित है। Apache का आधिकारिक ग्रेड Important है। S21S22S23

CVEप्रभावित संस्करणों की पुष्टि की गईआवश्यक परिदृश्य/परिणाम
CVE-2026-1012969.0.0.M1—9.0.122;10.1.0-M1—10.1.60;11.0.0-M1—11.0.26JNDIRealm गैर-जीएसएसएपीआई एसएएसएल प्रमाणीकरण तंत्र को कॉन्फ़िगर करता है, क्रेडेंशियल सत्यापन गायब है, और गलत पासवर्ड भी पास हो सकते हैं
CVE-2026-1013569.0.118—9.0.122;10.1.55—10.1.60;11.0.22—11.0.26HTTP/2 की एसिंक्रोनस सर्वलेट त्रुटि हैंडलिंग गलत तरीके से ऑब्जेक्ट को रीसायकल/पुन: उपयोग करती है, जिससे उपयोगकर्ताओं के बीच अनुरोध या प्रतिक्रियाएं मिश्रित हो जाती हैं
CVE-2026-103119केवल 11.0.0-M25-11.0.26 की पुष्टि करेंबड़े AJP नॉन-ब्लॉकिंग राइट्स के कारण बफर अंडर-रीड हो सकता है, जो बाद के अनुरोधों में पिछले प्रतिक्रिया डेटा को उजागर कर सकता है।

संबंधित फिक्स 9.0.123 / 10.1.61 / 11.0.27 है; घोषणा के अनुसार AJP को केवल Tomcat 11 के रूप में सूचीबद्ध किया गया है, और इसे समान समस्या वाली तीन शाखाओं तक विस्तारित नहीं किया जा सकता है। S21S22S23

JNDIRealm पैच वास्तविक प्रमाणीकरण प्रक्रिया में सत्यापन अंतर को ठीक करता है, जहां सत्यापन के बजाय “एप्लिकेशन लॉगिन इंटरफ़ेस सामान्य दिखता है” का उपयोग नहीं किया जा सकता है। सेवा के वास्तविक कॉन्फ़िगरेशन के लिए दायरे, एसएएसएल तंत्र की जांच की जानी चाहिए, और गलत पासवर्ड के लिए परीक्षण विफल होने चाहिए। S24

अंतरिम कार्यान्वयन सुझाव: प्रभावित प्रमाणीकरण पथ को अलग करें; जब व्यवसाय अनुमति देता है तो Tomcat की HTTP/2 प्रोसेसिंग को निलंबित कर दें; बेकार AJP बंद करें। केवल AJP पोर्ट तक सीधी पहुंच को प्रतिबंधित करने से यह साबित नहीं हो सकता है कि कानूनी फ्रंट प्रॉक्सी के माध्यम से प्रवेश करने वाला ट्रैफ़िक प्रभावित नहीं होगा। आधिकारिक अद्यतन के बाद, दो स्वतंत्र उपयोगकर्ताओं से अतुल्यकालिक समवर्ती अनुरोधों का परीक्षण यह पुष्टि करने के लिए किया जाना चाहिए कि पहचान और प्रतिक्रियाओं के बीच कोई क्रॉस-टॉक नहीं है।

संदर्भ: 4.3 Spring for GraphQL:CVE-2026-59285

सार्वजनिक दिनांक: 2026-08-20; High . प्रभावित 2.0.0 — 2.0.4 , मरम्मत की गई 2.0.5 ( OSS ) या 2.0.4.1 (व्यावसायिक सहायता) . S25

पेजिंग क्वेरीज़ में यह एक असुरक्षित डीसेरिएलाइज़ेशन जोखिम है। आधिकारिक आवश्यकता यह है कि निम्नलिखित शर्तों को एक ही समय में पूरा किया जाना चाहिए:

  1. Spring for GraphQL का प्रयोग करें।
  2. जैक्सन 2.x का उपयोग करके JSON को डिसेरिएलाइज़ करें।
  3. बाहरी दुनिया से कनेक्शन पेजिंग फ़ील्ड प्रदान करें।
  4. क्लासपाथ में विशिष्ट वर्ग होते हैं जो इंस्टेंशियेशन या डिसेरिएलाइज़ेशन के दौरान अप्रत्याशित तर्क निष्पादित कर सकते हैं।

शर्तें पूरी होने पर एक दुर्भावनापूर्ण GraphQL अनुरोध RCE का कारण बन सकता है। इसे “जैक्सन का उपयोग करने वाले सभी Java कार्यक्रमों का शोषण किया जा सकता है” तक कम नहीं किया जा सकता है। S25

2.0.4 अपर्याप्त क्यों है: जून में, CVE-2026-41699 ने 2.0.4 जैसी पैच बेसलाइन दी थी, और अगस्त में घोषणा में स्पष्ट रूप से 2.0.4 को प्रभाव के नए दायरे में शामिल किया गया था। इसलिए, मरम्मत रिकॉर्ड को बाद की घोषणाओं के अनुसार अद्यतन किया जाना चाहिए, और पुराने CVE के न्यूनतम संस्करण का उपयोग नहीं किया जा सकता है। S26

जब अपग्रेड अस्थायी रूप से अनुपलब्ध होता है, तो अविश्वसनीय कॉल करने वालों के लिए पहुंच वाले प्रभावित पेजिनेशन फ़ील्ड को निलंबित किया जा सकता है; डिसेरिएलाइज़ेबल प्रकारों और वर्ग पथों को सीमित करना एक गहन उपाय है। प्रतिगमन में कानूनी कर्सर, पृष्ठांकित परिणाम और अपवाद इनपुट अस्वीकृतियां शामिल होनी चाहिए, और अंतिम एप्लिकेशन JAR के भीतर वास्तविक घटक संस्करणों की जांच करनी चाहिए।

4.4 Spring Security: CVE-2026-59270 और संबंधित प्रमाणीकरण जोखिम

CVE-2026-59270, 2026-08-20, Critical. एम्बेडेड UnboundIdContainer डिफ़ॉल्ट रूप से ज्ञात व्यवस्थापक क्रेडेंशियल पंजीकृत करता है और सभी नेटवर्क इंटरफेस पर सुनता है। जब घटक सक्षम होता है और पोर्ट पहुंच योग्य होता है, तो एक हमलावर निर्देशिका डेटा को पढ़ या संशोधित कर सकता है; जो परियोजनाएं आम तौर पर Spring Security पेश करती हैं, वे स्वचालित रूप से LDAP को उजागर नहीं करेंगी। S27

प्रभावित क्षेत्र:

शाखाप्रभावितपहला फिक्स/अधिग्रहण चैनल
7.17.1.07.1.1 OSS; वाणिज्यिक 7.1.0.1 भी
7.07.0.0—7.0.67.0.7 OSS; वाणिज्यिक 7.0.6.1 भी
6.5 / 6.46.5.0—6.5.11;6.4.0—6.4.186.5.12/6.4.19, वाणिज्यिक
5.8 / 5.75.8.0—5.8.27;5.7.0—5.7.255.8.28/5.7.26, वाणिज्यिक

स्रोत: S27. spring.ldap.embedded.* स्वचालित कॉन्फ़िगरेशन और प्रत्यक्ष इंस्टेंटेशन कोड का समस्या निवारण करें; जब उत्पादन के लिए इसकी आवश्यकता न हो तो घटक को बंद कर दें, और वास्तविक सुनने के पते की जाँच करें। जब व्यवसाय को वास्तव में इसकी आवश्यकता हो, तो पहले कॉलिंग स्रोतों को सीमित करें और फिर घटक अपग्रेड को पूरा करें।

**संबंधित प्रमाणीकरण समस्या: CVE-2026-47841 (High).**WebAuthn उपयोगकर्ता प्रमाणीकरण REQUIRED पर सेट है, और HTTP सत्र वितरित भंडारण द्वारा क्रमबद्ध होने के बाद, गलत ऑब्जेक्ट पहचान तुलना प्रमाणीकरण आवश्यकता को अमान्य कर सकती है। हमले के लिए हमलावर के पास उपयोगकर्ता प्रमाणक डिवाइस का होना भी आवश्यक है, न कि डिवाइस के बिना मनमाने ढंग से रिमोट लॉगिन की। 7.1, 7.0, 6.5, और 6.4 के संबंधित प्रभावित संस्करणों के लिए, पैच बेसलाइन उपरोक्त तालिका में इन शाखाओं के अनुरूप है; सत्यापन में क्रॉस-नोड सत्र शामिल होने चाहिए और फिर भी पिन/बायोमेट्रिक सत्यापन की आवश्यकता होगी। S28

5. Python पारिस्थितिकी तंत्र: दुभाषिया, मानक पुस्तकालय, रूपरेखा और प्रमाण पत्र

5.1 CVE-2026-19445: SNI कॉलबैक में SSLContext UAF

प्रकाशन दिनांक: 2026-09-30; PSF स्तर: Critical. Python सर्वर TLS में, sni_callback कनेक्शन को दूसरे SSLContext पर स्विच करता है, और जब मूल संदर्भ में कोई अन्य जीवित संदर्भ नहीं होता है, तो अप्रमाणित TLS क्लाइंट सेवा को क्रैश कर सकता है या किसी रिलीज़ किए गए ऑब्जेक्ट में पॉइंटर को कॉल कर सकता है। S29

मूल बात यह है कि Python ऑब्जेक्ट अंतर्निहित TLS कॉलबैक जीवन चक्र के साथ असंगत है। मूल संदर्भ जारी कर दिया गया है, और अंतर्निहित परत अभी भी कॉलबैक के लिए आवश्यक स्थिति को बनाए रख सकती है; संदर्भ जीवन चक्र को ठीक करने के लिए दुभाषिया देशी पैच का उपयोग करने की आवश्यकता है। S47

स्कोप: Python कोड जो केवल TLS क्लाइंट के रूप में कार्य करता है, इस आइटम से प्रभावित नहीं होता है; मूल संदर्भ को लंबे समय तक रखने वाले श्रवण सॉकेट का सामान्य मोड घोषणा में वर्णित विशिष्ट विफलता पथ में नहीं आता है। Nginx TLS को समाप्त करने के बाद, यह केवल स्थानीय HTTP को Python को सौंपता है, और Python सीधे SNI को स्वयं संभालता है, जो एक अलग हमले की सतह है। S29

3.10—3.14 निश्चित संस्करण के अनुरूप, अनुभाग 2.3. देखें। 3.15 के आधिकारिक संस्करण की मरम्मत की गई है, और 3.15.1 को वास्तव में चुना जा सकता है। केवल pip निर्भरता को अद्यतन करने से दुभाषिया के _ssl कार्यान्वयन को प्रतिस्थापित नहीं किया जा सकता है। S33S35S47

आधिकारिक अस्थायी शमन: उन सभी SSLContext के लिए मजबूत संदर्भ रखता है जिन्होंने सर्वर जीवन चक्र के अंत तक SNI कॉलबैक सेट किया है। इसमें वास्तविक गतिशील निर्माण और स्विचिंग पथ को कवर करने की आवश्यकता है; कस्टम ओपनएसएसएल 1.1.1 बिल्ड को आधिकारिक इश्यू रिकॉर्ड के साथ पुन: बातचीत की शर्तों की भी जांच करनी चाहिए और अपडेट को पूरा करने को प्राथमिकता देनी चाहिए। S29S47

5.2 CVE-2026-19553: होस्टनाम ध्वज चालू है, लेकिन कॉल करते समय होस्टनाम गायब है

सार्वजनिक दिनांक: 2026-09-30; High. जबSSLContext.check_hostname=True, यदि wrap_bio() server_hostname में पारित नहीं हुआ है, तो मूल कार्यान्वयन चुपचाप होस्टनाम सत्यापन को छोड़ सकता है। सफल प्रमाणपत्र श्रृंखला सत्यापन का मतलब यह नहीं है कि लक्ष्य डोमेन नाम का भी मिलान हो गया है। S30

निवारण के लिए दोनों चरणों की आवश्यकता है:

  • अनुभाग 2.3. में सूचीबद्ध दुभाषिया सुरक्षा रिलीज़ स्थापित करें
  • wrap_bio(), संबंधित asyncio.create_connection() / loop.start_tls() पथों की जांच करें, अपेक्षित और गैर-खाली होस्टनाम में स्पष्ट रूप से पास करें, और प्रमाणपत्र सत्यापन चालू रखें। S30

**संगतता अंतर जिन्हें छोड़ा नहीं जा सकता:**3.10, 3.11, 3.12 संगतता के लिए हैं, केवल DeprecationWarning कुछ मामलों के लिए जारी किया जाता है जहां होस्टनाम गायब है; 3.13 और बाद में ValueError बढ़ाएँ। 3.12 बैकपोर्ट भी None को खाली स्ट्रिंग्स से स्पष्ट रूप से अलग करता है: None के लिए एक नई चेतावनी जोड़ी गई है, और खाली स्ट्रिंग्स के लिए एक त्रुटि अभी भी रिपोर्ट की गई है। इसलिए, निम्न-शाखा उपयोगकर्ता यह नहीं मान सकते हैं कि मूल रूप से गायब डोमेन नाम सत्यापन केवल अपग्रेड करके स्वचालित रूप से बहाल कर दिया गया है। S31S33

एक परीक्षण वातावरण में, बेमेल होस्टनाम के साथ एक विश्वसनीय-श्रृंखला प्रमाणपत्र का उपयोग करें और पुष्टि करें कि वास्तविक एप्लिकेशन TLS क्लाइंट इसे अस्वीकार कर देता है। केवल check_hostname बूलियन मान को पढ़ने से पूर्ण स्वीकृति नहीं मिलती है।

5.3 CVE-2026-82049: टारफाइल फिल्टर में लिंक संयोजन बायपास

सार्वजनिक दिनांक: 2026-09-14; High. CPython 3.13 और पहले से संबंधित कार्यान्वयन में, अविश्वसनीय टार में हार्ड लिंक और प्रतीकात्मक लिंक का संयोजन data / tar निष्कर्षण फ़िल्टर को बायपास कर सकता है, अनपैकिंग ट्री में अनपैकिंग निर्देशिका के बाहर फ़ाइलों की सामग्री को उजागर कर सकता है, या उनकी अनुमतियों और संशोधन समय को संशोधित करना। S32

इस भेद्यता के पुष्ट प्रभावों में फ़ाइल सामग्री एक्सपोज़र और मेटाडेटा संशोधन शामिल हैं; ये प्रभाव अकेले बाहरी फ़ाइल सामग्री की मनमानी ओवरराइटिंग या RCE के बिना शर्त कार्यान्वयन को प्रदर्शित करने के लिए पर्याप्त नहीं हैं।

संबंधित पैच बेसलाइन के लिए 3.10 — 3.13 , खंड देखें 2.3. Python 3.14 के कारण इस विशिष्ट मुद्दे से छूट दी गई है os.link() तब से व्यवहार बदल जाता है 3.14.0b1 , तो का प्रभावित दायरा 3.10 — 3.13 उपरोक्त शाखा लागू नहीं होती. S33

अस्थायी और गहन उपाय: अविश्वसनीय अभिलेखागार के स्वचालित निष्कर्षण को निलंबित करता है; जब व्यवसाय को संसाधित करना हो तो अलग-थलग कम-विशेषाधिकार प्राप्त कार्यकर्ता प्रक्रियाओं और नई विशिष्ट निर्देशिकाओं का उपयोग करें, व्यवसाय द्वारा प्रतीकात्मक लिंक, हार्ड लिंक और डिवाइस प्रविष्टियों को अस्वीकार करें, और फ़ाइलों और डीकंप्रेसन संसाधनों की संख्या को सीमित करें। ये परिनियोजन सिफ़ारिशें हैं.

filter="data" पूर्ण विश्वास रणनीति की तुलना में सामान्य अविश्वसनीय अभिलेखागार के लिए अधिक उपयुक्त है, लेकिन पुराने संस्करण के फ़िल्टर में भी यह भेद्यता है, और अकेले इस पैरामीटर को जोड़ने से अद्यतन को प्रतिस्थापित नहीं किया जा सकता है। फ़िल्टर पूर्ण फ़ाइल सिस्टम सैंडबॉक्स भी नहीं है. S32S45

5.4 अनुपूरक जोखिम: CVE-2026-114583 (Medium) और पैच रिलीज़ स्थिति

PSF ने 2026-10-22 में खुलासा किया कि tarfile.tar_filter के विशिष्ट लिंक नामों के प्रसंस्करण को बायपास किया जा सकता है, जिससे बाद के सदस्यों को अनपैकिंग निर्देशिका के बाहर लिखने की अनुमति मिलती है, एक स्तर के साथ Medium। उस दिन आधिकारिक फिक्स PR का विलय कर दिया गया था; 23 अक्टूबर, 2026 तक, इस प्रतिबद्धता से संबंधित किसी भी आधिकारिक रखरखाव रिलीज़ की पुष्टि नहीं की गई है। S40

इसलिए:

  • यह आइटम Medium के रूप में अलग से सूचीबद्ध है।
  • 21 अक्टूबर को जारी किए गए दुभाषिया संस्करणों में यह सुधार शामिल नहीं माना जा सकता है।
  • वह प्रक्रिया जो अभी भी अविश्वसनीय अभिलेखागार को संभालने के लिए filter="tar" का उपयोग करती है, उसे रिलीज़ बैकपोर्ट को ट्रैक करना चाहिए; इस प्रसंस्करण पथ को थोड़े समय के लिए अलग करें या निलंबित करें। data पर स्विच करते समय और लिंक को अस्वीकार करते समय, आपको यह भी पुष्टि करनी होगी कि यह व्यावसायिक आवश्यकताओं को पूरा करता है, और फ़िल्टर को बदलने को बिना शर्त सैंडबॉक्स के रूप में वर्णित नहीं किया जा सकता है।

5.5 GeoDjango: CVE-2026-15307 और अक्टूबर में बाद के सुधार

2026-08-04, Django आधिकारिक High. स्थानिक क्वेरी स्पष्ट रूप से GDALRaster को कुछ स्ट्रिंग/शब्दकोश भेजती है, और ड्राइवर फ़ाइलें लिख सकता है या नेटवर्क अनुरोध शुरू कर सकता है; RCE तब बन सकता है जब विशिष्ट पथ और बाद की निष्पादन स्थितियाँ हों। स्थानिक क्षेत्र मॉडल देखने की अनुमति वाले कर्मचारी भी व्यवस्थापक चेंजलिस्ट के माध्यम से इस पथ तक पहुंच सकते हैं। S38

प्रारंभिक सुधार 5.2.17 / 6.0.8 है, जो स्थानिक लुकअप द्वारा स्वीकृत इनपुट प्रकारों को प्रतिबंधित करता है। यह परिवर्तन रैस्टर को व्यक्त करने के लिए स्ट्रिंग/शब्दकोश का उपयोग करने के मूल व्यवसाय को प्रभावित कर सकता है; केवल GDALRaster में अविश्वसनीय इनपुट लपेटने का मतलब इसे सत्यापित करना नहीं है। S38

6 अक्टूबर को, CVE-2026-87890 (मध्यम) की मरम्मत की गई: बाइट्स में व्यक्त वीआरटी बाहरी संसाधनों को संदर्भित कर सकता है और फिर भी नेटवर्क अनुरोधों को ट्रिगर कर सकता है; उसी दिन, CVE-2026-15830 की नेस्टेड ज्योमेट्री DoS सुरक्षा को भी मजबूत किया गया। बाद वाले दो को नए उच्च जोखिम वाले RCE का वर्णन करने के लिए अपग्रेड नहीं किया जा सकता है, लेकिन संकेत मिलता है कि तैनाती बेसलाइन 5.2.18 / 6.0.9 / 6.1.2 होनी चाहिए। S39

कार्यान्वयन एपीआई और प्रशासन इंटरफ़ेस के दो प्रवेश बिंदुओं की जांच करता है, अविश्वसनीय स्थानिक लुकअप, फ़ाइल लिखने की अनुमति और आउटबाउंड पहुंच को प्रतिबंधित करता है; अद्यतन करने के बाद, प्रतिगमन-परीक्षण वैध स्थानिक प्रश्नों और निषिद्ध इनपुट की अस्वीकृति। सामान्य Django एप्लिकेशन जो GeoDjango का उपयोग नहीं करते हैं उन्हें सीधे इस RCE निष्कर्ष को लागू नहीं करना चाहिए।

5.6 certifi / pip: प्रमाणपत्र ट्रस्ट को प्रत्येक प्रति को कवर करना होगा

GHSA-6q48-6c7w-9gw2, 2026-10-20, Critical, ज्ञात CVE सूचीबद्ध नहीं है। यह eMudhra इंटरमीडिएट CA घटना के कारण होने वाला प्रमाणपत्र अविश्वास अद्यतन है। इसे HTTPS के क्रिप्टोग्राफी तंत्र के रूप में संक्षेपित नहीं किया जा सकता है या कि सभी रूट प्रमाणपत्र क्रैक हो गए हैं। S36

certifi एडवाइजरी में मूल रूप से 2026.10.18 को पैच के रूप में सूचीबद्ध किया गया था; PSF ने बाद में स्पष्ट रूप से अप्रभावित रूट प्रमाणपत्रों के साथ संगतता बनाए रखने के लिए 2026.10.19 की सिफारिश की। ऑपरेटिंग बेसलाइन .19 है। S36S37

अंतर करने की आवश्यकता:

सामग्री स्थान पर भरोसा रखेंआपको अलग से जाँच करने की आवश्यकता क्यों है?
ऑपरेटिंग सिस्टम CA पैकेजछवि या होस्ट के लिए सिस्टम ट्रस्ट सामग्री
वेनव में certifiCA bundle वास्तव में एप्लिकेशन या अनुरोध आदि द्वारा उपयोग किया जाता है।
pip बिल्ट-इन certifiबाहरी रूप से स्थापित certifi की तुलना में एक अलग प्रतिलिपि है
uv / अन्य पैकेजिंग उपकरणटूल के स्वयं के अपडेट और विश्वसनीय स्रोतों का पालन करें
अनुकूलित CA फ़ाइलें, पैकेज्ड स्नैपशॉटसिस्टम या पैकेज के लिए डिफ़ॉल्ट विश्वसनीय स्रोतों को ओवरराइड करना जारी रख सकता है

उपरोक्त विभिन्न पैकेजिंग स्थानों पर आधारित एक चेकलिस्ट है। PSF को संबंधित टूल, मौजूदा वर्चुअल वातावरण को अपडेट करने और छवि के पुनर्निर्माण की आवश्यकता है; केवल होस्ट CA को अपडेट करना या इंटरप्रेटर को फिर से इंस्टॉल करना यह साबित नहीं कर सकता कि सभी प्रतियां ताज़ा कर दी गई हैं। S35S37

पुराने pip सुरक्षित बूटस्ट्रैप से अपग्रेड करते समय, PSF फिक्स्ड व्हील और SHA-256 के लिए कमांड प्रदान करता है, परिशिष्ट S37 देखें। प्रमाणपत्र समस्याओं को बायपास करने के लिए TLS सत्यापन को बंद न करें या --trusted-host को न जोड़ें।

6. औपचारिक निवारण प्रक्रिया

निम्नलिखित आदेश पुष्टि किए गए विश्वसनीय वातावरण के लिए हैं। निष्पादित करते समय, परस्पर विरोधी लॉक फ़ाइलें उत्पन्न करने के लिए npm/pnpm/yarn या pip/uv/Poetry के मिश्रण से बचने के लिए प्रोजेक्ट के मौजूदा पैकेज मैनेजर, लॉक फ़ाइल और परिनियोजन प्रक्रिया को संयोजित किया जाना चाहिए।

पहले एक अपवाद को संभालें: यदि आपको संदेह है कि पर्यावरण ने धारा 9 में समझौता किए गए पैकेज को चलाया है, तो पहले इसे अलग करें और एक स्वच्छ वातावरण से डिस्क, लॉक फ़ाइल और छवि रिकॉर्ड की जांच करें; पहले निम्न Python/pip कमांड न चलाएँ। S41

6.1 एक ऐसा बहीखाता स्थापित करें जो वास्तविक ट्रैफ़िक के अनुरूप हो सके

प्रत्येक सेवा कम से कम रिकॉर्ड करती है:

  • बाहरी प्रवेश बिंदु, रिवर्स प्रॉक्सी, मूल साइट से सीधा कनेक्शन पथ और पृष्ठभूमि कतार/अनुसूचित कार्य।
  • वास्तविक स्टार्टअप कमांड, रनिंग अकाउंट, बाइनरी पथ, प्रक्रिया या कंटेनर पहचान।
  • रनटाइम पूर्ण संस्करण, प्रकाशक/रिपोजिटरी, पैकेज पूर्ण संस्करण, या छवि डाइजेस्ट।
  • फ़्रेमवर्क और ट्रांजिटिव निर्भरताएँ, लॉक फ़ाइलें, मूल लाइब्रेरी और ट्रस्ट स्टोर पथ।
  • भेद्यता की स्थिति मौजूद है या नहीं, इसके अनुरूप, पैच लक्ष्य, पुनरारंभ दायरा, जिम्मेदार व्यक्ति और सत्यापन परिणाम।

विकास मशीनों, सीआई रनर, बिल्ड कंटेनर और पृष्ठभूमि कार्यों को भी अविश्वसनीय सामग्री के उनके पथ के अनुसार जांचा जाना चाहिए; केवल सार्वजनिक-सामना वाले वेब कंटेनर को अपडेट न करें।

6.2 Node.js: पहले रनटाइम निर्धारित करें, फिर एप्लिकेशन निर्भरता अपडेट करें

वास्तविक सेवा परिवेश की जाँच करें:

node -p 'JSON.stringify({execPath:process.execPath,node:process.version,openssl:process.versions.openssl,brotli:process.versions.brotli},null,2)'
npm ls next react react-dom react-server-dom-webpack react-server-dom-parcel react-server-dom-turbopack sharp --all
npm audit --omit=dev

node -p को सेवा के वास्तविक निष्पादन योग्य या वास्तविक कंटेनर के भीतर निष्पादित किया जाना चाहिए; यह नई लॉन्च की गई प्रक्रियाओं की जाँच करता है और स्वयं यह साबित नहीं करता है कि पुराने कर्मचारी को बदल दिया गया है। Node मूल लाइब्रेरी संस्करण स्ट्रिंग को बनाए रखते हुए पैच को अंतर्निहित Brotli में जोड़ सकता है। इसलिए, यह निर्धारित करने के लिए कि इसकी मरम्मत की गई है या नहीं, केवल process.versions.brotli पर निर्भर न रहें। आपको इसे Node सुरक्षा संस्करण या विक्रेता के बैकपोर्ट साक्ष्य के साथ जोड़ना चाहिए। S2S4

npm ls का उपयोग वास्तविक निर्भरता वृक्ष को देखने के लिए किया जाता है; गुम पैकेज या सहकर्मी संघर्ष गैर-शून्य निकास कोड भी उत्पन्न कर सकते हैं, इसलिए आपको विशिष्ट आउटपुट पढ़ना चाहिए। npm audit का उपयोग निर्भरता जाँच सहायता के रूप में किया जाता है और यह Node बाइनरी और देशी लाइब्रेरी जाँच को प्रतिस्थापित नहीं कर सकता है।

Node 24के पर्यावरण को प्रबंधित करने के लिएmise का उपयोग करें, जिसे निम्नानुसार अद्यतन किया जा सकता है:

mise use -g [email protected]
mise exec [email protected] -- node -p 'process.version + " " + process.execPath'

mise use -g वैश्विक संस्करण को कॉन्फ़िगर करता है; प्रोजेक्ट के स्थानीय कॉन्फ़िगरेशन को अभी भी अलग से जाँचने की आवश्यकता है। यदि सेवा ने पुराने निरपेक्ष पथ, कंटेनर बेस छवि, या किसी भिन्न खाते के वातावरण को ठीक कर दिया है, तो संबंधित कॉन्फ़िगरेशन को अद्यतन किया जाना चाहिए और सेवा को पुनरारंभ करना होगा। कमांड स्वयं पुरानी चल रही प्रक्रिया को प्रतिस्थापित नहीं करता है। S43

Next प्रोजेक्ट में, चयनित शाखा के अनुसार संबंधित कमांड निष्पादित करें। Next 15 के लिए:

# Next 15 分支
npm install --save-exact [email protected]

Next 16 के लिए:

# Next 16 分支
npm install --save-exact [email protected]

React/RSC संगत निर्भरता, लॉक फ़ाइलें और अंतिम शार्प इंस्टेंस की जाँच करें, और फिर प्रोजेक्ट प्रक्रिया के अनुसार निर्माण करें। प्रतिलिपि प्रस्तुत करने योग्य इंस्टॉलेशन के लिए सीआई में अद्यतन लॉक फ़ाइल का उपयोग करें, और निर्माण के बाद चल रही छवि में संस्करण की जांच करें। इस आपात स्थिति के लिए डिफ़ॉल्ट समाधान के रूप में प्रमुख संस्करणों में अनियंत्रित स्वचालित मरम्मत का उपयोग न करें।

6.3 Java: प्रकाशक, वास्तविक JVM और एम्बेडेड घटकों को सत्यापित करें

प्रारंभिक सूची:

java -XshowSettings:properties -version

आउटपुट में java.home, java.runtime.version और प्रकाशक को वास्तव में सेवा द्वारा उपयोग किए जाने वाले JVM के साथ संरेखित किया जाना चाहिए। संलग्न अनुमति के साथ JVM के लिए, JDK के jcmd का उपयोग केवल लॉगिन शेल ही नहीं, बल्कि लक्ष्य प्रक्रिया की जांच करने के लिए किया जा सकता है।

विश्वसनीय परियोजनाओं में निर्भरता की जाँच करें और वास्तविक निर्माण उपकरणों के आधार पर चयन करें:

./mvnw dependency:tree '-Dincludes=org.apache.tomcat.embed:*,org.springframework.security:*,org.springframework.graphql:*'

./gradlew dependencyInsight --dependency tomcat-embed-core --configuration runtimeClasspath
./gradlew dependencyInsight --dependency spring-security-core --configuration runtimeClasspath
./gradlew dependencyInsight --dependency spring-graphql --configuration runtimeClasspath

ये बिल्ड कमांड प्लग-इन निष्पादित कर सकते हैं और निर्भरता को ऑनलाइन हल कर सकते हैं, और केवल विश्वसनीय प्रोजेक्ट पर ही चल सकते हैं। छवि में अंतिम JAR/WAR या वास्तविक JAR की जाँच करें और अंतिम आर्टिफैक्ट के लिए बिल्ड फ़ाइल घोषणाओं को प्रतिस्थापित न करें। Spring बूट एम्बेडेड Tomcat को एप्लिकेशन के पुनर्निर्माण की आवश्यकता है; सिस्टम में एक अलग Tomcat इंस्टॉलेशन को अपडेट करने से एप्लिकेशन पैकेज में कॉपी संशोधित नहीं होगी।

रनटाइम अपडेट होने के बाद, आइटम द्वारा अनुकूलित javax.net.ssl.trustStore, एप्लिकेशन-सेल्फ-लोडेड कीस्टोर, जेलिंक रनटाइम, ग्रेलवीएम/नेटिव इमेज और अन्य डिलीवरी फॉर्म की जांच करें। जिन अनुप्रयोगों में पहले से ही अनुकूलित ट्रस्ट सामग्री है, वे केवल इसलिए चेक समाप्त नहीं कर सकते क्योंकि JDK निर्देशिका नई हो जाती है।

6.4 Python: दुभाषिया-दर-दुभाषिया और आभासी वातावरण प्रसंस्करण

वास्तविक वेनव/कंटेनर के भीतर विश्वसनीय होने की पुष्टि की गई:

python - <<'PY'
import sys
import ssl
import importlib.metadata as metadata

print("executable:", sys.executable)
print("version:", sys.version)
print("openssl:", ssl.OPENSSL_VERSION)
print("verify_paths:", ssl.get_default_verify_paths())
for name in ("pip", "certifi", "Django", "urllib3", "Brotli", "litellm"):
    try:
        print(name + ":", metadata.version(name))
    except metadata.PackageNotFoundError:
        print(name + ": not installed")
PY

python -m pip --version
python -m pip check

यह स्क्रिप्ट केवल जानकारी एकत्र करती है और संस्करण योग्यता निर्धारण नहीं करती है। ssl.get_default_verify_paths() डिफ़ॉल्ट पथ जानकारी है और यह साबित नहीं कर सकता कि सभी तृतीय-पक्ष ग्राहक समान ट्रस्ट स्टोर का उपयोग करते हैं; एप्लिकेशन कॉन्फ़िगरेशन के आधार पर इसकी पुष्टि की जानी चाहिए।

परिशिष्ट S37 के विश्वसनीय pip बूट अपग्रेड को पूरा करने के बाद, प्रोजेक्ट बाधाओं के अनुसार प्रमाणपत्र निर्भरता को अपडेट करें, उदाहरण के लिए:

python -m pip install --upgrade 'certifi>=2026.10.19'

# 仅适用于当前就选择 Django 5.2 的项目
python -m pip install --upgrade 'Django>=5.2.18,<5.3'

python -m pip check

प्रोजेक्ट की आवश्यकताओं/लॉक फ़ाइल को उसी समय अद्यतन करने की आवश्यकता है, अन्यथा अगली तैनाती पुराने संस्करण पर वापस आ सकती है। uv, पोएट्री, या एंटरप्राइज़ पैकेज रिपॉजिटरी का उपयोग करते समय, उनकी मौजूदा लॉकिंग और प्रकाशन प्रक्रियाओं का उपयोग करें; केवल उत्पादन कंटेनर के भीतर पैकेजों को मैन्युअल रूप से संशोधित न करें।

प्रोजेक्ट के मौजूदा pip-audit वर्कफ़्लो का उपयोग किसी विश्वसनीय वातावरण में ज्ञात निर्भरता कमजोरियों की जाँच के लिए किया जा सकता है; यह एक दुर्भावनापूर्ण कोड स्कैनर नहीं है और सभी दुभाषिया, सिस्टम लाइब्रेरी और ट्रस्ट स्टोर जोखिमों को कवर नहीं करता है। S44

सिस्टम /usr/bin/python3 को नए संकलित संस्करण की ओर इंगित करने के लिए बाध्य करने की अनुशंसा नहीं की जाती है। सिस्टम Python पर निर्भर प्रबंधन टूल को तोड़ने से बचने के लिए रिलीज़ सुरक्षा अपडेट या प्रोजेक्ट आइसोलेशन रनटाइम का उपयोग करें। यह एक कार्यान्वयन विकल्प है और इस भेद्यता के लिए कोई अतिरिक्त समाधान आवश्यकता नहीं है।

6.5 चल रहे इंस्टेंस को फिर से बनाएं और बदलें

यह अनुशंसा की जाती है कि संपूर्ण परिवर्तन के रूप में निम्नलिखित कदम उठाए जाएं:

  1. मूल विश्वसनीय स्रोत से पैच प्राप्त करें और संस्करण/हैश और निर्भरता लॉक को सहेजें।
  2. निकट-उत्पादन परिवेश में मुख्य फ़ंक्शन लौटाएं और पुष्टि करें कि मूल एक्सटेंशन JVM/फ्रेमवर्क के साथ संगत हैं।
  3. रनटाइम, एप्लिकेशन निर्भरता और वास्तविक ट्रस्ट स्टोर को अपडेट करें; कंटेनर के लिए आधार छवि और सिस्टम CA को ताज़ा करें, केवल पुरानी परत का पुन: उपयोग न करें।
  4. एप्लिकेशन और छवियों का पुनर्निर्माण करें, और सेवा, कार्यकर्ता, कतार उपभोक्ता और निर्धारित कार्य उदाहरणों को रोलिंग आधार पर बदलें।
  5. नए चल रहे इंस्टेंस में संस्करण और कॉन्फ़िगरेशन को दोबारा जांचें और पुष्टि करें कि सभी पुरानी प्रतियां बाहर निकल गई हैं।
  6. त्रुटि दर, विलंबता, CPU/मेमोरी, TLS हैंडशेक विफलताओं और प्रक्रिया क्रैश का निरीक्षण करें।

रोलबैक में सुरक्षित रनटाइम और पैच निर्भरता को बनाए रखने और एप्लिकेशन कॉन्फ़िगरेशन या व्यावसायिक परिवर्तनों को वापस लाने को प्राथमिकता दी जानी चाहिए। यदि आपको कमजोरियों वाले किसी पुराने उत्पाद पर लौटना है, तो संबंधित प्रवेश प्रतिबंध एक साथ बहाल किया जाना चाहिए, और जिम्मेदार व्यक्ति और न्यूनतम पुनर्प्राप्ति अवधि को स्पष्ट रूप से परिभाषित किया जाना चाहिए।

7. अस्थायी शमन और पैच चयन

7.1 अस्थायी उपायों की कवरेज सीमा

घोषित उपयोग शर्तों के आधार पर निम्नलिखित कार्यान्वयन सुझाव हैं। जब तक आधिकारिक योजना का उल्लेख नहीं किया जाता है, विक्रेता यह गारंटी नहीं देता है कि सभी वेरिएंट को पूरी तरह से ब्लॉक किया जा सकता है।

जोखिमअस्थायी उपाय जो किये जा सकते हैंइसके आधार पर जिस भाग को पूर्ण नहीं माना जा सकता
Brotli डिकोडिंगअविश्वसनीय इनपुट डिकोडिंग बंद करें; इनबाउंड और आउटबाउंड स्वचालित डीकंप्रेसन की जाँच करेंइनबाउंड WAF या प्रतिक्रिया संपीड़न को बंद करने से सभी डिकोडिंग प्रविष्टियाँ S3 शामिल नहीं होती हैं
Next.js typed arrays RCEतुरंत अपग्रेड करें; यदि आवश्यक हो तो प्रभावित सेवाओं को अस्थायी रूप से अलग करेंकोई आधिकारिक विश्वसनीय सार्वभौमिक समाधान S9 नहीं है
Next.js SVG RCEआधिकारिक योजना: वास्तविक तीव्र ≥0.35.5 सुनिश्चित करें; जब व्यवसाय अनुमति देता है तो प्रासंगिक अनुकूलन प्रवेश बिंदुओं को निलंबित कर देंअन्य Next/RSC मुद्दों को कवर नहीं करता है S11
Tomcat क्षेत्र / HTTP/2 / AJPसंबंधित पथ को अलग करें और अनावश्यक कनेक्टर बंद करेंअभी भी संबंधित शाखा मरम्मत पैकेज S21S22S23 की आवश्यकता है
GraphQL अक्रमांकनप्रभावित कनेक्शन फ़ील्ड निलंबित करें; अविश्वसनीय कॉल करने वालों को प्रतिबंधित करेंकेवल अनुरोध लंबाई सीमा प्रकार/डीसेरिएलाइज़ेशन समस्या S25 को ठीक नहीं कर सकती
Spring embedded LDAPआवश्यकता न होने पर अक्षम करें; वास्तविक श्रवण पोर्ट की पहुंच सीमित करेंडिफ़ॉल्ट प्रशासनिक पहचान और निर्देशिका अखंडता को अभी भी S27 की जाँच करने की आवश्यकता है
CPython SNI UAFआधिकारिक योजना: सेवा के अंत तक प्रासंगिक SSLContext मजबूत संदर्भ रखेंसभी निर्माण/स्विच पथ S29 द्वारा कवर किए जाने चाहिए
Python होस्टनाम छोड़ेंआधिकारिक समाधान: अपेक्षित सर्वर_होस्टनाम सही ढंग से पास करेंकेवल check_hostname फ़्लैग की जाँच नहीं कर सकते या चेतावनी को अनदेखा नहीं कर सकते S30S31
अविश्वसनीय टारनिष्कर्षण को अक्षम/संगरोध करें, गैर-आवश्यक लिंक और डिवाइस प्रविष्टियों को अस्वीकार करेंन तो फ़िल्टर और न ही संसाधन कोटा सार्वभौमिक सैंडबॉक्स हैं S32S40S45
प्रमाणपत्र विश्वास घटनासही CA सामग्री को अपडेट करें; Java ट्रस्ट को आधिकारिक शमन के अनुसार प्रतिबंधित किया जा सकता हैTLS सत्यापन को अक्षम करने से जोखिम बढ़ जाता है S19S37

7.2 डिलीवरी विधि के आधार पर पैच का चयन करें

वितरण विधिमरम्मत के तरीकों को प्राथमिकता देंसबूत जिन्हें बरकरार रखा जाना चाहिए
वितरण-प्रबंधित रनटाइमनिर्माता के संबंधित सुरक्षा अद्यतनपूर्ण पैकेज संस्करण, घोषणा, भंडार स्रोत
आधिकारिक बाइनरी/रनटाइम मैनेजरउसी शाखा से आधिकारिक सुरक्षा विज्ञप्तिसंस्करण, स्रोत और डाइजेस्ट, वास्तविक निष्पादन पथ
स्व-संकलित Node / CPythonमिलान शाखा का आधिकारिक स्रोत रिलीज़ या विक्रेता का पूरा पैच सेटप्रतिबद्ध सेट, निर्माण पैरामीटर, आश्रित पुस्तकालय और प्रतिगमन परिणाम
Spring / Next / Djangoइन-ब्रांच अपडेट, निर्भरता लॉक के पुनर्निर्माण और अंतिम अनुप्रयोगों के साथ संगतअंतिम निर्भरता वृक्ष, JAR/पैकेज/छवि में वास्तविक संस्करण
कस्टम ट्रस्ट स्टोरआधिकारिक निकासी योजना या विक्रेता अद्यतन निकासी की पुष्टि करता हैवास्तविक उपयोग पथ, सामग्री परिवर्तन, TLS सफलता और अस्वीकृति परीक्षण
एक समझौतापूर्ण वातावरणस्वच्छ और भरोसेमंद उत्पादों से पुनर्निर्माण करें और घटना की अलग से जांच करेंऐतिहासिक पैकेज/इमेज डाइजेस्ट, इंस्टॉलेशन रिकॉर्ड, क्रेडेंशियल रोटेशन रिकॉर्ड

7.3 कुंजी पैच तंत्र और समीक्षा फोकस

  • Brotli: इस बात पर ध्यान देता है कि बिल्ड में प्रवेश करने से पहले मूल डिकोडिंग स्थिति की सीमा जांच और त्रुटि वापसी पूरी हो गई है या नहीं; केवल JavaScript पैकेज को बदलने से स्थिर रूप से संकलित कोड को Node में नहीं बदला जा सकता है। S4
  • Node DNS/TLS: इनपुट अस्वीकृति, पता सामान्यीकरण, IP SAN और DNS पहचान के बीच अंतर और DNS कॉलबैक/वादा पर केंद्रित है। पार्सिंग पथ और TLS होस्टनाम मिलान परीक्षण। S5S6
  • Tomcat JNDIRealm: केवल निर्देशिका संदर्भ प्राप्त करने के बजाय, इस पर ध्यान केंद्रित करता है कि प्रमाणीकरण प्रक्रिया वास्तव में क्रेडेंशियल्स को सत्यापित करती है या नहीं; आधिकारिक संस्करण को प्राथमिकता देना और एकल स्रोत फ़ाइल प्रतिस्थापन को पूर्ण बाइनरी पैच के रूप में नहीं मानना। S24
  • CPython ssl: Python संदर्भ स्वामित्व और अंतर्निहित SSLContext के जीवन चक्र पर केंद्रित है; शाखा संगतता अंतर होने पर wrap_bio() बैकपोर्ट करता है, और आपको उपयोग की गई शाखा के वास्तविक कार्यान्वयन को पढ़ना चाहिए। S31S47
  • प्रमाणपत्र अविश्वास: ऐसे अपडेट विश्वसनीय सामग्री के रूप में प्रकट हो सकते हैं या स्पष्ट एपीआई परिवर्तनों के बजाय सूची परिवर्तनों से इनकार कर सकते हैं। Node के उसी बैच में प्रभावित मध्यवर्ती CA का अस्वीकृति तंत्र भी शामिल है; Java और Python के संबंधित ट्रस्ट स्रोतों को अभी भी अलग से सत्यापित करने की आवश्यकता है। S19S37S46

स्वतंत्र Brotli बाइंडिंग की भी जांच होनी चाहिए. Google अपस्ट्रीम जारी किया गया 1.0.10 / 1.1.1 / 1.2.1 ठीक करने के लिए उसी दिन CVE-2026-111497 . Python समान प्रभावित सी कार्यान्वयन को एम्बेड करने वाले मूल एक्सटेंशन या जेएनआई कलाकृतियों को स्वतंत्र रूप से अद्यतन/पुनर्निर्मित करने की आवश्यकता है; इससे यह अनुमान नहीं लगाया जा सकता कि सभी शुद्ध हैं Java डिकोडर प्रभावित होते हैं, न ही यह माना जा सकता है कि अपग्रेड हो रहा है Node अन्य भाषाओं में प्रतियों को स्वचालित रूप से बदल देता है। S42

8. सत्यापन और अनुवर्ती जांच

8.1 न्यूनतम सत्यापन चेकलिस्ट

वस्तुओं की जाँच करेंसाक्ष्य आवश्यक है
रनटाइमपूर्ण संस्करण या विक्रेता बैकपोर्ट साक्ष्य वास्तविक प्रक्रिया/कंटेनर में सही है
अनुप्रयोग निर्भरताएँNext/RSC/sharp, Tomcat/Spring, और Django/certifi अंतिम परिनियोजन उत्पाद संबंधित सीमा तक पहुंच गए हैं
प्रतिस्थापन सीमासभी कार्यकर्ता/JVM/कंटेनर प्रतियां और पृष्ठभूमि कार्यों को नए से बदल दिया गया है, और पुराने उदाहरण बाहर निकल गए हैं।
TLSवैध डोमेन प्रमाणपत्र सफल; बेमेल होस्टनाम और अमान्य श्रृंखलाएँ नीति के अनुसार विफल हो जाती हैं; कस्टम ट्रस्ट स्टोर शामिल हैं
eMudhra अविश्वासप्रभावित इंटरमीडिएट CA द्वारा निर्मित प्रमाणपत्र श्रृंखला को वास्तविक रनटाइम के दौरान अस्वीकार कर दिया गया था, या इस बात का सबूत है कि विशिष्ट विक्रेता की सुरक्षा बिल्ड/संबंधित अस्वीकृति सूची तैनात की गई है; सामान्य TLS परीक्षण या Java 8 लघु संस्करण संख्या के आधार पर मामले को बंद नहीं किया जा सकता है।
Node डिकोडिंग और छवियांसामान्य संपीड़ित प्रतिक्रिया, अपलोड, छवि अनुकूलन और RSC फ़ंक्शन उपलब्ध हैं; अविश्वसनीय स्रोत नीति प्रभावी है
Java प्रमाणीकरण और अलगावग़लत पासवर्ड अस्वीकृत; पहचान/प्रतिक्रिया मिश्रण के बिना स्वतंत्र उपयोगकर्ता समवर्ती अतुल्यकालिक अनुरोध; LDAP अपेक्षा के अनुरूप सुन रहा हूँ
Python SNI / पुरालेखसामान्य मल्टी-डोमेन नाम TLS व्यवसाय स्थिर है; संग्रह पथ ट्रैवर्सल और अस्वीकृत लिंक को अस्वीकार कर देता है, और निर्देशिका के बाहर की फ़ाइलों को संशोधित नहीं किया जाता है
डेटा और कार्यात्मक प्रतिगमनपेजिंग, स्थानिक क्वेरी, अनुमति जांच और पृष्ठभूमि कार्यों ने परियोजना के मौजूदा परीक्षणों को पास कर लिया
संसाधन और अवलोकनCPU, मेमोरी, त्रुटि दर, विलंबता और TLS त्रुटियों में कोई असामान्य वृद्धि नहीं हुई है।
पता लगाने की क्षमताअपग्रेड समय, पैकेज/इमेज डाइजेस्ट, कॉन्फ़िगरेशन परिवर्तन, सत्यापन परिणाम और अनसुलझे आइटम बचाएं

ये कार्यान्वयन स्वीकृति अनुशंसाएँ हैं और प्रत्येक CVE के लिए एक आक्रमण स्क्रिप्ट तैयार करने की आवश्यकता नहीं है। क्रैश, संसाधन समाप्ति और सीमा से बाहर संग्रह से जुड़े सत्यापन में अपस्ट्रीम रिग्रेशन परीक्षण या एक अलग वातावरण में प्रोजेक्ट नियंत्रित परीक्षण डेटा का उपयोग करना चाहिए।

8.2 पैचिंग और घुसपैठ की जांच अलग-अलग कार्य हैं

असामान्य डिकोडिंग त्रुटियों, वर्कर/JVM क्रैश, संदिग्ध फ़ाइल लेखन, निर्देशिका डेटा परिवर्तन, प्रमाणीकरण अपवाद, आउटबाउंड अनुरोध और क्रेडेंशियल उपयोग रिकॉर्ड के लिए मौजूदा लॉग की जाँच करें। इन संकेतों को संदर्भ में आंकने की आवश्यकता है: एक दुर्घटना या ओओएम सफल शोषण का प्रमाण नहीं है; अलर्ट की अनुपस्थिति यह साबित नहीं करती कि सिस्टम अप्रभावित था।

जब अनधिकृत संशोधन, समझौता किए गए क्रेडेंशियल्स, या पुष्टि की गई दुर्भावनापूर्ण निर्भरता की खोज की जाती है, तो साक्ष्य को संरक्षित किया जाना चाहिए, प्रासंगिक उदाहरणों को अलग किया जाना चाहिए, प्रभावित क्रेडेंशियल्स को एक विश्वसनीय वातावरण से घुमाया जाना चाहिए, और सिस्टम को फिर से बनाया जाना चाहिए। पैच हमलावर द्वारा प्राप्त किए गए टोकन को रद्द नहीं करेगा या संशोधित किए गए डेटा को पुनर्स्थापित नहीं करेगा।

9. आपूर्ति श्रृंखला सुरक्षा घटना: LiteLLM 1.107.0 समझौता

**आधिकारिक पुष्टि तिथि: 2026-10-21.**LiteLLM ने बताया कि इसकी रिलीज़ पाइपलाइन से समझौता किया गया था। PyPI के litellm==1.107.0 और उसी अवधि के कुछ डॉकर/GHCR उत्पादों में गुप्त चोरी और रिमोट कंट्रोल दुर्भावनापूर्ण कोड शामिल थे, और संबंधित उत्पादों को वापस ले लिया गया है। S41

प्रभाव का निर्धारण करने के लिए, आपको ऐतिहासिक स्थापना रिकॉर्ड और छवि डाइजेस्ट की जांच करनी चाहिए; latest, main-latest, और main-stable जैसे लेबल अब साफ छवियों की ओर इशारा करते हैं, जो यह साबित नहीं करता है कि घटना के समय खींचे गए उत्पाद साफ थे। उस समय आधिकारिक अनुशंसा अस्थायी रूप से 1.106.2 को पिन करने की थी; यह अनुशंसा इस घटना पर आधारित थी, और तैनाती के दौरान अन्य सुरक्षा घोषणाओं की अभी भी जाँच करने की आवश्यकता है। S41

उन परिवेशों के लिए जहां संबंधित उत्पाद स्थापित या चलाए गए हैं:

  1. इंस्टॉलेशन रिकॉर्ड, छवियों और लॉग को अलग और संरक्षित करें, और स्वच्छ वातावरण से उनका निरीक्षण करें।
  2. पहले संदिग्ध वातावरण में Python/pip प्रारंभ न करें; दुर्भावनापूर्ण .pth / sitecustomize.py को स्टार्टअप के बाद फिर से निष्पादित किया जा सकता है।
  3. विश्वसनीय स्रोतों से होस्ट, वेनव/कंटेनर का पुनर्निर्माण करें; केवल पैकेजों को अनइंस्टॉल या डाउनग्रेड नहीं कर सकता।
  4. वास्तविक पहुंच के आधार पर क्लाउड क्रेडेंशियल्स, एलएलएम प्रदाता कुंजियाँ, LiteLLM कुंजियाँ और डेटाबेस क्रेडेंशियल्स को निरस्त/घुमाएँ और असामान्य उपयोग की समीक्षा करें। S41

यह एक पुष्ट आपूर्ति श्रृंखला घटना है और इससे निपटते समय दुर्भावनापूर्ण कोड निष्पादन, क्रेडेंशियल रिसाव और दृढ़ता जोखिमों पर विचार करने की आवश्यकता होती है। 23 अक्टूबर 2026 तक, अधिकारी अभी भी प्रारंभिक घुसपैठ की जाँच कर रहे थे।

परिशिष्ट: उद्धृत स्रोत और लिंक

निम्नलिखित स्रोत सत्यापन तिथि 2026-10-23 है, जिसमें परियोजना की आधिकारिक सुरक्षा घोषणा, आधिकारिक कोड भंडार और विक्रेता के निर्देश शामिल हैं। मुख्य पाठ [Sx] इस परिशिष्ट से मेल खाता है; अपडेट करते समय, आपको यह जांचना चाहिए कि आपूर्तिकर्ता ने बाद के संशोधन जारी किए हैं या नहीं।

S1 — Node.js: 2026-10-21 सुरक्षा सूचना

  • उद्देश्य: चार रनटाइम High, शाखाओं को प्रभावित करना, अक्टूबर सुरक्षा रिलीज़।
  • संदर्भ: Official Security Bulletin

S2 - Node.js: तीन रखरखाव लाइनों के लिए आधिकारिक रिलीज़ निर्देश

  • उद्देश्य: 22.23.4, 24.22.1, 26.12.1 और वास्तविक मर्ज किए गए पैच की जाँच करें।
  • संदर्भ: Node.js 22.23.4
  • संदर्भ: Node.js 24.22.1
  • संदर्भ: Node.js 26.12.1

S3 — Vercel: Node.js Brotli RCE सुरक्षा सलाह

  • उद्देश्य: इनबाउंड/आउटबाउंड डिकोडिंग स्थितियां, WAF कवरेज सीमा, Node 20 स्थिति।
  • संदर्भ: Node.js security advisory: Brotli decoder RCE

S4 - Node.js: Brotli आधिकारिक पैच सबमिशन

  • उद्देश्य: मूल डिकोडिंग जाँच और त्रुटि प्रसार के लिए कार्यान्वयन आधार।
  • संदर्भ: Brotli Patch commit 49dff6f57a

S5 - Node.js: TLS पता सामान्यीकरण पैच

S6 — Node.js: DNS NUL सत्यापन पैच

S7 — Node.js: 2026-07-29 सुरक्षा सूचना

  • उद्देश्य: HTTP/2 मेमोरी थकावट, UAF और अनुमति मॉडल कमजोरियां।
  • संदर्भ: July 2026 Security Releases

S8 — Next.js: 2026-10-14 सुरक्षा अद्यतन

संदर्भ: S9 — Next.js:typed arrays / use cache RCE

  • उद्देश्य: GHSA-673q-mjm6-r5xr; अंतराल, स्थिति, स्कोर और समाधान स्थिति को प्रभावित करता है।
  • संदर्भ: Next.js Official Security Bulletin

संदर्भ: S10 — React:React Server Components RCE

  • उद्देश्य: GHSA-xqc2-xf4c-x3h3; तीन RSC पैकेजों के प्रभावित और निश्चित संस्करण।
  • संदर्भ: React Official Security Bulletin

संदर्भ: S11 — Next.js:SVG Image Optimization RCE

संदर्भ: S12 — Next.js:Server Actions DoS

  • उद्देश्य: GHSA-p3m5-59mp-jv5r; स्थितियों, संस्करणों और रेटिंग को प्रभावित करता है।
  • संदर्भ: Server Actions DoS Official Security Bulletin

S13 — Next.js: AVIF छवि अनुकूलन RCE

संदर्भ: S14 — Next.js:Windows RCE

संदर्भ: S15 — Next.js:next/og ImageResponse RCE

संदर्भ: S16 — Oracle: October 2026 CPU

S17 — Oracle: CVE-2026-91403 आउट-ऑफ़-बैंड अलार्म

  • उद्देश्य: 2026-10-21, JSSE प्रमाणपत्र ट्रस्ट जोखिम, प्रभावित उत्पाद और CVSS 3.1 9.1।
  • संदर्भ: Oracle Security Alert

S18 — Oracle: JDK आधिकारिक संस्करण और डाउनलोड

  • उद्देश्य: 20 अक्टूबर को CPU और 21 अक्टूबर को आउट-ऑफ-बैंड संस्करण के बीच अंतर करना; Java 8 के लघु संस्करण की सीमाओं को अलग करें।
  • संदर्भ: JDK release list
  • संदर्भ: Oracle Java Download page

S19 — Oracle: eMudhra अस्थायी निकासी योजना

  • उद्देश्य: अद्यतन 2026-10-22; दो रूट प्रमाणपत्र, कीटूल, कस्टम ट्रस्टस्टोर, और निरस्तीकरण जाँच।
  • संदर्भ: Distrusting eMudhra Intermediate Certificates in Oracle JDK

S20 - Eclipse Adoptium: रिलीज़ बिल्ड रिकॉर्ड

  • उद्देश्य: प्रमाणपत्र घटना के कारण Temurin को दोबारा पैक किया गया है; Oracle संस्करण प्रत्यय यांत्रिक रूप से लागू नहीं किया जा सकता है।
  • संदर्भ: Adoptium Release Scorecards

S21 - Apache Tomcat 9 सुरक्षा सूचना

  • उद्देश्य: 9.0.123 फिक्स के साथ 9-शाखा सटीक प्रभावित अंतराल।
  • संदर्भ: Tomcat 9 vulnerabilities

S22 - Apache Tomcat 10 सुरक्षा सूचना

  • उद्देश्य: 10.1 शाखा सटीक अंतराल और 10.1.61 मरम्मत; 10.0 EOL.
  • संदर्भ: Tomcat 10 vulnerabilities

S23 - Apache Tomcat 11 सुरक्षा सूचना

  • उद्देश्य: तीन आइटम Important, 11.0.27, AJP लागू दायरा और प्रकटीकरण/रिलीज की तारीख।
  • संदर्भ: Tomcat 11 vulnerabilities

S24 - Apache Tomcat: JNDIRealm पैच कमिट

  • उद्देश्य: प्रमाणन सत्यापन अंतराल की मरम्मत के लिए औपचारिक आधार।
  • संदर्भ: JNDIRealm Patch commit

संदर्भ: S25 — Spring:GraphQL CVE-2026-59285

संदर्भ: S26 — Spring:GraphQL CVE-2026-41699

  • उद्देश्य: पहले से निर्धारित सीमा, केवल यह समझाने के लिए कि आप पुरानी आधार रेखा पर क्यों नहीं रह सकते।
  • संदर्भ: 6 Month GraphQL Security Bulletin

संदर्भ: S27 — Spring Security:CVE-2026-59270

  • उद्देश्य: UnboundID LDAP एम्बेड करें, प्रबंधन पहचान ज्ञात करें और OSS/वाणिज्यिक संस्करण को अलग करें।
  • संदर्भ: Spring embedded LDAP Security Bulletin

संदर्भ: S28 — Spring Security:CVE-2026-47841

  • उद्देश्य: WebAuthn उपयोगकर्ता प्रमाणीकरण, सत्र क्रमांकन और आक्रमण परिसर।
  • संदर्भ: WebAuthn Security Bulletin

S29 — PSF: CVE-2026-19445 स्वतंत्र सुरक्षा सलाहकार

  • उद्देश्य: 2026-09-30, Critical, SNI SSLContext द्वारा उद्धृत स्थितियाँ और अस्थायी उपाय।
  • संदर्भ: SSLContext UAF Official announcement

S30 — PSF: CVE-2026-19553 स्वतंत्र सुरक्षा सलाहकार

S31 - CPython: रैप_बायो आधिकारिक पैच और 3.12 बैकपोर्ट

S32 — PSF: CVE-2026-82049 स्वतंत्र सुरक्षा सलाहकार

  • उद्देश्य: 2026-09-14, High, लिंक संयोजन, मेटाडेटा संशोधन और सामग्री एक्सपोज़र।
  • संदर्भ: tarfile link bypasses the official announcement

S33 - CPython: सितंबर के अंत/अक्टूबर की शुरुआत में आधिकारिक सुरक्षा रिलीज़

S34 — CPython: 3.10 अंतिम सुरक्षित रिलीज़

  • उद्देश्य: 3.10.22 और अपस्ट्रीम जीवन चक्र का अंत।
  • संदर्भ: Python 3.10.22

S35 — CPython: 2026-10-21 आपातकालीन रखरखाव संस्करण

  • उद्देश्य: 3.13.17 / 3.14.9 / 3.15.1, अंतर्निहित pip और certifi अपडेट, मौजूदा वेन आवश्यकताएँ।
  • संदर्भ: Python 3.13.17
  • संदर्भ: Python 3.14.9
  • संदर्भ: Python 3.15.1

S36 — certifi: emSign प्रमाणपत्र अविश्वास घोषणा

  • उद्देश्य: 2026-10-20, GHSA-6q48-6c7w-9gw2, Critical, कोई ज्ञात CVE नहीं।
  • संदर्भ: certifi Official Security Bulletin

S37 - PSF: Python उपयोगकर्ताओं पर eMudhra / emSign का प्रभाव

  • उद्देश्य: certifi .19 अनुशंसा, pip/uv बेसलाइन, SHA-256 के साथ विश्वसनीय बूट अपग्रेड कमांड।
  • संदर्भ: PSF Official event and upgrade instructions

S37 द्वारा उद्धृत आधिकारिक निर्देशों द्वारा प्रदान किया गया pip बूट अपग्रेड कमांड इस प्रकार है। केवल Python वातावरण में उपयोग किया जाए जिसके भरोसेमंद होने की पुष्टि की गई हो; यदि धारा 9 में विषाक्तता का संदेह है, तो घटना प्रक्रिया के अनुसार पहले अलग करें और पुनर्निर्माण करें। यह व्हील कंटेंट हैश को ठीक करता है और बाद में प्रोजेक्ट प्रक्रिया के अनुसार अन्य निर्भरता को अपडेट करता है।

python -m pip install "pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70"

S38 — Django: 2026-08-04 सुरक्षित रिलीज़

  • उपयोग: CVE-2026-15307, GeoDjango शोषण की स्थितियाँ, प्रारंभिक सुधार और अनुकूलता परिवर्तन।
  • संदर्भ: Django 6.0.8 / 5.2.17

S39 — Django: 2026-10-06 सुरक्षित रिलीज़

  • उद्देश्य: CVE-2026-87890, ज्यामिति DoS वर्तमान में चयनित आधार रेखा के साथ बाद में सुदृढीकरण।
  • संदर्भ: Django 6.1.2 / 6.0.9 / 5.2.18

S40 — PSF / CPython: नवीनतम tar_filter साइड नोट

  • उद्देश्य: 2026-10-22, CVE-2026-114583 (Medium); PR विलय का मतलब यह नहीं है कि आधिकारिक रखरखाव संस्करण जारी कर दिया गया है।
  • संदर्भ: PSF Independent Announcement
  • संदर्भ: CPython Patch PR #160098

S41 — LiteLLM: आधिकारिक आपूर्ति श्रृंखला घटना रिपोर्ट, 21 अक्टूबर

  • उद्देश्य: 1.107.0 दूषित उत्पाद, ऐतिहासिक डाइजेस्ट, अलगाव पुनर्निर्माण और क्रेडेंशियल निपटान।
  • संदर्भ: Contained: LiteLLM v1.107.0 Compromised

S42 - Google Brotli: आधिकारिक सुरक्षित संस्करण

  • उद्देश्य: स्वतंत्र Brotli 1.0.10 / 1.1.1 / 1.2.1 और क्रॉस-भाषा एम्बेडेड कॉपी सत्यापन आधार।
  • संदर्भ: Brotli releases

S43 - गलत: कमांड आधिकारिक दस्तावेज़ का उपयोग करें

  • उद्देश्य: वैश्विक कॉन्फ़िगरेशन के टूल संस्करण और कमांड शब्दार्थ निर्दिष्ट करें।
  • संदर्भ: mise use

S44 — PyPA: pip-ऑडिट आधिकारिक परियोजना

  • उद्देश्य: Python निर्भरता भेद्यता ऑडिटिंग का उद्देश्य और क्षमता सीमाएँ।
  • संदर्भ: pip-audit

S45 - Python: टैरफ़ाइल निष्कर्षण फ़िल्टर दस्तावेज़

  • उद्देश्य: डेटा रणनीति, डिफ़ॉल्ट व्यवहार परिवर्तन, और प्रतिबंध जो सैंडबॉक्स को प्रतिस्थापित नहीं कर सकते।
  • संदर्भ: tarfile extraction filters

S46 - Node.js: इंटरमीडिएट CA अस्वीकृति तंत्र

  • उद्देश्य: यह eMudhra संबंधित ट्रस्ट श्रृंखला प्रसंस्करण सभी रूट प्रमाणपत्रों के क्रिप्टोग्राफ़िक अमान्यकरण के बराबर नहीं है।
  • संदर्भ: Node.js PR #66871

S47 — CPython: SNI UAF तकनीकी नोट्स और सुधार