eMudhra मध्यवर्ती CA सम्झौता: प्रभाव र उपचार गाइड

स्रोतहरू अक्टोबर 22, 2026 मा बेइजिङ समय जाँच गरियो। Audience: व्यक्तिगत प्रयोगकर्ताहरू, वेबसाइट अपरेटरहरू, विकासकर्ताहरू, र प्रणाली प्रशासकहरू।

गम्भीर कमजोरीहरूले eMudhra/emSign मध्यवर्ती CA निजी कुञ्जीहरूको समूहलाई पुन: प्राप्त गर्न योग्य बनायो। यसले वेबसाइटहरू, एपीआईहरू, र सफ्टवेयर प्रमाणीकरण गर्न सार्वजनिक प्रमाणपत्र प्रणाली प्रयोग गर्ने ग्राहकहरूलाई असर गर्छ। सार्वजनिक विश्वासले प्रमुख अपरेटिङ सिस्टमहरूमा फैलिएको छ, तर सम्झौता गरिएका कुञ्जीहरूको सेट र सम्भावित ग्राहक प्रभावहरू फरक दायराहरू हुन्। 1 5

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

TL;DR

Eight मध्यवर्ती CA निजी कुञ्जीहरू सम्झौता भएको पुष्टि भयो। हालको रिपोर्टहरूले मूल निजी कुञ्जीहरू वा HTTPS क्रिप्टोग्राफी सामान्य रूपमा तोडिएको छ भनेर स्थापित गर्दैन। अपडेटहरूले धेरै सार्वजनिक विश्वास इकोसिस्टमलाई फैलाउँछ; अवशिष्ट जोखिम वास्तविक आवेदन मा निर्भर गर्दछ।1 5

व्यक्तिगत प्रयोगकर्ताहरू: अपडेट ब्राउजरहरू, अपरेटिङ सिस्टमहरू, र सुरक्षा कम्पोनेन्टहरू। Android मा, Google Play सेवाहरू पनि अपडेट गर्नुहोस्। Firefox Android 158.0.2 वा पछिको प्रयोग गर्नुहोस्। 1 2
Servers: वितरणको ca-certificates/NSS प्याकेजहरू अद्यावधिक गर्नुहोस् र एप्लिकेसन-बन्डल गरिएको ट्रस्ट स्टोरहरू जाँच गर्नुहोस्। होस्ट मात्र अद्यावधिक गर्न अपर्याप्त छ। 7 8 10
विकास वातावरणहरू: Node 24 24.22.1 मा अपडेट गर्नुहोस् वा त्यो शाखामा लागू हुने नयाँ रिलीज। Python वातावरणमा, कम्तिमा pip 26.2.2, certifi 2026.10.19, र uv 0.13.4 मा अपडेट गर्नुहोस्। निश्चित Go बाइनरीहरू प्राप्त गर्नुहोस् वा तिनीहरूलाई पुन: निर्माण गर्नुहोस्; यसको विक्रेताको सल्लाह अनुसार Java अपडेट गर्नुहोस्। 12–15
सक्रिय अपडेटहरू: प्रभावित सेवाहरू पुन: सुरु गर्नुहोस् र कन्टेनरहरू पुन: निर्माण र पुन: प्रयोग गर्नुहोस्। Cloudflare Tunnel को लागि, cloudflared 2026.10.2 वा पछि अपडेट गर्नुहोस्। 7
वेबसाइट सर्टिफिकेटहरू: ले प्रभावित चेनलाई प्रतिस्थापन गर्नुहोस् यदि यसले रद्द वा अवरुद्ध मध्यवर्ती CA समावेश गर्दछ, वा अविश्वास गरिएको रूटमा निर्भर गर्दछ। प्रमाणपत्र पुन: जारी गर्नाले ग्राहक ट्रस्ट स्टोरहरू अद्यावधिक गर्दैन। 1 5 8
प्रमाणीकरण: प्रत्येक अनुप्रयोगको वास्तविक TLS पथ परीक्षण गर्नुहोस्। टाइमआउट र DNS विफलताहरूबाट प्रमाणपत्र अस्वीकृति छुट्याउनुहोस्। प्रमाणपत्र प्रमाणिकरण सक्षम राख्नुहोस्; -k प्रयोग नगर्नुहोस् वा त्रुटिहरूलाई दबाउन प्रमाणीकरण छोड्नुहोस्। 7

1 घटनाको तथ्य र कारणहरू

पुष्टि भएका तथ्यहरू

Mozilla र Google ले आठ eMudhra मध्यवर्ती CA निजी कुञ्जीहरूमा त्रुटिहरू पुष्टि गरेका छन्। शोधकर्ताले निजी-कुञ्जी नियन्त्रणको प्रमाण प्रदान गरे; Mozilla ले स्वतन्त्र रूपमा कुञ्जीहरू पुनःप्राप्त गर्यो र मुद्दा पुन: उत्पादन गर्यो। छ मध्यवर्ती CA TLS सेवा र दुई सेवा कोड हस्ताक्षर। 2 5

दोष उत्पन्न गरिएका कुञ्जीहरूमा निहित छ: यी मध्यवर्ती CAहरूले P-384 कर्भ प्रयोग गर्छन्, तर तिनीहरूका निजी कुञ्जीहरू 256 भन्दा कम पूर्णाङ्कहरू छन्। यो इच्छित ठूलो दायराबाट अनियमित रूपमा कुञ्जीहरू चयन गर्नबाट टाढा छ। यी कमजोर कुञ्जीहरू पुन: प्राप्ति गर्दा ठीकसँग उत्पन्न गरिएको P-384 कुञ्जीहरू तोड्न सकिन्छ भनेर देखाउँदैन। 2

यहाँ “प्रमाणपत्र क्र्याक भएको छ” लाई “सम्बन्धित निजी कुञ्जी पुन: प्राप्त गर्न सकिन्छ” भनेर सही रूपमा बुझ्नुपर्छ। प्रमाणपत्र र यसमा सार्वजनिक कुञ्जी स्वाभाविक रूपमा सार्वजनिक छन्; के साँच्चै गोप्य राख्न आवश्यक छ एक मान्य हस्ताक्षर उत्पन्न गर्न सक्ने निजी कुञ्जी हो।

कुञ्जी-पुस्ता प्रक्रिया मुद्दाहरू अझै अनुसन्धानमा छन्

eMudhra को प्रारम्भिक विवरणले अप्रिल 2025 मा कुञ्जी जेनेरेसन समारोहमा समस्या पत्ता लगाउँछ। स्पष्टीकरणमा कुञ्जी इन्क्याप्सुलेशन र डिक्याप्सुलेशन चरण समावेश छ: मूल बलियो कुञ्जीका अतिरिक्त, कमजोर कुञ्जीहरूको अर्को सेट देखिन्छ, र कमजोर कुञ्जीहरू पछि प्रमाणपत्र आवेदन र जारी गर्न प्रयोग गरिन्छ। कम्पनीले अझै पनि ठोस मूल कारण निर्णायक रूपमा निर्धारण गर्न नसकेको बताएको छ। 6

त्यसकारण, के निर्धारण गर्न सकिन्छ कि यी कुञ्जीहरू गम्भीर रूपमा कमजोर छन् र सम्झौता गरिएको छ; विफलतालाई HSM को निश्चित हार्डवेयर अनियमित संख्या स्रोतको रूपमा दोषपूर्ण साबित भएको रूपमा वर्णन गर्न सकिँदैन, न त यसलाई RSA, ECC वा TLS को सामान्य क्रिप्टोग्राफिक सफलताको रूपमा वर्णन गर्न सकिँदैन।

मूल प्रमाणपत्र अविश्वास भनेको के हो?

ब्राउजर वा अपरेटिङ सिस्टमले प्रभावित मध्यवर्ती CA को सर्टिफिकेट वा सार्वजनिक कुञ्जीलाई सीधै ब्लक गर्न सक्छ, वा यसले तिनीहरूलाई नेतृत्व गर्ने रूट ट्रस्ट हटाउन सक्छ। पछिल्लो उपायले उही मूल अन्तर्गत केही वैध प्रमाणपत्रहरू पनि अस्वीकार गर्नेछ।

Google ले Chrome रूट स्टोरका प्रयोगकर्ताहरूलाई जोगाउन CRLSet बाट अद्यावधिकहरू प्राप्त नगर्ने emSign ECC Root CA - G3 हटाउने तालिका बनाएको छ। रूट स्टोर हटाउने कार्य अक्टोबर 27th देखि 28th, बेइजिङ समय सम्मको अवधिमा धक्का दिइने अपेक्षा गरिएको छ; Google को मूल समय अक्टोबर 27 को बिहान, US प्यासिफिक डेलाइट समय हो। यो योजना पहिले तैनाथ गरिएको आपतकालीन सार्वजनिक कुञ्जी ब्लकिङबाट अलग छ। 1

रूटमा अविश्वास गर्नु प्रतिक्रिया उपाय हो; यसले आफैं प्रमाणित गर्दैन कि रूट निजी कुञ्जी सम्झौता गरिएको थियो।

2 किन सम्भावित प्रभाव सार्वजनिक विश्वास इकोसिस्टम फैलिएको छ

सम्झौता गरिएका कुञ्जीहरू र प्रभावित विश्वास मार्गहरू

न्याय वस्तु	यस घटनाको दायरा
समस्याग्रस्त कुञ्जी पहिचान गरियो	eMudhra को लागि 8 मध्यवर्ती CA निजी कुञ्जीहरू
कार्य आवश्यक हुन सक्ने प्लेटफर्महरू	सार्वजनिक रूट स्टोर, ब्राउजर, अपरेटिङ सिस्टम, भाषा रनटाइम, सफ्टवेयर प्याकेज र कन्टेनर इकोसिस्टम
सम्भवतः प्रतिरूपित पहिचान TLS	ग्राहकहरूले भ्रमण गरेका वेबसाइटहरू वा सेवाहरू जसले अझै पनि सम्बन्धित नक्कली प्रमाणपत्र श्रृंखला स्वीकार गर्दछ
के यसको मतलब सबै उपकरणहरू सम्झौता गरिएको छ?	होइन; विश्वास सर्तहरू, आक्रमणकर्ता नेटवर्क स्थान, र अन्य प्रमाणीकरण रणनीतिहरूले शोषण निर्धारण गर्दछ
के यसको मतलब सबै कानूनी प्रमाणपत्रहरू अवैध छन्?	होइन; सम्बन्धित अमान्यता ग्राहकले अविश्वास गरेको रूट वा प्रमाणपत्र चेन मा निर्भर गर्दछ।

Red Hat ले स्पष्ट रूपमा शोषणलाई सर्तहरूमा सीमित गर्दछ जहाँ ग्राहकले अझै पनि सान्दर्भिक चेन स्वीकार गर्दछ, आक्रमणकर्तासँग सम्झौता गरिएको निजी कुञ्जी हुन्छ, र नेटवर्कमा जडानलाई रोक्न सक्षम हुन्छ। जोखिम कवरेज भएको आक्रमणको संख्या संग भ्रमित हुनु हुँदैन। 10

अन्य CA प्रयोग गर्ने वेबसाइटहरू पनि प्रतिरूपित हुन सक्छन्

मानौं कि वेबसाइटले वास्तवमा Let’s Encrypt प्रमाणपत्र प्रयोग गर्दछ, र आगन्तुकको ग्राहकले एकै समयमा धेरै सार्वजनिक CA लाई विश्वास गर्दछ। एक आक्रमणकारीले समान डोमेन नामको लागि अर्को प्रमाणपत्र सिर्जना गर्न सम्झौता गरिएको मध्यवर्ती CA प्रयोग गर्ने प्रयास गर्न सक्छ। ग्राहकहरूलाई सामान्यतया डोमेन नामले Let’s Encrypt मात्र प्रयोग गर्न सक्ने अग्रिम आवश्यक पर्दैन; यदि नक्कली चेन अझै पनि स्वीकार गरिएको छ, जुन CA वेबसाइटले वास्तवमा प्रयोग गर्दछ त्यस्ता आक्रमणहरूलाई अस्वीकार गर्न पर्याप्त छैन। 8

यो मेकानिजमले बताउँछ: अर्को CA प्रमाणपत्र प्रतिस्थापन गर्नाले जुन मूल रूपमा सामान्य थियो ग्राहकको विश्वासलाई सम्झौता गरिएको CA मा स्वतः मर्मत गर्दैन। वास्तवमा काट्नु पर्ने कुरा भनेको ग्राहकहरूलाई नक्कली पहिचान स्वीकार गर्ने बाटो हो।

तीनवटा असरलाई छुट्टाछुट्टै व्यवहार गर्नुपर्छ

पहिचान प्रतिरूपण जोखिम: सान्दर्भिक चेनलाई अवरुद्ध नगर्ने ग्राहकहरूले आक्रमणकारीले नक्कली पहिचान स्वीकार गर्न सक्छन्, जसले गर्दा नक्कली सेवाहरूमा संवेदनशील अनुरोधहरू पठाइन्छ।

वैध सेवा उपलब्धता जोखिम: रूट ट्रस्ट हटाउनाले अन्यथा वैध वेबसाइटहरूको लागि प्रमाणपत्र त्रुटिहरू निम्त्याउन सक्छ, जसलाई अर्को स्वीकृत श्रृंखलामा माइग्रेसन आवश्यक हुन सक्छ।

Deployment कवरेज जोखिम: अपरेटिङ सिस्टम फिक्स हुन सक्छ जब एप्लिकेसन-बन्डल गरिएको ट्रस्ट स्टोर, भर्चुअल वातावरण, पुरानो कन्टेनर छवि, वा कम्पाइल गरिएको कार्यक्रमले पुरानो प्रमाणीकरण व्यवहार कायम राख्छ।

यी तीनवटै दायरा एउटै होइनन् । Cloudflare को प्रतिक्रियाले टाढाको पहिचान प्रमाणीकरण, साझा ट्रस्ट स्टोरहरू, आधार छविहरू, र व्यक्तिगत एप्लिकेसनहरू समावेश गर्दछ, किन पछिल्ला दुई कार्यहरू अलग-अलग ह्यान्डल गर्नुपर्छ भनेर चित्रण गर्दछ। 7

3 प्रभावित CA र प्रमाणपत्र प्रदायकहरू

प्रदायक र प्रभाव प्रकार

प्रदायक वा प्रणाली	यस घटनामा भूमिका	सीमाहरू छुट्याउन आवश्यक छ
eMudhra／emSign	मध्यवर्ती CA निजी कुञ्जी सीधा सम्झौता गरिएको छ।	तपाईंले सबै eMudhra जरा र सबै प्रमाणपत्रहरू क्र्याकको रूपमा लेख्न सक्नुहुन्न
Sectigo सम्बन्धित क्रस-हस्ताक्षर श्रृंखला	A क्रस-प्रमाणपत्र प्रभावित सार्वजनिक कुञ्जीहरूको एउटै ब्याचको लागि जारी गरिएको थियो, अर्को विश्वास मार्ग बनाउँदै।	सम्बन्धित क्रस प्रमाणपत्र वा सार्वजनिक कुञ्जी अवरुद्ध गर्न आवश्यक छ; Sectigo रूट निजी कुञ्जी सम्झौता भएको प्रमाणित गरिएको छैन।
Internet2/InCommon का लागि सान्दर्भिक प्रमाणपत्र स्तरहरू	केही वैध प्रमाणपत्रहरू emSign ECC रूटमा भर पर्छन्, माइग्रेसन समावेश गर्दछ।	यो मूल अविश्वासको संपार्श्विक प्रभाव हो र ती 8 कमजोर कुञ्जीहरूको बीचमा गणना गर्न सकिँदैन CA
Let’s Encrypt, DigiCert, Google Trust Services, GlobalSign, आदि।	यस प्रतिवेदनमा जसको निजी कुञ्जीमा सम्झौता गरिएको थियो त्यो पार्टीको रूपमा सूचीबद्ध छैन	वैध प्रमाणपत्रहरू समान रूपमा अवैध छैनन्; कमजोर ग्राहकहरूले अझै पनि उनीहरूले सेवा गर्ने वेबसाइटहरूको नक्कल गर्दै नक्कली प्रमाणपत्रहरू स्वीकार गर्न सक्छन्
CDN, क्लाउड प्लेटफर्म, प्रमाणपत्र डीलर	सम्भवतः सान्दर्भिक प्रमाणपत्रहरू प्रदान गर्नुहोस् वा मूल र API मा जडान गर्दा सार्वजनिक ट्रस्टस्टोर प्रयोग गर्नुहोस्।	वास्तविक प्रमाणपत्र श्रृंखला र प्रमाणिकरण जाँच गर्न, प्लेटफर्म वा उत्पादन नाम मात्र नहेर्नुहोस्

Mozilla को सूचनाले सम्झौता गरिएका कुञ्जीहरू र Sectigo क्रस-हस्ताक्षरहरू दस्तावेज गर्दछ। Google को सार्वजनिक घटना छलफलले वैध Internet2/InCommon पदानुक्रमहरूको स्थानान्तरणलाई सम्बोधन गर्दछ। 2 5 Cloudflare को फिक्स ठेगाना सेवा र ग्राहक विश्वास; तिनीहरूले Cloudflare को आफ्नै CA निजी कुञ्जीहरूको सम्झौतालाई संकेत गर्दैनन्। 7

TLS प्रमाणपत्र श्रृंखला र क्रस-हस्ताक्षर

निम्न सम्बन्धले यस पटक TLS सम्बन्धित मार्गहरू मात्र वर्णन गर्दछ। यसले कोड हस्ताक्षर गर्ने मार्गहरू समावेश गर्दैन, न त यसको मतलब यो हो कि यी मार्गहरू अझै पनि सबै प्लेटफर्महरूमा विश्वसनीय छन्। 17

emSign ECC Root CA - G3 → emSign Root TLS CA - G3 → प्रभावित TLS मध्यवर्ती CA सार्वजनिक कुञ्जी → लक्षित डोमेनको लागि जाली प्रमाणपत्र
AAA Certificate Services → प्रभावित TLS मध्यवर्ती CA सार्वजनिक कुञ्जी → लक्षित डोमेनको लागि जाली प्रमाणपत्र

emSign Root TLS CA - G3 प्रभावित TLS मध्यवर्तीहरूको एक प्रत्यक्ष जारीकर्ता हो र आफैंले केही स्टोरहरूमा विश्वासको एंकर हुन सक्छ। emSign ECC Root CA - G3 ले अर्को क्रस-साइनिङ तह प्रदान गर्दछ। Sectigo को AAA Certificate Services ले समान मध्यवर्ती CA सार्वजनिक कुञ्जीहरूको लागि अतिरिक्त मार्ग सिर्जना गर्दछ। 17

त्यसकारण, मरम्मत गर्दा त्यहाँ दुई फरक ग्रेन्युलेरिटीहरू छन्:

ठ्याक्कै मध्यवर्ती CA वा सार्वजनिक कुञ्जीलाई अवरुद्ध गर्नुहोस्: यसले अन्य वैध पदानुक्रमहरूलाई उही रूट अन्तर्गत सुरक्षित गर्न सक्छ, जहाँ मान्यकर्ताले त्यो संयन्त्रलाई समर्थन गर्दछ।
रूट विश्वास हटाउनुहोस्: यसले मध्यवर्ती CA अवरुद्ध क्षमताहरू बिना ग्राहकहरूलाई सुरक्षित गर्न सक्छ, तर अनुकूलतालाई असर गर्न सक्छ। ग्राहकले स्वीकार गर्ने अन्य सबै मार्गहरू पनि कभर हुनुपर्छ। 5

“सबै Sectigo/eMudhra जराहरू मेटाउनुहोस्” लाई अविवेकी सामान्य कदमको रूपमा लिनु हुँदैन, न त समान नामको प्रमाणपत्र मेटाउनुको मतलब सबै मार्गहरू बन्द छन्।

4 अपरेटिङ सिस्टम र ब्राउजर कभरेज

मुख्य प्लेटफार्म

प्लेटफर्म	ज्ञात स्वभाव	स्कोप जुन प्रयोग गर्दा जाँच गर्नुपर्छ
Windows र Windows Server	Microsoft वितरण स्वचालित प्रमाणपत्र ट्रस्ट सूची अद्यावधिक मार्फत अवरुद्ध	यन्त्रले अद्यावधिक प्राप्त गरेको छ कि छैन; स्ट्यान्डअलोन CA bundle ले Windows को प्रमाणीकरण मार्ग प्रयोग गर्दैन।
macOS, iOS, iPadOS, आदि। Apple प्लेटफर्म	घटना संयोजकले पुष्टि गरे कि Apple ले प्रासंगिक नाकाबन्दी तैनाथ गरेको छ।	प्रत्येक पुरानो संस्करण र तेस्रो-पक्ष अनुप्रयोग समान कभरेज प्राप्त गर्न ग्यारेन्टी छैन
Android	Google ले Google Play सेवा मार्फत बराबर ब्लकहरू वितरण गर्दछ।	ROM बिना Google Play सेवा निर्माताको घोषणा अनुसार प्रमाणित गरिनु पर्छ; थप प्रमाणिकरणको लागि बिल्ट-इन प्रमाणिकरण प्रयोग गर्नुहोस्
Ubuntu	प्रणाली प्रमाणपत्र बन्डल फिक्स प्रदान गरिएको छ, धेरै हालको र पुरानो संस्करण शाखाहरू सहित	ESM को पुरानो संस्करण सर्तहरू, कन्टेनर आन्तरिक प्रमाणपत्र प्याकेज र अनुप्रयोग निर्मित पुस्तकालय समर्थन गर्दछ
Debian र Devuan	Debian रेकर्ड गरिएको ca-certificates निश्चित	तपाईंले प्रयोग गरिएको वास्तविक शाखा र स्थापित प्याकेज जाँच गर्नुपर्छ, र तपाईंले अर्को शाखाको संस्करण नम्बर प्रतिलिपि गर्न सक्नुहुन्न।
RHEL र डेरिभेटिभहरू	आधिकारिक सूची RHEL 6, 7, 8, 9, 10 हो, र सम्बन्धित उत्पादनहरू र छविहरू समावेश गर्दछ जुन प्रभावित हुन सक्छ।	यस जाँचको रूपमा, घोषणाले अझै फिक्स र इरेटाको पूर्ण सूची सूचीबद्ध गरेको छैन; “अद्यावधिक फेला परेन” अप्रभावित मान्न सकिदैन
Fedora, Arch, Gentoo, Alpine, आदि।	घटना मर्मतकर्ताले सम्बन्धित मर्मत रेकर्डहरू संकलन गरेको छ	स्वतन्त्र रूपमा रिलीज, संस्करण शाखा र छवि द्वारा पुष्टि
FreeBSD	आधिकारिक रूपमा सबै समर्थित संस्करणहरू सूचीबद्ध गर्दछ र प्रणाली ट्रस्ट स्टोर मर्मत प्रदान गर्दछ	अद्यावधिक पछि, घोषणा अनुसार प्रासंगिक डेमन प्रक्रिया पुन: सुरु गर्नुहोस्; स्वतन्त्र आवेदन ट्रस्ट स्टोर अलग जाँच गर्नुहोस्।

Windows, Apple र रिलीजहरूको सारांशको लागि, 4 हेर्नुहोस्; Android को लागि, 1 हेर्नुहोस्; Ubuntu, Debian, RHEL, र FreeBSD को लागि जारीकर्ता रेकर्डहरू क्रमशः 8–11 मा देखाइन्छ।

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

ब्राउजर सुरक्षा अपरेटिङ सिस्टम सुरक्षा भन्दा फरक छ

Chrome ले आकस्मिक ब्लकहरू वितरण गर्न CRLSet प्रयोग गर्दछ; Firefox ले OneCRL जस्ता संयन्त्रहरू प्रयोग गर्दछ। Firefox कन्फिगरेसनहरूको लागि थप सुरक्षा प्रदान गर्न ब्लकिङ जानकारीको साथ रिमोट सेटिङहरू ठीकसँग प्राप्त नगर्ने पनि जारी गरिएको छ। 1 3

Firefox Android को केहि कन्फिगरेसनहरूले स्टार्टअपमा अद्यावधिक गरिएको सूचीलाई सही रूपमा लागू गरेका थिएनन्, जुन Mozilla 158.0.2. द्वारा निश्चित गरिएको छ त्यसैले, सबै Android Firefox कन्फिगरेसनहरू समावेश गर्न प्रारम्भिक 158.0.1 को स्थिति विस्तार गर्न सकिँदैन। 2

Apple र Windows को प्रणाली प्रमाणिकरणको लागि उपायहरू लिइएका छन्, तर यसको मतलब यो होइन कि एउटै मेसिनमा सबै कमाण्ड लाइन कार्यक्रमहरू प्रणाली प्रमाणीकरणबाट गुज्रनेछन्। घटना संरक्षकले विशेष रूपमा सम्झायो कि केहि macOS निर्मित उपकरणहरूले स्वतन्त्र प्रमाणपत्र फाइलहरू प्रयोग गर्छन्; जाँच गर्दा वास्तविक TLS ब्याकइन्ड र CA स्रोत रेकर्ड गर्नुपर्छ। 4

प्रमाणपत्र पारदर्शिताका लागि सुरक्षात्मक सीमाहरू

Google ले यो ब्लक लागू गर्नु अघि, छ TLS मध्यवर्ती CA CT लगमा प्रवेश गर्ने TLS प्रमाणपत्र जारी गरेन भनेर पुष्टि गर्यो। तसर्थ, CT लागू गर्ने Chrome ग्राहकहरूसँग अतिरिक्त सुरक्षा छ। यो तथ्यले CT कार्यान्वयन नगर्ने अन्य क्लाइन्टहरूले कागजात नभएका प्रमाणपत्रहरू स्वीकार गरेको सम्भावनालाई अस्वीकार गर्दैन। 1 5

“यो बाहिर जान्छ कि यो विश्वसनीय जरा संग लिङ्क गर्न सकिन्छ”, “सम्भावित शोषण अवस्था अवस्थित छ” र “एक आक्रमण भएको छ” तीन फरक निर्णय हो र एक अर्का द्वारा प्रतिस्थापित हुनु हुँदैन।

5 विकास वातावरण र रनटाइम मर्मत आधार रेखा

निम्न पुष्टि गरिएका फिक्सहरूको आधारभूत रेखा हो र यी रिलीजहरूलाई लामो-समयमा पिन गर्न आवश्यक छैन। Distros ले पुरानो संस्करण नम्बरहरू ब्याक प्याचहरू सार्न सक्छ, र तिनीहरूको सुरक्षा सल्लाहहरू पनि समीक्षा गरिनुपर्छ।

अवयवहरू	पुष्टि संस्करण वा अद्यावधिक विधि	परिनियोजन विचारहरू
Node.js 24	24.22.1 वा उही शाखाको स्थिर संस्करण अपडेट गर्नुहोस्	रूट रिपोजिटरी अपडेटहरू र अवरुद्ध सार्वजनिक किचेनहरूको अस्वीकार समावेश गर्दछ; वास्तवमा सेवा द्वारा प्रयोग गरिएको Node पथ जाँच गर्नुहोस् र पुन: सुरु गर्नुहोस्
Python certifi	2026.10.19 वा नयाँ संस्करण	प्रत्येक वास्तविक चलिरहेको वातावरण जाँच गर्नुहोस्; तपाईले ग्लोबल Python अन्तर्गत एउटा मात्र प्याकेज अपडेट गर्न सक्नुहुन्न
pip	26.2.2 वा नयाँ संस्करण	पुरानो भर्चुअल वातावरणमा pip छुट्टै अपडेट गर्नुहोस् र नयाँ वातावरण सिर्जना भएपछि संस्करणको समीक्षा गर्नुहोस्।
uv	0.13.4 वा नयाँ संस्करण	उपकरणको प्रतिलिपि अद्यावधिक गर्नुहोस् किनकि यो वास्तवमा स्थापना भएको थियो
Go	1.27.3 वा 1.26.10, सम्बन्धित शाखाको अद्यावधिक संस्करण पनि उपलब्ध छ	उपकरण श्रृंखला अद्यावधिक गरेपछि सान्दर्भिक कार्यक्रमहरू पुन: निर्माण र तैनाती गर्नुहोस्, वा विक्रेताको मर्मत बाइनरी प्राप्त गर्नुहोस्।
Oracle JDK	सम्बन्धित समर्थित संस्करण लाइनहरूको लागि Critical प्याचहरू	विभिन्न JDK प्रकाशकहरूले आफ्नै घोषणाहरू पालना गर्छन्; सबै Java रिलीजहरूमा लागू हुने कुनै एकल संस्करण नम्बर छैन
Cloudflare Tunnel	cloudflared 2026.10.2 वा नयाँ संस्करण	चलिरहेको सेवाहरू अद्यावधिक गर्नुहोस्; कन्टेनर डिप्लोयमेन्टले छवि प्रतिस्थापन र पुन: प्रयोग गर्न आवश्यक छ
Cloudflare One／WARP	प्लेटफर्म वा अपडेट गरिएको स्थिर संस्करणसँग सम्बन्धित निश्चित ग्राहक संस्करण	क्लाइन्ट-साइड र सर्भर-साइड उपायहरू अलग-अलग पुष्टि गरिएका छन्। विशिष्ट प्लेटफर्म संस्करणहरूको लागि, परिशिष्ट 7 हेर्नुहोस्

को लागि मूल निर्देशन Node , Python , Go , Oracle र Cloudflare मा क्रमशः उपलब्ध छन् 13 , 12 , 14 , 15 , 7 .

Python स्वतन्त्र प्रमाणपत्र डाटाबेस समस्या

Python अधिकारीहरूले औंल्याए कि पुरानो pip ले प्रणाली विश्वास र निर्मित certifi को संयोजन प्रयोग गर्नेछ। केवल प्रणाली प्रमाणपत्र भण्डार परिमार्जन गर्न वा pip मा CA फाइल थप्दा यसको निर्मित पुरानो विश्वासलाई विश्वसनीय रूपमा बहिष्कार गर्न सकिँदैन। त्यसैले, PIP_CERT, REQUESTS_CA_BUNDLE वा --cert पुरानो pip को लागि विश्वव्यापी मर्मत प्रतिस्थापनको रूपमा प्रयोग गर्न सकिँदैन। 12

अद्यावधिक पछि अवस्थित भर्चुअल वातावरण जाँच गर्नुहोस्। साथै pip संस्करण वास्तवमा नयाँ सिर्जना गरिएको वातावरणमा स्थापना गरिएको जाँच गर्नुहोस् ताकि पुरानो बुटस्ट्र्याप कम्पोनेन्टहरूले कमजोर उपकरणहरू पुन: प्रस्तुत गर्दैनन्। प्रारम्भिक स्तरवृद्धिको लागि, अन्य प्याकेजहरू अद्यावधिक गर्नु अघि डाउनलोड स्रोतहरू र Python को सल्लाहमा SHA-256 प्रमाणीकरण चरणहरू पालना गर्नुहोस्। 12

Go र अन्य संकलित कार्यक्रमहरू

Go को लागि फिक्सले crypto/x509 को लागि प्रमाणीकरण तर्क परिवर्तन गर्यो। 14 डिप्लोइमेन्ट मेकानिजमको परिप्रेक्ष्यबाट, विकास मेसिनमा कम्पाइलर अपडेट गर्दा पहिले नै तैनाथ गरिएको बाइनरी पुन: लेखिने छैन। नयाँ कोड तह अवरुद्ध प्राप्त गर्न, अनुप्रयोगलाई पुन: निर्माण र प्रतिस्थापन गर्नुपर्छ, वा विक्रेता द्वारा प्रदान गरिएको अद्यावधिक संस्करण प्रयोग गर्नुपर्छ। पुरानो कार्यक्रमले प्रणाली रूट अद्यावधिकहरूबाट पनि लाभ उठाउन सक्छ कि यसले प्रयोग गर्ने वास्तविक प्रमाणिकरण मार्गमा निर्भर गर्दछ।

कन्टेनर र प्याकेज गरिएका अनुप्रयोगहरू

प्रणाली प्रमाणपत्र प्याकेज, अनुप्रयोग निर्भरता र कन्टेनरमा रनटाइम सामान्यतया छवि सामग्री द्वारा निर्धारण गरिन्छ। होस्ट अपडेट छवि सामग्री अद्यावधिकको बराबर छैन; आधारभूत छवि र निर्भरताहरू अद्यावधिक गर्न आवश्यक छ, र वास्तविक चलिरहेको उदाहरण पुन: निर्माण, तैनाती, र जाँच गर्न आवश्यक छ। प्याकेज गरिएका एप्लिकेसनहरू र डेस्कटप प्रोग्रामहरू जुन तिनीहरूको आफ्नै रनटाइमसँग आउँछन् पनि विक्रेता रिलीज च्यानलहरू अनुसार अद्यावधिक गरिनु पर्छ। 7 10

6 मर्मत कार्यान्वयन निर्देशनहरू

पहिले निरीक्षण वस्तु निर्धारण गर्नुहोस्

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

परियोजना	के रेकर्ड गर्न आवश्यक छ
अनुप्रयोग र प्रयोगहरू	ब्राउजर, भुक्तानी API ग्राहक, इमेल पठाउने सेवा, डाउनलोड उपकरण, रिभर्स प्रोक्सी, आदि।
सञ्चालन स्थिति	होस्ट, कन्टेनर, भर्चुअल मेसिन, डेस्कटप अनुप्रयोग वा मोबाइल उपकरण
कार्यान्वयन प्रमाणित गर्नुहोस्	अपरेटिङ सिस्टम प्रमाणीकरणकर्ता, OpenSSL, Node, Python पुस्तकालय, Java वा अनुप्रयोग अनुकूलन कार्यान्वयन
विश्वसनीय स्रोत	प्रणाली CA प्याकेज, certifi, JDK ट्रस्ट स्टोर, निर्मित CA bundle वा उद्यम कन्फिगरेसन
मर्मत स्थिति	स्थापना गरिएको संस्करण, प्याच स्रोत, पुन: सुरु गर्ने वा पुन: प्रयोग गर्ने
स्वीकृति परिणामहरू	प्रभावित चेन अस्वीकार गरिएको छ कि छैन, सामान्य व्यापार जडान सफल छ कि छैन, र जाँच समय

Cloudflare को लागि विकासकर्ता गाइडले विशेष रूपमा बताउँछ कि SDK ले अन्य घटकहरूलाई प्रमाणीकरण प्रत्यायोजित गर्न सक्छ; केवल शीर्ष-स्तर SDK अद्यावधिक गर्दा वास्तविक विश्वास नीति परिवर्तन हुँदैन। 7

अपरेटिङ सिस्टम र ब्राउजरहरू

Windows: स्वचालित प्रमाणपत्र विश्वास सूची अद्यावधिकहरू सक्षम र प्रमाणित गर्नुहोस्। स्थापित व्यवस्थापन नीतिहरू मार्फत अद्यावधिकहरू वितरण गर्नुहोस्। अफलाइन यन्त्रहरू वा स्वचालित अद्यावधिकहरू असक्षम गरिएका यन्त्रहरूलाई उपयुक्त व्यवस्थापन प्रक्रिया मार्फत लागू गरिएको ब्लक चाहिन्छ। Windows प्रणाली प्रमाणीकरणलाई छुट्टै प्रयोग नगर्ने कार्यक्रमहरू जाँच गर्नुहोस्। 4

Apple प्लेटफर्म: पूरा प्रणाली, सुरक्षा घटक र अनुप्रयोग अद्यावधिकहरू। macOS मा विकास उपकरणहरूको लागि, यसको TLS ब्याकइन्ड, प्रमाणपत्र फाइलहरू र स्थापना स्रोतहरू पनि जाँच गर्नुहोस्। Safari ले परीक्षण चेनलाई अस्वीकार गरेकोले मात्र सम्पूर्ण मेसिन मर्मत गरिएको छ भनेर न्याय गर्न सकिँदैन। 4

Android: Google Play सेवाहरू भएका यन्त्रहरूमा अपडेट गर्नुहोस्। Google ले यन्त्र पुन: सुरु गर्दा तत्काल अद्यावधिक ट्रिगर गर्न सक्छ। ती सेवाहरू नभएका यन्त्रहरूका लागि, विक्रेता वा ROM सल्लाह पालना गर्नुहोस्; Google को कभरेज कथन प्रत्येक Android उपकरणमा स्वचालित रूपमा लागू हुँदैन। 1

Ubuntu/Debian: समर्थित भण्डारहरूबाट प्रमाणपत्र प्याकेजहरू अद्यावधिक गर्नुहोस् र स्थापित वितरणको लागि सल्लाहकार जाँच गर्नुहोस्। उदाहरणका लागि, APT-आधारित प्रणालीले प्रयोग गर्न सक्छ:

sudo apt update
sudo apt install --only-upgrade ca-certificates
dpkg-query -W -f='${Package} ${Version}\n' ca-certificates

Ubuntu 22.04, 24.04, 26.04, र 26.10 का लागि सान्दर्भिक अद्यावधिकहरू मानक समर्थन हुन्; अघिल्लो संस्करणहरूले ESM समर्थन र गोदाम स्थिति जाँच गर्नुपर्छ। आदेश सफलतापूर्वक समाप्त भएपछि, तपाईंले अझै पनि बुलेटिनमा फिक्स प्याक संस्करण तुलना गर्नुपर्छ। 8 9

RHEL र सम्बन्धित उत्पादनहरू: प्रमाणपत्र प्याकेज र उत्पादन च्यानल द्वारा सुरक्षा त्रुटि जाँच गर्नुहोस्। संस्करण जाँच प्रयोग गरेर गर्न सकिन्छ:

rpm -q ca-certificates

विक्रेता प्याचहरू प्राप्त गर्न समर्थित DNF/YUM अद्यावधिक संयन्त्र प्रयोग गर्नुहोस्; यदि च्यानलले अझै फिक्स प्रदान गरेको छैन भने, “कुनै अद्यावधिक गर्न मिल्ने प्याकेज” लाई सुरक्षित नठान्नुहोस्। जब यो अस्थायी रूपमा रूट विश्वास हटाउन आवश्यक छ, निर्माता द्वारा स्पष्ट रूपमा सूचीबद्ध उपायहरू अपनाउनुहोस् र वैध व्यापार प्रमाणपत्रहरूको अनुकूलता मूल्याङ्कन गर्नुहोस्। 10

FreeBSD: आधिकारिक सल्लाहकारले निर्देशन दिए अनुसार सान्दर्भिक प्रणाली शाखा अपडेट गर्नुहोस्, त्यसपछि प्रभावित OpenSSL ट्रस्ट कन्फिगरेसन प्रयोग गरेर डेमनहरू पुनः सुरु गर्नुहोस् वा प्रणाली रिबुट गर्नुहोस्। 11

अनुप्रयोग र छविहरू

सम्बन्धित रनटाइम र प्रमाणपत्र निर्भरता अद्यावधिकहरू पूरा गरेपछि, टर्मिनलले नयाँ संस्करणमा स्विच गरेको छ र डेमनले अझै पनि पुरानो स्थापना डाइरेक्टरी प्रयोग गर्छ भन्ने कुराबाट बच्न सेवा वास्तवमा चलिरहेको छ जहाँ कार्यान्वयनयोग्य फाइल मार्ग जाँच गर्नुहोस्। बहु-पर्यावरण Python, सेवा कन्टेनरहरू र अनुप्रयोगहरू जुन तिनीहरूको आफ्नै रनटाइमसँग आउँछन्, तिनीहरू छुट्टै जाँच गर्नुपर्छ।

पुन: निर्माण गर्न आवश्यक कम्पोनेन्टहरूका लागि, निर्माण संस्करण, निर्भरता संस्करण, र डिप्लोइमेन्ट छवि ID बचत गर्नुहोस्। स्वीकृति वस्तु वास्तविक चलिरहेको उदाहरण हो र निर्माण मेसिन वा छवि रजिस्ट्रीमा नयाँ ट्याग मात्र जाँच गर्न सक्दैन। 7 12 14

वेबसाइट प्रमाणपत्र माइग्रेसन

यदि वेबसाइटको चेनमा रद्द गरिएको वा अवरुद्ध मध्यवर्ती CA समावेश छ, वा अन्ततः एक अविश्वासित रूटमा निर्भर छ भने, ग्राहकहरूले अझै पनि स्वीकार गर्ने अर्को श्रृंखला प्राप्त गर्नुहोस्। पूर्ण सर्भर सर्टिफिकेट चेन स्थापना गर्नुहोस् र लोड ब्यालेन्सरहरू, रिभर्स प्रोक्सीहरू, CDN अन्त्य बिन्दुहरू, र प्रत्यक्ष पहुँचयोग्य मूलहरू सहित प्रत्येक प्रवेश जाँच गर्नुहोस्। 1 5

माइग्रेसन आवश्यक छ कि छैन वास्तविक श्रृंखलामा आधारित छ। प्रमाणपत्र बिक्री ब्रान्डद्वारा मात्र फिल्टर गर्दा पुनर्विक्रय वा क्रस-साइनिङ सम्बन्धहरू छुट्न सक्छ; नियमित म्याद समाप्ति नवीकरणको लागि मात्र पर्खनुले रूट स्टोर अद्यावधिक हुनु अघि माइग्रेसन पूरा नगर्न सक्छ।

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

7 निश्चित गर्नुहोस् कि फिक्सले वास्तवमा प्रभाव पार्छ

संस्करण जाँच र व्यवहार जाँच अलग प्रदर्शन गरिन्छ

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

घटना संरक्षकले परीक्षण साइट र प्रमाणपत्र श्रृंखला सामग्रीहरू प्रदान गर्दछ, र प्रवेश द्वार परिशिष्ट 4 मा केन्द्रित छ। यो सामान्य प्रमाणपत्र प्रमाणिकरण कन्फिगरेसन कायम राख्दै, लक्ष्य अनुप्रयोगको वास्तविक परिचालन वातावरणमा प्रमाणित गरिनु पर्छ। 4 7

परिणामहरू जाँच गर्नुहोस्	निष्कर्ष निकाल्न सकिन्छ
स्पष्ट रूपमा अस्वीकार गर्नुहोस् किनभने प्रभावित चेन विश्वसनीय छैन	प्रमाणीकरण मार्ग परिक्षण गरिएको चेन अस्वीकृत भएको संकेत गर्दछ
प्रभावित चेनलाई सामान्य रूपमा स्वीकार गर्नुहोस्	यो मार्ग मर्मत गर्न वा कन्फिगरेसन जाँच गर्न जारी राख्न आवश्यक छ भनेर संकेत गर्दछ।
DNS त्रुटि, जडान टाइमआउट, प्रोक्सी अस्वीकार वा सेवा पहुँचयोग्य छैन	यसका आधारमा सर्टिफिकेटको जोखिम हट्यो भन्ने निष्कर्षमा पुग्न सकिँदैन।
ब्राउजरले अस्वीकार गर्छ, तर एप कल जाँच गरिएको छैन	यसले ब्राउजरलाई मात्र पुष्टि गर्न सक्छ, पृष्ठभूमि कार्यक्रम होइन।
A चेन अस्वीकार गरियो	अझै पनि विचार गर्न आवश्यक छ कि ग्राहकले अर्को क्रस-साइनिङ मार्ग स्वीकार गर्दछ

परीक्षणले सामान्य व्यापार जडानहरू पनि कभर गर्नुपर्दछ सबै अनुरोध विफलताहरूलाई गलत नहोस् किनभने व्यापार असफलताहरू पछि सफल मर्मतहरू धेरै विश्वास हटाउनको कारणले गर्दा हुन्छ।

सुझाव पूरा सर्तहरू

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

माथिको समाप्ति सर्तहरू यस निपटानको लागि सञ्चालन र मर्मत स्वीकृतिको लागि सुझावहरू हुन्; यो उपकरणमा कुनै अन्य सुरक्षा समस्याहरू छैनन् भनेर प्रमाणित गर्न बराबर छैन।

8 ऐतिहासिक HTTPS यातायात र जोखिम सीमाहरू

तीन प्रकारका कुञ्जीहरू फरक फरक प्रयोगहरू छन्

कुञ्जी	मुख्य उद्देश्य
CA निजी कुञ्जी	प्रमाणपत्रमा पहिचान र सार्वजनिक कुञ्जी बाध्यकारी हस्ताक्षर गर्नुहोस्
वेबसाइट निजी कुञ्जी	प्रमाणपत्र प्रमाणिकरण TLS ह्यान्डशेकमा सर्भर पहिचान प्रमाणित गर्नुहोस्
सत्र कुञ्जी	वास्तवमा जडानमा प्रसारित डाटा सुरक्षित गर्नुहोस्

CA निजी कुञ्जी प्राप्त गर्नु भनेको वेबसाइट निजी कुञ्जी वा सबै सत्र कुञ्जीहरू प्राप्त गर्न बराबर होइन। A अस्थायी कुञ्जी आदानप्रदानको प्रयोग गरेर अगाडि गोप्यतासँग सामान्य जडानले ऐतिहासिक सत्रहरू स्वतः खुलासा गर्दैन किनभने लामो-समय हस्ताक्षर कुञ्जी पछि सम्झौता गरिएको छ। TLS 1.3 को सान्दर्भिक सुरक्षा विशेषताहरूको लागि, RFC 8446 हेर्नुहोस्। 16

मुख्य जोखिम यस पटक प्रमाणीकरण चरणको समयमा हुन्छ: यदि ग्राहकले नक्कली सर्भरको प्रमाणपत्र स्वीकार गर्दछ भने, यसले आक्रमणकर्तासँग जडान स्थापित गर्न सक्छ जुन अझै पनि गुप्तिकरण गरिएको छ। TLS 1.3 लाई पनि विश्वसनीय प्रमाणीकरण चाहिन्छ; केवल प्रोटोकल संस्करण अपग्रेड गर्नु CA ब्लक गर्ने विकल्प होइन।

वर्तमानमा गर्न सकिने र नहुने निर्णयहरू

पुष्टि गरिएको: विशिष्ट मध्यवर्ती CA निजी कुञ्जीहरू सम्झौता गरिएका छन्; प्रभावित सार्वजनिक विश्वास मार्गहरू व्यापक पहुँच छन्; प्रमुख प्लेटफर्महरू र धेरै सफ्टवेयर इकोसिस्टमहरूले कारबाही गरेका छन्। 1 4 5

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

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

परिशिष्ट A प्रभावित मध्यवर्ती CA नाम

निम्न नामहरूले सम्पत्ति जाँच गर्न मद्दत गर्दछ। नामहरूले प्रमाणपत्र फिंगरप्रिन्टहरू वा सार्वजनिक-कुञ्जी पहिचानकर्ताहरू प्रतिस्थापन गर्दैनन्। स्वचालित मिलानले क्रस-हस्ताक्षरित प्रमाणपत्रहरू सहित घटना मर्मतकर्ता वा विक्रेताहरूद्वारा प्रकाशित सटीक पहिचानकर्ताहरू प्रयोग गर्नुपर्छ। 5

मध्य CA	उद्देश्य	सम्बद्ध संस्थाहरू
EM EV TLS CA - G3B	TLS	eMudhra BV
EM OV TLS CA - G3B	TLS	eMudhra BV
EM DV TLS CA - G3B	TLS	eMudhra BV
EM EV TLS CA - G3C	TLS	eMudhra Inc
EM OV TLS CA - G3C	TLS	eMudhra Inc
EM DV TLS CA - G3C	TLS	eMudhra Inc
EM OV CS CA - G3B	कोड हस्ताक्षर	eMudhra BV
EM OV CS CA - G3C	कोड हस्ताक्षर	eMudhra Inc

TLS कोड हस्ताक्षरको रूपमा ठ्याक्कै उही प्रमाणीकरणकर्ता र रद्द गर्ने संयन्त्र होइन। यस लेखको फोकस HTTPS/TLS हो; कोड साइनिङ वातावरणले Microsoft, JDK वा यस प्रमाणीकरण उद्देश्यका लागि सम्बन्धित सफ्टवेयर विक्रेताहरू अपनाउनुपर्छ, र ब्राउजर परीक्षण परिणामहरूलाई कोड हस्ताक्षर स्वीकृतिको रूपमा लिनु हुँदैन। 5 15

परिशिष्ट B सन्दर्भ लिङ्क

निम्न स्रोतहरू अक्टोबर 22, 2026 मा प्रमाणित गरिएको थियो। रोलिङ घोषणा अद्यावधिक हुन जारी रहन सक्छ, र पाठमा रहेको स्थिति र संस्करण यस कागजातको मितिको आधारमा बुझ्नुपर्छ।

घटना तथ्य र प्लेटफर्म ह्यान्डलिंग

[1] Google Chrome र Android आधिकारिक घोषणा निजी कुञ्जी त्रुटिहरू, SPKI अवरुद्ध, Google Play सेवा वितरण, CT सुरक्षा, र Chrome रूट रिपोजिटरी हटाउने योजनाहरू वर्णन गर्दछ। Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates

[2] Mozilla Bugzilla 2083449 घटना रेकर्ड मौलिक रिपोर्टहरू, स्वतन्त्र प्रमाणिकरण, जेनरेशन प्रक्रिया अनुसन्धान, Firefox Android का लागि पछिका फिक्सहरू, र कानुनी प्रमाणपत्र माइग्रेसन छलफलहरू समावेश गर्दछ; टिप्पणी 5, 11, 29, र 30 मा फोकस गर्नुहोस्। eMudhra Private key compromise of Intermediate Certificates

[3] Mozilla Firefox सुरक्षा सूचना OneCRL आपतकालीन वितरण र त्यसपछिको Firefox/NSS निपटानको विवरण। Protecting Firefox users following the compromise of eMudhra intermediate certificates

[4] घटना संयोजक Dennis Jackson मर्मत सारांश र पत्ता लगाउने पोर्टल प्लेटफर्म र सफ्टवेयर मर्मत स्थिति, परीक्षण प्रवेश, सार्वजनिक प्रमाणपत्र श्रृंखला सामग्री, र Windows/macOS जस्ता वातावरणहरूमा पूरक निर्देशनहरू प्रदान गर्दछ। परीक्षण परिणामहरूले मात्र परीक्षण गरिएका वास्तविक प्रमाणिकरण पथहरू प्रतिनिधित्व गर्दछ। eMudhra Intermediate CA Compromise

[5] Mozilla वितरण र ट्रस्टस्टोर मर्मतकर्ताहरूलाई सूचना 6 TLS र 2 कोड साइनिंग मध्यवर्ती CA, Sectigo क्रस-साइनिङ, रिभोकेशन, र रूट ट्रस्ट प्रशोधन सीमाहरू वर्णन गर्दछ, र सही प्रमाणपत्र र सार्वजनिक कुञ्जी पहिचान सूचीबद्ध गर्दछ। oss-security eMudhra Intermediates Compromise

[6] eMudhra आधिकारिक घटना बयान मुख्य उत्पादन प्रक्रियाको निर्माताको प्रारम्भिक व्याख्या प्रदान गर्नुहोस्; सही मूल कारण अझै पनि पूरा अनुसन्धानको निष्कर्षको अधीनमा हुनेछ। eMudhra Statement on Recent Certificate Security Incident

[7] Cloudflare आधिकारिक घटना र मर्मत निर्देशन WARP, Cloudflare Tunnel, मूल साइट प्रमाणिकरण, रनटाइम निर्भरताहरू, छवि अद्यावधिकहरू र प्रमाणीकरण विधिहरू समावेश गर्दछ। 8 eMudhra certificates are compromised Here is what you need to know

सञ्चालन प्रणाली र वितरण

[8] Ubuntu आधिकारिक मर्मत घोषणा ca-certificates फिक्स प्याकेजहरू, समर्थन च्यानलहरू र प्रत्येक संस्करणको लागि लक्षित अद्यावधिक चरणहरू सूचीबद्ध गर्दछ। eMudhra CA compromise fixes available

[9] Debian आधिकारिक समस्या र मरम्मत रेकर्ड मर्मतकर्ताको फिक्स रेकर्ड र सम्बन्धित रिलीज प्याकेजलाई मानकको रूपमा लिनुपर्छ, र समस्या छलफलमा प्रारम्भिक अस्थायी सुझावहरूलाई अन्तिम समाधानको रूपमा लिनु हुँदैन। Debian bug 1151413 eMudhra Intermediate CA key compromise

[10] Red Hat आधिकारिक सुरक्षा बुलेटिन RHSB 2026 012 RHEL 6 मार्फत 10, सम्बन्धित उत्पादन र कन्टेनर प्रभावहरू, र रिलीज र अन्तरिम डिस्पोजल प्रविष्टिहरू फिक्स गर्नुहोस्। Certificate compromise eMudhra

[11] FreeBSD आधिकारिक सुरक्षा बुलेटिन प्रभावित प्रणाली शाखाहरू, मर्मत संस्करणहरू र सेवा पुन: सुरु आवश्यकताहरू प्रदान गर्नुहोस्। FreeBSD SA 26 73 caroot

रनटाइम र प्रोटोकलहरू

[12] Python आधिकारिक घटना विवरण pip, certifi, uv, इत्यादिको लागि मर्मत आधार रेखाहरू प्रदान गर्दछ, पुरानो pip स्वतन्त्र ट्रस्ट स्टोरको समस्या बताउँछ, र SHA-256 प्रमाणीकरणको साथ प्रारम्भिक स्तरवृद्धि विधि प्रदान गर्दछ। Information for Python users regarding eMudhra emSign CA certificate security incident

[13] Node.js 24.22.1 आधिकारिक रिलीज NSS रूट स्टोर अपडेटहरू समावेश गर्दछ र अवरुद्ध सार्वजनिक कुञ्जी प्रमाणपत्र चेनहरू समावेश गरिएका परिवर्तनहरू अस्वीकार गर्दछ। Node.js 24.22.1 security release

[14] Go आधिकारिक सुरक्षा रिलीज विवरण crypto/x509 प्रमाणपत्र श्रृंखला फिल्टरिङ अपडेट Go 1.27.3/1.26.10. को लागि Go 1.27.3 and Go 1.26.10 are released

[15] Oracle JDK आधिकारिक निपटान निर्देशन JDK क्रिटिकल प्याच र सम्बन्धित कन्फिगरेसन उपायहरू व्याख्या गर्नुहोस् जब यसलाई तुरून्त अपग्रेड गर्न सकिँदैन। Distrusting eMudhra Intermediate Certificates in Oracle JDK

[16] TLS 1.3 प्रोटोकल मानक RFC 8446 परिशिष्ट E.1 पहिचान प्रमाणीकरण, अस्थायी कुञ्जी आदानप्रदान र फर्वार्ड गोप्यतामा निर्देशनहरूको लागि हेर्नुहोस्। The Transport Layer Security Protocol Version 1.3

[17] घटना-सम्बन्धित मूल प्रमाणपत्र र जारी सम्बन्ध डेटा प्रत्यक्ष जारीकर्ता र क्रस-हस्ताक्षर सम्बन्ध बुझ्न प्रयोग गरियो; रूट स्टोर समावेश स्थितिले ग्राहकको पछिल्लो रद्दीकरण वा अवरुद्ध स्थितिलाई प्रतिस्थापन गर्न सक्दैन। Root certificate relationships JSON