कार्यकारी सारांश

FindAll वर्डप्रेस थीम (संस्करण ≤ 1.4) में एक स्थानीय फ़ाइल समावेश (LFI) सुरक्षा दोष को सार्वजनिक रूप से उजागर किया गया है और इसे CVE-2026-22478 सौंपा गया है। यह दोष अनधिकृत हमलावरों को लक्षित साइट से स्थानीय फ़ाइलों को शामिल करने और प्रदर्शित करने की अनुमति देता है, जिससे संभावित रूप से रहस्यों (डेटाबेस क्रेडेंशियल, कॉन्फ़िग फ़ाइलें) का खुलासा होता है, जिससे दूरस्थ कोड निष्पादन जैसे आगे के हमलों की अनुमति मिलती है, या सर्वर कॉन्फ़िगरेशन के आधार पर पूर्ण साइट समझौता करने की अनुमति मिलती है।.

हांगकांग और व्यापक क्षेत्र में एक प्रैक्टिशनर के दृष्टिकोण से, यह एक उच्च-जोखिम मुद्दा है (CVSS ~8.1)। स्वचालित स्कैनर और बॉटनेट्स खुलासे के तुरंत बाद बड़े पैमाने पर शोषण करने का प्रयास करेंगे। जहां विक्रेता पैच अभी उपलब्ध नहीं हैं, वहां तत्काल शमन की आवश्यकता है।.

नोट: यह सलाह शोषण स्तर के निर्देशों से बचती है। इसका उद्देश्य जोखिम को कम करने और जिम्मेदारी से प्रतिक्रिया देने के लिए प्रशासकों के लिए त्वरित, व्यावहारिक मार्गदर्शन प्रदान करना है।.

इस सलाह के बारे में

• प्रभावित सॉफ़्टवेयर: FindAll वर्डप्रेस थीम
• प्रभावित संस्करण: ≤ 1.4
• सुरक्षा कमजोरी का प्रकार: स्थानीय फ़ाइल समावेश (LFI)
• CVE: CVE-2026-22478
• आवश्यक विशेषाधिकार: कोई नहीं (बिना प्रमाणीकरण)
• गंभीरता: उच्च (CVSS 8.1)
• पैच स्थिति: प्रकाशन के समय कोई आधिकारिक पैच उपलब्ध नहीं है

स्थानीय फ़ाइल समावेश क्या है और यह क्यों खतरनाक है

स्थानीय फ़ाइल समावेश तब होता है जब एक एप्लिकेशन उपयोगकर्ता-नियंत्रित इनपुट को स्वीकार करता है ताकि सर्वर फ़ाइल सिस्टम से शामिल करने या पढ़ने के लिए एक फ़ाइल निर्दिष्ट की जा सके बिना उचित सत्यापन के। जब एक हमलावर उस इनपुट को नियंत्रित करता है, तो वे:

• संवेदनशील कॉन्फ़िगरेशन फ़ाइलें (जैसे, wp-config.php, .env) पढ़ सकते हैं और डेटाबेस क्रेडेंशियल और गुप्त कुंजी प्राप्त कर सकते हैं।.
• डेटाबेस, बाहरी सेवाओं, या वर्डप्रेस प्रशासनिक खातों तक पहुँचने के लिए क्रेडेंशियल्स एकत्रित करें।.
• श्रृंखला हमले: क्रेडेंशियल्स प्राप्त करने के लिए एक फ़ाइल पढ़ें, फिर उन क्रेडेंशियल्स का उपयोग करके सामग्री को संशोधित करें, एक वेबशेल इंजेक्ट करें, या डेटाबेस तक पहुँचें।.
• हमलावर द्वारा प्रदान किए गए PHP कोड (यदि PHP को लिखने योग्य निर्देशिकाओं में निष्पादित किया जाता है तो RCE की ओर ले जाने वाला) को शामिल करने के लिए लॉग फ़ाइलों या अपलोड को ट्रिगर करें।.
• सर्वर पथ जानकारी को उजागर करें जो आगे के शोषण में मदद करती है।.

क्योंकि यह LFI बिना प्रमाणीकरण के शोषण योग्य है और एक सामान्य थीम फ़ाइल पथ को लक्षित करता है, प्रभावित साइटों को इसे एक तात्कालिक संचालन प्राथमिकता के रूप में मानना चाहिए।.

वास्तविक शोषण परिदृश्य

LFI के लिए सामान्य हमलावर कार्यप्रवाह में शामिल हैं:

1. कॉन्फ़िगरेशन फ़ाइलों (wp-config.php, .env) को सूचीबद्ध करें और पढ़ें ताकि DB क्रेडेंशियल्स और गुप्त कुंजियों को निकाला जा सके।.
2. खुफिया के लिए सिस्टम फ़ाइलें पढ़ें (जैसे, /etc/passwd) और बैकअप या डेवलपर फ़ाइलें जो गुप्त जानकारी रख सकती हैं।.
3. लॉग विषाक्तता या अपलोड-नियंत्रित फ़ाइल समावेश का उपयोग करें ताकि कोड निष्पादन प्राप्त किया जा सके जब सर्वर बाद में उन फ़ाइलों को शामिल करता है।.
4. निरंतर पहुंच प्राप्त करने के लिए निकाले गए क्रेडेंशियल्स का उपयोग करें: व्यवस्थापक उपयोगकर्ता बनाएं, सामग्री संशोधित करें, या बैकडोर अपलोड करें।.

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

समझौते के संकेत (IoCs) और किस पर ध्यान देना है

इन संकेतों के लिए लॉग और फ़ाइल प्रणाली की स्थिति की समीक्षा करें:

सर्वर एक्सेस लॉग

• ऐसे अनुरोध जिनमें पैरामीटर जैसे फ़ाइल=, शामिल=, पृष्ठ=, टेम्पलेट=, पथ=, या दृश्य= के साथ मिलकर ../ या एन्कोडेड ट्रैवर्सल टोकन (%2e%2e%2f).
• डबल-एन्कोडेड ट्रैवर्सल अनुक्रम जैसे %252e%252e%252f.
• फ़etch करने का प्रयास करने वाले अनुरोध /etc/passwd, wp-config.php, .env, php://filter/convert.base64-encode/resource=, या data://.
• ट्रैवर्सल-पैटर्न अनुरोधों के लिए 4xx/5xx प्रतिक्रियाओं में स्पाइक्स।.

अनुरोध निकाय

• POST या GET पैरामीटर जिसमें शामिल हैं .., %2f, php://, रैपर और फ़िल्टर को अस्वीकार करें:, या लंबे base64 ब्लॉब।.

फ़ाइल प्रणाली और सामग्री

• अपलोड, कैश, या थीम निर्देशिकाओं में नए या संशोधित PHP फ़ाइलें।.
• अप्रत्याशित व्यवस्थापक उपयोगकर्ता या परिवर्तित साइट सेटिंग्स (साइट URL, व्यवस्थापक ईमेल)।.
• संदिग्ध अनुसूचित कार्य या अज्ञात प्रविष्टियाँ 11. संदिग्ध सामग्री के साथ।.

डेटाबेस

• पोस्ट या विकल्पों में अप्रत्याशित सामग्री जिसमें एन्क्रिप्टेड PHP या स्क्रिप्ट शामिल हैं।.
• नए डेटाबेस उपयोगकर्ता या संशोधित विशेषाधिकार।.

यदि आप इन संकेतों को देखते हैं, तो साइट को संभावित रूप से समझौता किया गया मानें और नीचे दिए गए घटना प्रतिक्रिया चेकलिस्ट का पालन करें।.

तात्कालिक उपाय (अल्पकालिक, पूर्व-पैच)

यदि आपकी साइट FindAll थीम (≤ 1.4) का उपयोग करती है, तो इन क्रियाओं को तुरंत लागू करें:

1. एक बैकअप लें (फाइलें + डेटाबेस)

   कोई भी परिवर्तन करने से पहले एक पूर्ण ऑफ़लाइन बैकअप करें। यदि आवश्यक हो तो फोरेंसिक विश्लेषण के लिए सर्वर से एक प्रति बनाए रखें।.

2. साइट को रखरखाव मोड में डालें (यदि उपयुक्त हो)

   जब आप उपाय कर रहे हों, तो आगे के स्वचालित हमलों को सीमित करें।.

3. कमजोर थीम को हटा दें या निष्क्रिय करें

   यदि संभव हो, तो एक सुरक्षित सक्रिय थीम पर स्विच करें। यदि थीम आवश्यक है और इसे जल्दी से नहीं बदला जा सकता, तो अस्थायी रूप से साइट को ऑफ़लाइन ले जाने और एक स्थिर पृष्ठ प्रदान करने पर विचार करें।.

4. कमजोर अंत बिंदुओं तक पहुंच को प्रतिबंधित करें

   उन विशिष्ट थीम फ़ाइलों तक सार्वजनिक पहुंच को अवरुद्ध करें जो वेब सर्वर नियमों के माध्यम से शामिल पैरामीटर स्वीकार करती हैं। अपलोड/कैश/टेम्प निर्देशिकाओं में सार्वजनिक रूप से लिखने योग्य PHP निष्पादन को अक्षम करें।.

5. तुरंत WAF / आभासी पैच नियम लागू करें

   यदि आप एक वेब एप्लिकेशन फ़ायरवॉल या होस्ट-आधारित नियम सेट का प्रबंधन करते हैं, तो नियम लागू करें जो:

   • निर्देशिका यात्रा पैटर्न को ब्लॉक करें: ../, %2e%2e%2f, ..%2f, %2e%2e%5c.
   • संदिग्ध रैपर को अवरुद्ध करें: php://, रैपर और फ़िल्टर को अस्वीकार करें:, expect://, फ़ाइल://.
   • संवेदनशील फ़ाइलों तक पहुंचने का प्रयास करने वाले अनुरोधों को अवरुद्ध करें: wp-config.php, .env, config.php.
   • अवरुद्ध करें php://filter फ़ाइल पढ़ने के लिए उपयोग की जाने वाली संरचनाएँ।.

   फ़ाइलों का चयन करने के लिए उपयोग किए जाने वाले किसी भी पैरामीटर के लिए एक श्वेतसूची को प्राथमिकता दें, जहां संभव हो केवल ज्ञात-सुरक्षित फ़ाइल नामों की अनुमति दें।.

6. फ़ाइल अनुमतियों को मजबूत करें

   सुनिश्चित करें wp-config.php यह विश्व-पढ़ने योग्य नहीं है। अपलोड/कैश निर्देशिकाओं को प्रतिबंधात्मक अनुमतियों पर सेट करें और इन निर्देशिकाओं में PHP निष्पादन को अक्षम करें .htaccess या सर्वर कॉन्फ़िगरेशन।.

7. दुर्भावनापूर्ण फ़ाइलों और संदिग्ध संशोधनों के लिए स्कैन करें

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

8. यदि एक्सपोजर का संदेह हो तो रहस्यों को घुमाएँ

   यदि आपको संकेत मिलते हैं कि wp-config.php या अन्य रहस्यों तक पहुँच प्राप्त की गई है, तो तुरंत डेटाबेस क्रेडेंशियल्स और किसी भी प्रभावित API कुंजी या टोकन को बदलें।.

9. लॉग को ध्यान से मॉनिटर करें

   शोषण के प्रयासों और असामान्य गतिविधियों के लिए एक्सेस और त्रुटि लॉग पर नज़र रखें।.

अनुशंसित WAF नियम (सैद्धांतिक उदाहरण)

नीचे सामान्य LFI शोषण पैटर्न को ब्लॉक करने के लिए रक्षात्मक नियम अवधारणाएँ दी गई हैं। अपने WAF के लिए वाक्यविन्यास को अनुकूलित करें और व्यापक तैनाती से पहले स्टेजिंग में परीक्षण करें।.

उच्च-स्तरीय जांच

• उन पैरामीटर मानों को ब्लॉक करें जिनमें \.\./ या %2e%2e%2f (केस-संवेदनशीलता-मुक्त).
• उन मानों को ब्लॉक करें जिनमें php://, रैपर और फ़िल्टर को अस्वीकार करें:, फ़ाइल://, expect://.
• अनुरोधों को ब्लॉक करें जो शामिल हैं wp-config.php या .env क्वेरी स्ट्रिंग या बॉडी में।.
• जहाँ संभव हो फ़ाइल-चयन पैरामीटर के लिए अनुमति-सूचियों को प्राथमिकता दें।.

ModSecurity (उदाहरण नियम — अपने वातावरण के अनुसार अनुकूलित करें)

# Block common directory traversal attempts
SecRule ARGS|ARGS_NAMES|REQUEST_URI "(?:\.\./|\.\.\\|%2e%2e%2f|%2e%2e%5c)" "id:100001,phase:2,deny,log,msg:'Detect Directory Traversal LFI attempt'"

# Block access to wp-config.php or .env via query string or body
SecRule REQUEST_URI|ARGS|REQUEST_HEADERS "(wp-config\.php|\.env|config\.php)" "id:100002,phase:2,deny,log,msg:'Blocked attempt to access sensitive file'"

# Block php wrappers
SecRule ARGS|REQUEST_URI "(?:php://|data:|expect://|file://|phar://)" "id:100003,phase:2,deny,log,msg:'Blocked wrapper usage in input'"

# Optional: detect file-selection parameters for closer inspection
SecRule ARGS_NAMES "file|template|include|page|view|path" "id:100004,phase:2,pass,log,msg:'Detected file selection parameter'"

wp-config.php या .env तक क्वेरी स्ट्रिंग या बॉडी के माध्यम से पहुँच को ब्लॉक करें

# Deny requests that contain traversal patterns
if ($request_uri ~* "\.\./|%2e%2e%2f") {
    return 403;
}

# Deny parameters that mention wp-config.php
if ($query_string ~* "wp-config\.php|\.env") {
    return 403;
}

वैकल्पिक: निकट निरीक्षण के लिए फ़ाइल-चयन पैरामीटर का पता लगाएँ.

Nginx (सैद्धांतिक उदाहरण)

अनुरोधों को अस्वीकार करें जो ट्रैवर्सल पैटर्न को शामिल करते हैं

• उन पैरामीटर को अस्वीकार करें जो wp-config.php का उल्लेख करते हैं.
• अनुरोध जो शामिल हैं php://filter उपयोग।.
• फ़etch करने का प्रयास करने वाले अनुरोध wp-config.php, .env, या /etc/passwd एप्लिकेशन के माध्यम से।.
• असामान्य उपयोगकर्ता-एजेंट या आईपी जो बार-बार LFI-जैसे प्रयास कर रहे हैं।.

केवल पहचान मोड फोरेंसिक सबूत प्रदान करता है और आपको ब्लॉक करने से पहले नियमों को समायोजित करने देता है।.

घटना प्रतिक्रिया चेकलिस्ट (चरण-दर-चरण)

1. सीमित करें

   आगे के प्रयासों को रोकने के लिए WAF नियम लागू करें (पैटर्न या आपत्तिजनक आईपी को ब्लॉक करें)। यदि आवश्यक हो तो साइट को ऑफलाइन करें।.

2. संरक्षित करें

   लॉग, फ़ाइलों और डेटाबेस स्नैपशॉट की फोरेंसिक प्रतियां बनाएं। विश्लेषण के लिए किसी भी संदिग्ध फ़ाइलों को संरक्षित करें।.

3. पहचानें

   वेबशेल और अप्रत्याशित PHP फ़ाइलों के लिए स्कैन करें। संदिग्ध पैरामीटर और अनुरोधों के लिए एक्सेस और त्रुटि लॉग की जांच करें।.

4. समाप्त करें

   पहचाने गए बैकडोर और दुर्भावनापूर्ण फ़ाइलों को हटा दें। समझौता की गई फ़ाइलों को विश्वसनीय बैकअप से साफ़ प्रतियों के साथ बदलें।.

5. पुनर्प्राप्त करें

   क्रेडेंशियल्स (डेटाबेस, FTP, SSH, API कुंजी) को घुमाएं। विश्वसनीय स्रोतों से WordPress कोर, थीम और प्लगइन्स को फिर से स्थापित करें। यदि आवश्यक हो तो एक साफ़ बैकअप से पुनर्स्थापित करें।.

6. घटना के बाद

   एक पूर्ण सुरक्षा ऑडिट करें: फ़ाइल अनुमतियाँ, स्थापित घटक, और सर्वर कॉन्फ़िगरेशन। WAF नियमों और निगरानी को मजबूत करें। आवश्यकतानुसार हितधारकों को सूचित करें।.

7. रिपोर्ट

   यदि ग्राहक डेटा उजागर हुआ है, तो लागू कानूनी और प्रकटीकरण आवश्यकताओं का पालन करें।.

हार्डनिंग और दीर्घकालिक शमन

इस और समान कमजोरियों से जोखिम को कम करने के लिए, इन सर्वोत्तम प्रथाओं को लागू करें:

• थीम, प्लगइन्स, और WordPress कोर को अपडेट रखें और एक आपातकालीन पैचिंग योजना बनाए रखें।.
• स्थापित घटकों को न्यूनतम करें: अप्रयुक्त थीम/प्लगइन्स को हटा दें।.
• जब आधिकारिक पैच उपलब्ध न हो, तो अस्थायी रूप से वर्चुअल पैचिंग का उपयोग करें, लेकिन इसे एक अस्थायी उपाय के रूप में मानें।.
• PHP निष्पादन को निष्क्रिय करें /wp-content/uploads, कैश निर्देशिकाएँ, और समान लिखने योग्य स्थानों का सर्वर कॉन्फ़िगरेशन का उपयोग करके।.
• डेटाबेस उपयोगकर्ताओं के लिए न्यूनतम विशेषाधिकार का उपयोग करें; केवल आवश्यक अनुमतियाँ दें।.
• अप्रत्याशित परिवर्तनों का पता लगाने के लिए फ़ाइल अखंडता निगरानी लागू करें।.
• नियमित, परीक्षण किए गए बैकअप को ऑफ-साइट या ऑफ़लाइन संग्रहीत करें।.
• कमजोर निर्भरताओं के लिए कोडबेस और तृतीय-पक्ष घटकों (सॉफ़्टवेयर संरचना विश्लेषण) को स्कैन करें।.
• समय-समय पर सुरक्षा समीक्षाएँ और पेनिट्रेशन परीक्षण करें।.

वर्चुअल पैचिंग / प्रबंधित सुरक्षा कैसे मदद करती है (व्यावहारिक व्याख्या)

जब एक कमजोरियों का खुलासा किया जाता है और कोई विक्रेता पैच उपलब्ध नहीं होता है, तो परिधि पर आभासी पैचिंग (WAF) जोखिम को कम कर सकती है:

• ज्ञात हमले के पैटर्न को कमजोर कोड तक पहुँचने से पहले रोकना और अवरुद्ध करना।.
• जब नए शोषण पैटर्न देखे जाते हैं तो जल्दी अपडेट होना।.
• गलत सकारात्मकता को कम करने के लिए लक्षित अवरोध की अनुमति देना (उदाहरण के लिए, केवल ट्रैवर्सल या रैपर उपयोग को अवरुद्ध करना)।.
• एक स्थायी समाधान की योजना बनाने और लागू करने के दौरान तत्काल, अस्थायी सुरक्षा प्रदान करना।.

आभासी पैचिंग एक शमन है, विक्रेता द्वारा प्रदान किए गए पैच का प्रतिस्थापन नहीं। जब एक सुरक्षित विक्रेता पैच उपलब्ध हो, तो स्थायी सुधार की योजना बनाएं।.

व्यावहारिक उदाहरण: लॉग में क्या देखना है (नमूने)

GET /?file=../../../../wp-config.php HTTP/1.1

यदि आप ऐसे प्रविष्टियाँ पाते हैं, तो IP को अवरुद्ध करें, लॉग को संरक्षित करें, और तुरंत जांच करें।.

यदि साइट में सेंध लग गई है - सुधार प्राथमिकताएँ

1. उजागर क्रेडेंशियल्स को रद्द करें (DB पासवर्ड, API कुंजी बदलें)।.
2. प्रशासकों और विशेषाधिकार प्राप्त खातों के लिए पासवर्ड रीसेट करने के लिए मजबूर करें।.
3. ज्ञात-साफ स्रोतों से WordPress कोर, थीम और प्लगइन्स को फिर से स्थापित करें।.
4. समझौता किए गए फ़ाइलों को ज्ञात-स्वच्छ संस्करणों से बदलें।.
5. बैकडोर की खोज करें और उन्हें हटा दें; हाल ही में संशोधित फ़ाइलों की सावधानीपूर्वक जांच करें।.
6. कॉन्फ़िगरेशन को मजबूत करें और पुनः शोषण को रोकने के लिए WAF नियम लागू करें।.

एजेंसियों और होस्ट के लिए संचार मार्गदर्शन

यदि आप कई ग्राहक साइटों का प्रबंधन करते हैं या WordPress उदाहरणों की मेज़बानी करते हैं:

• प्रभावित थीम (≤ 1.4) का उपयोग करने वाली साइटों की जल्दी पहचान करें।.
• बाहरी-फेसिंग व्यावसायिक साइटों और संवेदनशील डेटा को संभालने वाली साइटों को प्राथमिकता दें।.
• प्रति-साइट ओवरहेड को कम करने के लिए नेटवर्क या परिधि पर आभासी पैचिंग को संभवतः लागू करें।.
• ग्राहकों के साथ स्पष्ट रूप से संवाद करें: बताएं कि आपने क्या बदला, क्यों, और अगले कदमों में बैकअप और क्रेडेंशियल रोटेशन शामिल हैं।.

प्रॉएक्टिव सुरक्षा क्यों महत्वपूर्ण है

व्यापक रूप से वितरित थीम में LFI दोष हमलावरों के लिए आकर्षक होते हैं क्योंकि शोषण को स्वचालित और स्केल किया जा सकता है। विक्रेता पैच की प्रतीक्षा करने से डेटा हानि और सेवा बाधित होने का जोखिम बढ़ जाता है। प्रॉएक्टिव उपाय - वर्चुअल पैचिंग, निरंतर निगरानी, नियमित अपडेट और घटना योजना - जोखिम और पुनर्प्राप्ति समय दोनों को महत्वपूर्ण रूप से कम करते हैं।.

अक्सर पूछे जाने वाले प्रश्न (FAQ)

प्रश्न: मेरी थीम एक पैच किए गए संस्करण में अपडेट की गई है - क्या मुझे अभी भी परिधीय सुरक्षा की आवश्यकता है?

उत्तर: हाँ। एक परिधीय WAF गहराई में रक्षा प्रदान करता है और आपको अपडेट का परीक्षण और तैनात करते समय शोषण के प्रयासों को रोक सकता है। यह अन्य कमजोरियों के खिलाफ भी सुरक्षा में मदद करता है जिन्हें आपने अभी तक पैच नहीं किया हो सकता है।.

प्रश्न: क्या WAF नियम वैध कार्यक्षमता को तोड़ देंगे?

उत्तर: अच्छी तरह से तैयार किए गए नियम झूठे सकारात्मक को न्यूनतम करते हैं। पहले पहचान मोड में परीक्षण करें, फिर नियम सेट को मान्य करने के बाद ब्लॉकिंग पर स्विच करें। जहां संभव हो, वैध फ़ाइल-चयन पैरामीटर के लिए व्हाइटलिस्टिंग का उपयोग करें।.

प्रश्न: मैंने लॉग में संदिग्ध अनुरोध पाए - मुझे पहले क्या करना चाहिए?

उत्तर: परिधीय पर आपत्तिजनक IP(s) को ब्लॉक करें, लॉग को संरक्षित करें, एक बैकअप लें, और ऊपर दिए गए घटना प्रतिक्रिया चेकलिस्ट का पालन करें।.

अंतिम अनुशंसाएँ

• यदि आप प्रभावित थीम का उपयोग करते हैं तो CVE-2026-22478 (FindAll थीम ≤ 1.4 LFI) को तत्काल खतरे के रूप में मानें।.
• यदि संभव हो, तो तुरंत थीम को निष्क्रिय या बदलें; अन्यथा WAF/वर्चुअल पैचिंग लागू करें और फ़ाइल अनुमतियों को मजबूत करें।.
• लॉग की निगरानी करें और समझौते के संकेतों के लिए स्कैन करें; यदि आप खुलासा का संदेह करते हैं तो क्रेडेंशियल्स को घुमाएं।.
• भविष्य के खुलासों के लिए पुनर्प्राप्ति को तेज करने के लिए बैकअप और एक परीक्षण किया हुआ घटना प्रतिक्रिया योजना बनाए रखें।.
• यदि आपको मदद की आवश्यकता है, तो containment, फोरेंसिक विश्लेषण और पुनर्प्राप्ति में सहायता के लिए विश्वसनीय सुरक्षा पेशेवरों या घटना प्रतिक्रिया प्रदाता से संपर्क करें।.