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

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

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

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

  1. Up रनटाइम अपडेट गर्नुहोस् जुन वास्तवमा सेवालाई पहिले होस्ट गर्दछ। सम्बन्धित 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 बाइनरीले यी फ्रेमवर्क कमजोरीहरूलाई कभर गर्दैन। S8 S9 S10 S11 S12
  3. Java : अपडेटको दुबै राउन्ड कभर गर्नुहोस्। अक्टोबर 20 दुवैलाई कभर गर्ने विक्रेता निर्माण स्थापना गर्नुहोस् CPU र अक्टोबर 21 CVE-2026-91403 आपतकालीन प्रमाणपत्र-विश्वास फिक्स। खण्ड हेर्नुहोस् 2.2 को लागी Oracle JDK 11 -27 बाहिर-ब्यान्ड संस्करणहरू; तिनीहरूको आफ्नै सुरक्षा प्याकेजहरू र पूर्ण निर्माण नम्बरहरू विरुद्ध अन्य वितरणहरू प्रमाणित गर्नुहोस्। सम्बन्धित अपडेट गर्नुहोस् Tomcat शाखा सम्म 9.0.123 / 10.1.61 / 11.0.27 . S16 S17 S18 S20 S21 S22 S23
  4. Python : अनुवादक, एप्लिकेसन प्याकेज र प्रमाणपत्र प्याकेजहरू अलग-अलग अपडेट गर्नुहोस्। खण्ड हेर्नुहोस् 2.3 अनुवादक आधारभूतका लागि; certifi सिफारिस गर्दछ ≥ 2026.10.19 , pip ≥ 26.2.2 , प्रयोग गर्दा uv ≥ 0.13.4 । प्रत्येक अवस्थित venv जाँच गर्न आवश्यक छ। को लागी wrap_bio() सम्बन्धित कोडहरू, सही र गैर-खाली server_hostname पनि पास गर्नुपर्छ। S29 S30 S31 S33 S35 S36 S37
  5. यदि तत्काल अपग्रेड असम्भव छ भने, सान्दर्भिक प्रविष्टि बिन्दुहरूमा एक्सपोजर कम गर्नुहोस्। अविश्वासीलाई रोक्न प्राथमिकता दिनुहोस् Brotli डिकोडिङ, प्रभावित छवि/पेजिङ/अभिलेख प्रशोधन, र समस्याग्रस्त पृथक LDAP वा प्रमाणीकरण प्रविष्टिहरू; राख्दै TLS प्रमाणपत्र र होस्टनामहरू प्रमाणित। इनबाउन्ड WAF आउटबाउन्ड मार्गहरू कभर गर्न सक्दैन जस्तै कि अनुप्रयोगहरूले दुर्भावनापूर्ण संकुचित प्रतिक्रियाहरू तान्छन्। S3 S11 S25 S27 S30 S32
  6. पुनर्निर्माण गर्नुहोस्, पुराना प्रक्रियाहरू प्रतिस्थापन गर्नुहोस्, र वास्तविक सेवा मार्गहरू मार्फत प्रमाणित गर्नुहोस्। लक फाइल र छवि डाइजेस्ट बचत गर्नुहोस्, अनुप्रयोग र छवि पुन: निर्माण गर्नुहोस्, सबै कामदारहरूको लागि प्रतिस्थापन रोल आउट गर्नुहोस्/ JVM / कन्टेनर; वास्तविक प्रक्रिया, निर्भरता रूख, विश्वास स्टोर र व्यापार प्रतिगमन परीक्षण जाँच गर्नुहोस्। नयाँ कमाण्ड-लाइन संस्करण एक्लैले सुधार पूरा भयो भनेर स्थापित गर्दैन।
  7. I यदि 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.1TLS/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 वा नेटिभ विस्तारहरू।
  • remediation थ्रेसहोल्ड हालको डिप्लोइमेन्ट बेसलाइनबाट अलग छ। अगस्टमा कमजोरीका लागि पहिलो प्याच सेप्टेम्बरदेखि अक्टोबरसम्म नयाँ मुद्दाहरू समेट्ने ग्यारेन्टी छैन; खण्ड २ ले कार्यान्वयन लक्ष्यको रूपमा प्रमाणित पछिल्लो अद्यावधिकहरू प्रयोग गर्दछ।
  • वास्तविक आपूर्ति-श्रृंखला सम्झौताबाट जोखिम छुट्याउनुहोस्। सामान्य कमजोरीहरूको लागि, प्याचहरूले भविष्यमा आक्रमण गर्ने मार्गहरू हटाउँछन्; जब दुर्भावनापूर्ण प्याकेजहरू चलाइएका छन्, प्रमाणहरू र दृढताको प्रभाव जाँच गर्न आवश्यक छ। धारा ९ LiteLLM आधिकारिक रूपमा पुष्टि भएको घटना हो। S41

जंगलमा शोषण पुष्टि भएको छ कि छैन आधिकारिक खुलासामा आधारित हुनुपर्छ। विक्रेताले शोषण गतिविधिहरू उल्लेख गरेन र कुनै आक्रमण छैन भनेर प्रमाणित गर्न सक्दैन; उपचार वास्तविक आक्रमण सतहमा आधारित हुनुपर्छ।

2. निश्चित संस्करण र तैनाती आधार रेखाको द्रुत जाँच

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

कम्पोनेन्ट/शाखासिफारिस गरिएको संस्करण बेसलाइनप्रयोगको लागि निर्देशनहरू
Node.js 22.x22.23.4सुरक्षा रिलीज 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.28अक्टोबर 14 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 मा लागू हुन्छ। दोस्रो स्तम्भले अक्टोबर २० CPU मात्र कभर गर्दछ; तेस्रोमा अक्टोबर २१ को ब्यान्ड बाहिरको रिलीज समावेश छ। CPU संस्करणहरूले मात्र यहाँ छलफल गरिएका सबै Java जोखिमहरूलाई समेट्दैन। S16S17S18

शाखाअक्टोबर २० CPUOracle अक्टोबर २१ मा ब्यान्डबाट बाहिर रिलिज भयो
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 ठीक माथिल्लो संस्करणको एउटै नामले प्याकेज सामग्री उस्तै हो भन्ने होइन। द .0.2 लागि प्रत्यय नियम Oracle अन्य प्रकाशकहरूमा यान्त्रिक रूपमा लागू गर्न सकिँदैन। 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.2अक्टोबर 6 मा पछिल्लो सुधार 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

दुबै दिशाहरू एकै समयमा जाँच गर्न आवश्यक छ:

  • inbound: The फ्रेमवर्क वा मिडलवेयरले प्रयोगकर्ताद्वारा पेश गरिएको Brotli अनुरोध निकायलाई स्वचालित रूपमा डिकम्प्रेस गर्छ।
  • **outbound:**HTTP ग्राहकहरू, छवि ग्राबरहरू, इत्यादिले आक्रमणकर्ता-नियन्त्रणयोग्य स्रोतहरू पहुँच गर्नुहोस् र फिर्ता गरिएको सामग्रीलाई स्वचालित रूपमा डिकम्प्रेस गर्नुहोस्।

ब्राउजरहरूमा पठाइएका प्रतिक्रियाहरूको Brotli सङ्कुचन असक्षम पार्नाले डिकोडिङ प्रविष्टि बिन्दु हटाउँदैन। इनबाउन्ड WAF सुरक्षाले बाह्य प्रतिक्रियाहरू ल्याउने र डिकोड गर्ने अनुप्रयोगहरूलाई पनि कभर गर्दैन। S3

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

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

3.2 TLS / DNS तीन High: प्रमाणिकरण वस्तु वास्तविक लक्ष्यसँग असंगत छ

खण्ड 2.1. S1 मा सेट गरिएको आधिकारिक स्तरवृद्धि थ्रेसहोल्डको साथ, सबै तीन अक्टोबर 21 मा खुलासा गरिएको थियो।

पहिचानकर्तामुद्दा पुष्टि भयोप्रभावित शाखाहरू
CVE-2026-105482dns.resolve NUL समावेश नामहरूको काट्ने22.x / 24.x / 26.x
CVE-2026-105483IP पूर्ण-चौडाइ संख्यात्मक फारममा सर्टिफिकेट होस्टनाम प्रमाणीकरणलाई बाइपास गर्ने कारण बनाउँछ24.x / 26.x
CVE-2026-106069IP को रूपमा ढिलो रूपमा व्याख्या गर्न सकिने होस्टनाम 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. RCE RSC / use cache प्रकार्यहरू टाइप गरिएका एरेहरू फर्काउँदै

सार्वजनिक मिति: २०२६-१०-१४; 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 दुई-स्तरीय अद्यावधिकहरू हुन्

द Java SE जोखिम म्याट्रिक्स को लागी Oracle CPU अक्टोबर 20 मा सूची 55 नयाँ सुरक्षा प्याचहरू, जसमध्ये 49 लाई प्रमाणीकरण बिना नेटवर्कमा शोषण योग्यको रूपमा चिन्ह लगाइएको छ । यसको मतलब त्यहाँ 55 छन् भन्ने होइन Critical , न त यसको मतलब त्यहाँ 49 प्रत्यक्ष शोषणयोग्य छन् RCE प्रत्येकको लागि मार्गहरू Java वेब सेवा; यसलाई कम्पोनेन्टहरू, API हरू, प्रयोगकर्ता अन्तरक्रियाहरू र म्याट्रिक्समा परिनियोजन अवस्थाहरूसँग संयोजनमा बुझ्नुपर्छ। 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 कार्यान्वयन, रद्द सेवा पहुँच योग्यता र विफलता रणनीतिमा निर्भर गर्दछ। सामान्य परिनियोजनका लागि, सबै TLS पुस्तकालयहरू फिक्स गरिएको प्रमाणको रूपमा दुई JVM स्विचहरूको उपचार गर्नबाट बच्न पूर्ण विक्रेता अद्यावधिकहरू स्थापना गर्न प्राथमिकता दिनुहोस्।

4.2 Tomcat: प्रमाणीकरण बाइपास र क्रस-प्रयोगकर्ता अनुरोध अलगाव

निम्न तीन वस्तुहरू 2026-10-20 मा प्रकाशित गरियो; मर्मत गरिएको संस्करण प्रविष्टि October 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 गैर-GSSAPI SASL प्रमाणीकरण संयन्त्र कन्फिगर गर्दछ, प्रमाण प्रमाणिकरण हराइरहेको छ, र गलत पासवर्डहरू पनि पास हुन सक्छ।
CVE-2026-1013569.0.118—9.0.122;10.1.55—10.1.60;11.0.22—11.0.26HTTP/2 को एसिन्क्रोनस सर्भलेट त्रुटि ह्यान्डलिङले वस्तुहरूलाई गलत तरिकाले रिसाइकल/पुन:प्रयोग गर्दछ, जसले गर्दा प्रयोगकर्ताहरू बीच अनुरोध वा प्रतिक्रियाहरू मिलाइन्छ।
CVE-2026-10311911.0.0-M25-11.0.26 मात्र पुष्टि गर्नुहोस्ठूला AJP गैर-ब्लकिङ राइटहरूले पछिका अनुरोधहरूमा अघिल्लो प्रतिक्रिया डेटालाई उजागर गर्दै, अण्डर-पढ्ने बफर निम्त्याउन सक्छ।

सम्बन्धित फिक्स 9.0.123 / 10.1.61 / 11.0.27 हो; AJP घोषणा अनुसार Tomcat 11 को रूपमा मात्र सूचीबद्ध छ, र समान समस्या भएका तीन शाखाहरूमा विस्तार गर्न सकिँदैन। S21S22S23

JNDIRealm प्याचले वास्तविक प्रमाणीकरण प्रक्रियामा प्रमाणीकरण ग्याप फिक्स गर्दछ, जहाँ “एप्लिकेशन लगइन इन्टरफेस सामान्य देखिन्छ” प्रमाणीकरणको सट्टा प्रयोग गर्न सकिँदैन। सेवाको वास्तविक कन्फिगरेसनको लागि क्षेत्र, SASL संयन्त्रहरू जाँच गरिनु पर्छ, र गलत पासवर्डहरूको लागि परीक्षणहरू असफल हुनुपर्छ। S24

अन्तरिम कार्यान्वयन सुझावहरू: प्रभावित प्रमाणीकरण मार्ग अलग गर्नुहोस्; व्यवसायले अनुमति दिँदा HTTP/2 Tomcat को प्रोसेसिङ निलम्बन गर्नुहोस्; बेकार 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. Jackson 2.x प्रयोग गरेर JSON लाई डिसिरियलाइज गर्नुहोस्।
  3. बाहिरी संसारमा जडान पृष्ठिङ क्षेत्र प्रदान गर्नुहोस्।
  4. क्लासपाथले विशिष्ट वर्गहरू समावेश गर्दछ जसले इन्स्ट्यान्टिएसन वा डिसेरियलाइजेसनको बेला अप्रत्याशित तर्क प्रदर्शन गर्न सक्छ।

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

किन 2.0.4 अपर्याप्त छ: जुनमा, CVE-2026-41699 ले 2.0.4 जस्ता प्याच आधारभूत रेखाहरू दिएको थियो, र अगस्टमा घोषणाले स्पष्ट रूपमा 2.0.4 को प्रभावलाई नयाँ स्कोपमा समावेश गरेको थियो। त्यसकारण, मर्मत रेकर्ड पछिको घोषणाहरू अनुसार अद्यावधिक गरिनुपर्छ, र पुरानो CVE को न्यूनतम संस्करण प्रयोग गर्न सकिँदैन। S26

जब स्तरवृद्धि अस्थायी रूपमा अनुपलब्ध हुन्छ, अविश्वसनीय कलरहरूलाई पहुँचयोग्य प्रभावित पृष्ठन क्षेत्रहरू निलम्बन गर्न सकिन्छ; डिसिरियलाइज गर्न मिल्ने प्रकारहरू र वर्ग मार्गहरूलाई साँघुरो पार्नु एउटा गहन उपाय हो। Regressions ले कानूनी कर्सरहरू, पृष्ठांकन गरिएका परिणामहरू, र अपवाद इनपुट अस्वीकारहरू कभर गर्नुपर्छ, र अन्तिम अनुप्रयोग 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 , प्याच आधार रेखा माथिको तालिकामा यी शाखाहरु संग संगत छ; प्रमाणीकरणले क्रस-नोड सत्रहरू कभर गर्नुपर्छ र अझै पनि PIN/बायोमेट्रिक प्रमाणीकरण आवश्यक पर्दछ। S28

5. Python इकोसिस्टम: अनुवादक, मानक पुस्तकालय, फ्रेमवर्क र प्रमाणपत्रहरू

5.1 CVE-2026-19445: SSLContext UAF SNI कलब्याकमा

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

मूल कुरा यो हो कि Python वस्तु अन्तर्निहित TLS कलब्याक जीवन चक्रसँग असंगत छ। मूल सन्दर्भ जारी गरिएको छ, र अन्तर्निहित तहले अझै पनि कलब्याकको लागि आवश्यक राज्य होल्ड गर्न सक्छ; सन्दर्भ जीवन चक्र ठीक गर्न अनुवादक नेटिभ प्याच प्रयोग गर्न आवश्यक छ। S47

Scope: Python कोड जसले TLS ग्राहकको रूपमा मात्र कार्य गर्दछ यो वस्तुबाट प्रभावित हुँदैन; लामो समयको लागि मौलिक सन्दर्भ समात्ने सुन्ने सकेटको सामान्य मोड घोषणामा वर्णन गरिएको विशिष्ट विफलता मार्गमा पर्दैन। Nginx ले TLS समाप्त गरिसकेपछि, यसले स्थानीय HTTP लाई Python लाई मात्र हस्तान्तरण गर्छ, र Python SNI लाई प्रत्यक्ष रूपमा ह्यान्डल गर्छ, जुन एक फरक आक्रमण सतह हो। S29

3.10—3.14 निश्चित संस्करणसँग सम्बन्धित, 2.3. 3.15 को आधिकारिक संस्करण मर्मत गरिएको छ, र 3.15.1 वास्तवमा चयन गर्न सकिन्छ। केवल pip निर्भरता अद्यावधिक गर्नाले अनुवादकको _ssl कार्यान्वयनलाई प्रतिस्थापन गर्न सक्दैन। S33S35S47

Official अस्थायी शमन: सबै SSLContext को लागि बलियो सन्दर्भ राख्छ जसले SNI कलब्याक सर्भर जीवन चक्रको अन्त्य सम्म सेट गरेको छ। यसले वास्तविक गतिशील सिर्जना र स्विच गर्ने मार्गहरू कभर गर्न आवश्यक छ; अनुकूलन OpenSSL 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: टारफाइल फिल्टरमा लिङ्क संयोजन बाइपास

सार्वजनिक मिति: २०२६-०९-१४; High . मा CPython 3.13 र पहिले सम्बन्धित कार्यान्वयनहरू, अविश्वसनीय टारमा हार्ड लिङ्कहरू र प्रतीकात्मक लिङ्कहरूको संयोजनले बाइपास गर्न सक्छ। data / tar एक्स्ट्र्याक्शन फिल्टर, अनप्याकिङ ट्रीमा अनप्याकिङ डाइरेक्टरी बाहिर फाइलहरूको सामग्रीहरू उजागर गर्दै, वा तिनीहरूको अनुमति र परिमार्जन समय परिमार्जन गर्दै। S32

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

For the corresponding patch baselines of 3.10—3.13, see Section 2.3. Python 3.14 has been exempted from this specific issue due to os.link() behavior changes since 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

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

कार्यान्वयनले API र प्रशासन इन्टरफेसको दुई प्रविष्टि बिन्दुहरू जाँच गर्दछ, अविश्वसनीय स्थानिय लुकअप, फाइल लेखन अनुमति र आउटबाउन्ड पहुँच प्रतिबन्धित गर्दछ; अद्यावधिक गरेपछि, प्रतिगमन-परीक्षण मान्य स्थानिक प्रश्नहरू र निषेधित इनपुटको अस्वीकार। GeoDjango प्रयोग नगर्ने साधारण Django अनुप्रयोगहरूले यस 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 प्याकेजछवि वा होस्टको लागि प्रणाली विश्वास सामग्री
certifi venv माCA 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 लेजर स्थापना गर्नुहोस् जुन वास्तविक ट्राफिकसँग मेल खान्छ

प्रत्येक सेवा कम्तिमा रेकर्ड:

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

विकास मेसिनहरू, CI धावकहरू, कन्टेनरहरू निर्माण गर्नुहोस्, र पृष्ठभूमि कार्यहरू पनि अविश्वसनीय सामग्रीमा तिनीहरूको मार्ग अनुसार जाँच गरिनु पर्छ; सार्वजनिक अनुहार वेब कन्टेनर मात्र अद्यावधिक नगर्नुहोस्।

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 मिल्दो निर्भरताहरू, लक फाइलहरू र अन्तिम तीव्र उदाहरण जाँच गर्नुहोस्, र त्यसपछि परियोजना प्रक्रिया अनुसार निर्माण गर्नुहोस्। पुन: उत्पादन योग्य स्थापनाको लागि CI मा अद्यावधिक गरिएको लक फाइल प्रयोग गर्नुहोस्, र निर्माण पछि चलिरहेको छविमा संस्करण जाँच गर्नुहोस्। यस आपतकालिनको लागि पूर्वनिर्धारित समाधानको रूपमा प्रमुख संस्करणहरूमा अनियन्त्रित स्वचालित मरम्मत प्रयोग नगर्नुहोस्।

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, एप्लिकेसन सेल्फ-लोड गरिएको कीस्टोर, jlink रनटाइम, GraalVM/नेटिभ छवि र अन्य डेलिभरी फारमहरू वस्तुद्वारा जाँच गर्नुहोस्। JDK डाइरेक्टरी नयाँ भएको कारणले गर्दा पहिले नै अनुकूलित ट्रस्ट सामग्रीहरू भएका अनुप्रयोगहरूले जाँच समाप्त गर्न सक्दैन।

6.4 Python: अनुवादक-द्वारा-दोभाषे र भर्चुअल वातावरण प्रशोधन

वास्तविक venv/कन्टेनर भित्र विश्वास गरिएको पुष्टि भयो:

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

I प्रणाली /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 होस्टनाम छोड्नुहोस्आधिकारिक समाधान: अपेक्षित सर्भर_होस्टनाम सही रूपमा पास गर्नुहोस्चेक_होस्टनाम झण्डा जाँच गर्न वा 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 सान र DNS पहिचान, र DNS कलब्याक/प्रोमिस पार्सिङ मार्ग र TLS होस्टनाम मिलान परीक्षण। S5 S6
  • Tomcat JNDIRealm: केवल डाइरेक्टरी सन्दर्भ प्राप्त गर्नुको सट्टा प्रमाणीकरण प्रक्रियाले वास्तवमा प्रमाणहरू प्रमाणित गर्छ कि गर्दैन भन्ने कुरामा केन्द्रित छ; आधिकारिक संस्करणलाई प्राथमिकता दिँदै र एकल स्रोत फाइल प्रतिस्थापनलाई पूर्ण बाइनरी प्याचको रूपमा व्यवहार नगर्ने। S24
  • CPython ssl: Python सन्दर्भ स्वामित्व र अन्तर्निहित SSLContext को जीवन चक्रमा केन्द्रित छ; wrap_bio() शाखा अनुकूलता भिन्नता हुँदा ब्याकपोर्टहरू, र तपाईंले प्रयोग गरिएको शाखाको वास्तविक कार्यान्वयन पढ्नुपर्छ। S31S47
  • प्रमाणपत्र अविश्वास: यस्ता अपडेटहरू विश्वसनीय सामग्रीको रूपमा देखा पर्न सक्छन् वा स्पष्ट API परिवर्तनहरूको सट्टा सूची परिवर्तनहरू अस्वीकार गर्न सक्छन्। Node को एउटै ब्याचले प्रभावित मध्यवर्ती CA को अस्वीकार गर्ने संयन्त्र पनि समावेश गर्दछ; Java र Python को सम्बन्धित विश्वास स्रोतहरू अझै पनि अलग रूपमा प्रमाणित गर्न आवश्यक छ। S19S37S46

स्वतन्त्र Brotli बन्धन पनि जाँच गर्नुपर्छ। गुगल अपस्ट्रीम जारी गरियो 1.0.10 / 1.1.1 / 1.2.1 ठीक गर्न एकै दिन CVE-2026-111497 . Python नेटिभ एक्सटेन्सनहरू वा JNI कलाकृतिहरू जसले उही प्रभावित C कार्यान्वयनलाई इम्बेड गर्दछ स्वतन्त्र रूपमा अद्यावधिक/पुनर्निर्माण गर्न आवश्यक छ; सबै शुद्ध छ भनेर अनुमान गर्न सकिँदैन 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 क्र्यासहरू, शंकास्पद फाइलहरू, डाइरेक्टरी डेटा परिवर्तनहरू, प्रमाणीकरण अपवादहरू, आउटबाउन्ड अनुरोधहरू, र प्रमाणिक उपयोग रेकर्डहरूका लागि अवस्थित लगहरू जाँच गर्नुहोस्। यी संकेतहरूलाई सन्दर्भमा न्याय गर्न आवश्यक छ: दुर्घटना वा OOM सफल शोषणको प्रमाण होइन; अलर्टहरूको अनुपस्थितिले प्रणाली अप्रभावित थियो भनेर प्रमाणित गर्दैन।

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

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

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

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

वातावरणका लागि जहाँ सम्बन्धित उत्पादनहरू स्थापना वा चलाइएको छ:

  1. स्थापना रेकर्डहरू, छविहरू, र लगहरू अलग गर्नुहोस् र सुरक्षित गर्नुहोस्, र तिनीहरूलाई सफा वातावरणबाट निरीक्षण गर्नुहोस्।
  2. पहिले शङ्कास्पद वातावरणमा Python/pip सुरु नगर्नुहोस्; मालिसियस .pth / sitecustomize.py स्टार्टअप पछि फेरि कार्यान्वयन हुन सक्छ।
  3. विश्वसनीय स्रोतहरूबाट होस्टहरू, venvs/कन्टेनरहरू पुन: निर्माण गर्नुहोस्; केवल प्याकेजहरू अनइन्स्टल वा डाउनग्रेड गर्न सक्दैन।
  4. वास्तविक पहुँचको आधारमा क्लाउड प्रमाणहरू, LLM प्रदायक कुञ्जीहरू, 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: wrap_bio आधिकारिक प्याच र 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 अद्यावधिकहरू, अवस्थित venv आवश्यकताहरू।
  • सन्दर्भ: Python 3.13.17
  • सन्दर्भ: Python 3.14.9
  • सन्दर्भ: Python 3.15.1

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

S37 — PSF: Python प्रयोगकर्ताहरूमा eMudhra / emSign को प्रभाव

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

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

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: कमांड आधिकारिक कागजात प्रयोग गर्नुहोस्

  • उद्देश्य: विश्वव्यापी कन्फिगरेसनको उपकरण संस्करण र आदेश अर्थशास्त्र निर्दिष्ट गर्नुहोस्।
  • सन्दर्भ: mise use

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

  • उद्देश्य: Python निर्भरता जोखिम अडिटिङको उद्देश्य र क्षमता सीमाहरू।
  • सन्दर्भ: pip-audit

S45 — Python: tarfile निकासी फिल्टर कागजात

  • उद्देश्य: डेटा रणनीति, पूर्वनिर्धारित व्यवहार परिवर्तनहरू, र स्यान्डबक्स प्रतिस्थापन गर्न नसक्ने प्रतिबन्धहरू।
  • सन्दर्भ: tarfile extraction filters

S46 — Node.js: मध्यवर्ती CA अस्वीकृति संयन्त्र

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

S47 — CPython: SNI UAF प्राविधिक नोटहरू र समाधानहरू