| प्लगइन का नाम | 1. मीडिया में कस्टम फ़ील्ड जोड़ें |
|---|---|
| कमजोरियों का प्रकार | CSRF |
| CVE संख्या | 2. CVE-2026-4068 |
| तात्कालिकता | कम |
| CVE प्रकाशन तिथि | 2026-03-19 |
| स्रोत URL | 2. CVE-2026-4068 |
CVE-2026-4068: CSRF in “Add Custom Fields to Media” – What WordPress Site Owners Must Do Now
तारीख: 4. 2026-03-19 · लेखक: हांगकांग सुरक्षा विशेषज्ञ · श्रेणियाँ: 5. वर्डप्रेस सुरक्षा, कमजोरियों की सलाह
सारांश: A Cross-Site Request Forgery (CSRF) vulnerability (CVE-2026-4068) affecting the “Add Custom Fields to Media” plugin (7. “मीडिया में कस्टम फ़ील्ड जोड़ें” प्लगइन (≤ 2.0.3) में एक CSRF दोष है जो तैयार अनुरोधों के माध्यम से कस्टम फ़ील्ड को हटाने की अनुमति देता है (CVE-2026-4068)। तुरंत 2.0.4 में अपडेट करें। यदि आप अपडेट नहीं कर सकते हैं, तो प्लगइन को अक्षम करें या आभासी पैच लागू करें (WAF नियम या अस्थायी mu-plugin) और नीचे दिए गए पहचान और पुनर्प्राप्ति चरणों का पालन करें।.
TL;DR: The “Add Custom Fields to Media” plugin (≤ 2.0.3) has a CSRF flaw allowing deletion of custom fields via crafted requests (CVE-2026-4068). Update to 2.0.4 immediately. If you cannot update, disable the plugin or apply virtual patches (WAF rules or a temporary mu-plugin) and follow detection & recovery steps below.
अवलोकन
On 19 March 2026 a CSRF vulnerability affecting the WordPress plugin “Add Custom Fields to Media” (versions ≤ 2.0.3) was published and assigned CVE‑2026‑4068. In short: a missing or insufficient nonce/CSRF protection on the deletion path allows an attacker to trick an authenticated privileged user (for example an administrator) into executing a request that deletes custom fields from media items.
10. यह सलाह एक तकनीकी व्याख्या, पहचान के चरण, तात्कालिक शमन, उदाहरण आभासी पैच/WAF नियम और वर्डप्रेस साइट मालिकों और ऑपरेटरों के लिए लक्षित घटना के बाद की पुनर्प्राप्ति क्रियाएँ प्रदान करती है।.
11. प्लगइन लेखक ने संस्करण 2.0.4 में इस मुद्दे को ठीक किया - प्राथमिक सुधार के रूप में उस अपडेट को लागू करें।.
नोट: 12. प्लगइन के हटाने के प्रवाह में एक क्रॉस-साइट अनुरोध धोखाधड़ी (CSRF) दोष है।.
भेद्यता वास्तव में क्या है?
- 13. एक अनुरोध (GET या POST) में पैरामीटर और वर्डप्रेस nonce या अन्य CSRF टोकन की पुष्टि किए बिना कस्टम फ़ील्ड का हटाना करता है।.
- प्लगइन एक स्वीकार करता है
हटाएँ14. एक हमलावर एक URL या फ़ॉर्म तैयार कर सकता है जो, जब एक प्रमाणित विशेषाधिकार प्राप्त उपयोगकर्ता द्वारा देखा/सबमिट किया जाता है, लक्षित कस्टम फ़ील्ड को हटाने का कारण बनता है।. - 15. क्योंकि यह क्रिया संग्रहीत डेटा (अटैचमेंट पोस्टमेटा) को परिवर्तित करती है, यह उन फ़ील्ड पर निर्भर करने वाली गैलरी, मेटाडेटा और अन्य साइट सुविधाओं को तोड़ सकती है।.
- 16. कस्टम फ़ील्ड का हटाना फ्रंटेंड कार्यक्षमता को बाधित कर सकता है, उच्च-मूल्य मेटाडेटा या साइट कॉन्फ़िगरेशन को हटा सकता है, और बहु-चरण हमलों में अन्य कमजोरियों के साथ मिलाया जा सकता है।.
यह क्यों महत्वपूर्ण है: 17. CVE‑2026‑4068 ·.
CVE: 18. ≤ 2.0.3 · प्रभावित संस्करण: 19. शोषणीयता और खतरे का मॉडल पैच किया गया: 2.0.4
Exploitability & Threat Model
शोषण की पूर्वापेक्षाएँ:
- हमलावर को प्रशासनिक क्रेडेंशियल की आवश्यकता नहीं है, लेकिन एक प्रमाणित विशेषाधिकार प्राप्त उपयोगकर्ता को एक तैयार पृष्ठ पर जाने या एक लिंक पर क्लिक करने की आवश्यकता है (क्लासिक CSRF)।.
- यह सबसे प्रभावी है जब प्रशासक वेब ब्राउज़ करते समय wp-admin में लॉग इन होते हैं।.
Why severity is “low” but still important:
- उच्च विशेषाधिकार खाते द्वारा उपयोगकर्ता इंटरैक्शन की आवश्यकता होती है (स्वचालित अंधे शोषण को कम करता है)।.
- प्रभाव लक्षित कस्टम फ़ील्ड का हटाना है—विनाशकारी लेकिन जरूरी नहीं कि पूरी साइट पर कब्जा।.
- हमलावरों के लिए एक विघटन वेक्टर या श्रृंखलाबद्ध हमलों के हिस्से के रूप में अभी भी उपयोगी है।.
सामान्य दुरुपयोग परिदृश्य: फ़िशिंग पृष्ठ, दुर्भावनापूर्ण पोस्ट या टिप्पणियाँ जिनमें तैयार लिंक या टैग होते हैं जो प्रशासक के लॉग इन होने पर प्रशासनिक अनुरोधों को ट्रिगर करते हैं।.
कैसे जांचें कि आपकी साइट कमजोर है
- प्लगइन संस्करण
Login to WP Admin → Plugins and confirm the exact version of “Add Custom Fields to Media”. If it is 2.0.4 or later, you are patched. If ≤ 2.0.3, treat the site as vulnerable and take immediate action.
- संदिग्ध गतिविधि के लिए सर्वर लॉग की जांच करें
अनुरोधों के लिए वेब सर्वर एक्सेस लॉग की खोज करें जिसमें एक
हटाएँपैरामीटर है जो प्रशासनिक एंडपॉइंट्स को हिट करता है जैसेadmin-ajax.php,admin-post.phpया प्लगइन प्रशासनिक पृष्ठ।.grep -i "delete=" /var/log/nginx/access.logबाहरी डोमेन से उत्पन्न संदर्भ और अनुरोधों की भी जांच करें।.
- डेटाबेस ऑडिट: खोए हुए या परिवर्तित पोस्टमेटा की पुष्टि करें
गायब कस्टम फ़ील्ड का पता लगाने के लिए अटैचमेंट पोस्टमेटा का निरीक्षण करें। उदाहरण SQL:
-- अटैचमेंट की सूची बनाएं और कस्टम फ़ील्ड की गणना करें;यदि आप जानते हैं कि प्लगइन कौन सा विशेष मेटा_की का उपयोग करता है, तो उसकी अनुपस्थिति के लिए खोजें:
SELECT * FROM wp_postmeta WHERE meta_key = 'your_custom_meta_key' LIMIT 10; - प्रशासन क्रिया इतिहास की समीक्षा करें
यदि आपके पास एक ऑडिट/लॉगिंग प्लगइन है, तो उपयोगकर्ता गतिविधि से मेल न खाने वाले हटाने की घटनाओं की जांच करें।.
- मैलवेयर स्कैन
अज्ञात फ़ाइलों या इंजेक्टेड कोड के लिए पूर्ण साइट मैलवेयर स्कैन और अखंडता जांच चलाएँ—मेटा का हटाना अन्य दुर्भावनापूर्ण गतिविधियों के साथ हो सकता है।.
तात्कालिक कदम (0–24 घंटे)
यदि आपकी साइट में कमजोर प्लगइन है और आप तुरंत अपडेट नहीं कर सकते हैं, तो जोखिम को कम करने के लिए अब निम्नलिखित करें।.
- प्लगइन को 2.0.4 (सिफारिश की गई) पर अपडेट करें
यह सही और अंतिम समाधान है—जितनी जल्दी हो सके लागू करें।.
- यदि आप अपडेट नहीं कर सकते हैं, तो अस्थायी रूप से प्लगइन को निष्क्रिय करें
निष्क्रियता कमजोर कोड पथ को पहुँचने से रोकती है। पैचिंग और सत्यापन के बाद ही पुनः सक्रिय करें।.
- WAF या ब्लॉकिंग नियमों के माध्यम से आभासी पैचिंग लागू करें
अनुरोधों को अवरुद्ध करने के लिए नियम जोड़ें जिसमें
हटाएँप्रशासन अंत बिंदुओं और प्लगइन पथों के लिए पैरामीटर शामिल हैं। नीचे WAF उदाहरण देखें।. - wp-admin तक पहुँच सीमित करें
जहाँ संभव हो, IP द्वारा पहुँच को प्रतिबंधित करें, या
/wp-admin/. HTTP प्रमाणीकरण का उपयोग करें।. - प्रशासकों को सूचित करें
प्रशासनिक उपयोगकर्ताओं को अनजान लिंक पर क्लिक करने से बचने, लॉग आउट और फिर से लॉग इन करने, और दो-कारक प्रमाणीकरण सक्षम करने के लिए सूचित करें।.
- तुरंत बैकअप लें।
परिवर्तन करने से पहले पूर्ण बैकअप (फाइलें + डेटाबेस) लें ताकि आवश्यकता पड़ने पर आप पुनर्प्राप्त कर सकें।.
अनुशंसित स्थायी समाधान
- संस्करण 2.0.4 या नए में अपडेट करें
प्लगइन लेखक ने आवश्यक CSRF सुरक्षा के साथ 2.0.4 जारी किया—यह मानक समाधान है।.
- कोड में वर्डप्रेस नॉनसेस को लागू करें
1. सभी राज्य-परिवर्तन क्रियाएँ नॉनस का उपयोग करना चाहिए (
wp_create_nonce+चेक_एडमिन_रेफरर/wp_verify_nonce). - 2. सुरक्षित विकास प्रथाओं का पालन करें
3. म्यूटेशन के लिए POST का उपयोग करें, इनपुट को साफ करें और मान्य करें, और सुरक्षा रिलीज प्रक्रियाओं का दस्तावेज़ीकरण करें।.
4. वर्चुअल पैचिंग / WAF नियम जिन्हें आप अभी लागू कर सकते हैं
5. नीचे उन रूढ़िवादी नियमों की सूची है जिन्हें आप अपने WAF, mod_security या NGINX कॉन्फ़िगरेशन में जोड़ सकते हैं ताकि आप अपडेट करते समय शोषण को कम कर सकें। पहले स्टेजिंग पर परीक्षण करें।.
6. सामान्य सिद्धांत
उन अनुरोधों को ब्लॉक करें जहाँ:
- A
हटाएँ7. पैरामीटर क्वेरी या POST बॉडी में मौजूद है और अनुरोध व्यवस्थापक एंडपॉइंट्स या प्लगइन व्यवस्थापक पथों को लक्षित करता है।. - 8. अनुरोध GET है (GET में राज्य परिवर्तन संदिग्ध है) या अन्यथा अपेक्षित नॉनस टोकन की कमी है।.
9. उदाहरण mod_security नियम (Apache / mod_security v2/v3)
10. # GET अनुरोधों को ब्लॉक करें जिनमें "delete" पैरामीटर है जो व्यवस्थापक एंडपॉइंट्स को लक्षित करता है"SecRule REQUEST_METHOD "GET" "phase:2,deny,log,status:403,id:1005001,msg:'CSRF हटाने के प्रयास को ब्लॉक करें: GET के साथ delete पैरामीटर व्यवस्थापक एंडपॉइंट्स के लिए'" हटाएँ SecRule ARGS_NAMES "delete" "chain".
SecRule REQUEST_URI "@pm /wp-admin/ /admin-ajax.php /admin-post.php /wp-content/plugins/"
11. नोट: एक तर्क नाम के साथ GET अनुरोधों को अस्वीकार करें12. जो सामान्य व्यवस्थापक या प्लगइन एंडपॉइंट्स को लक्षित करते हैं। पहले पहचान मोड में परीक्षण करें। यदि 13. उदाहरण NGINX स्निपेट हटाएँ 14. # GET अनुरोधों को ब्लॉक करें जिनमें "delete" तर्क है जो व्यवस्थापक एंडपॉइंट्स को हिट करता है.
location ~* /wp-admin/ {
IF request.uri contains “/wp-admin” OR “admin-ajax.php” OR “admin-post.php” OR plugin-slug AND request.args contains parameter name “delete” AND request.method IN {GET, POST} THEN block with 403.
if ($arg_delete) {
यदि आप तुरंत WAF नियमों को अपडेट या लागू नहीं कर सकते हैं, तो एक अनिवार्य प्लगइन लागू करें जो GET-आधारित हटाने के प्रयासों को ब्लॉक करता है। यह केवल एक अस्थायी उपाय है - अपडेट करने के बाद हटा दें।.
फ़ाइल बनाएँ: wp-content/mu-plugins/temporary-csrf-block.php
नोट्स: यह प्रशासनिक सत्रों के लिए साइट-व्यापी GET हटाने के प्रयासों को रोकता है। यह एक कुंद उपकरण है और वैध दुर्लभ कार्यप्रवाहों को ब्लॉक कर सकता है। 2.0.4 में अपडेट करने के बाद हटा दें।.
पहचान: संकेत कि आप लक्षित या शोषित हुए थे
- एक्सेस लॉग में अनुरोध दिखाते हैं
हटाएँ=बाहरी संदर्भों के साथ प्रशासनिक अंत बिंदुओं पर।. - प्रशासनिक उपयोगकर्ता रिपोर्ट करते हैं कि उन्होंने लिंक पर क्लिक किया या पृष्ठ खोले जो उन्होंने जानबूझकर नहीं खोले।.
- मीडिया अटैचमेंट के लिए कस्टम फ़ील्ड गायब हैं जो पहले मौजूद थे।.
- टूटे हुए गैलरी या गायब मीडिया मेटाडेटा।.
- ऑडिट लॉग में प्रशासनिक पुष्टि के बिना हटाने या अपडेट घटनाएँ दिखा रहे हैं।.
- अप्रत्याशित अनुरोध
admin-ajax.phpअपरिचित के साथक्रियापैरामीटर।.
यदि आप अनचाहे हटाने के सबूत पाते हैं, तो साइट को समझौता किया गया मानें: इसे ऑफलाइन लें (रखरखाव मोड), लॉग और बैकअप को सुरक्षित करें, और फोरेंसिक समीक्षा करें।.
पुनर्प्राप्ति और घटना के बाद के कार्य
- बैकअप से हटाए गए मेटा को पुनर्स्थापित करें
हटाए गए मेटा पंक्तियों को पुनर्स्थापित करने के लिए डेटाबेस बैकअप का उपयोग करें। यदि संभव हो, तो नए सामग्री को ओवरराइट करने से बचने के लिए केवल प्रभावित मेटाडेटा को पुनर्स्थापित करें।.
- क्रेडेंशियल्स को घुमाएं
प्रशासनिक पासवर्ड और किसी भी API कुंजी को पुनः सेट करें जो पोस्ट/मेटा में संग्रहीत हैं। जहां समर्थित हो, सत्रों को अमान्य करें।.
- प्रशासनिक खातों को मजबूत करें
प्रशासनिक उपयोगकर्ताओं के लिए दो-कारक प्रमाणीकरण की आवश्यकता करें, अप्रयुक्त प्रशासनिक खातों को हटा दें और न्यूनतम विशेषाधिकार लागू करें।.
- प्लगइन्स और थीम की समीक्षा करें।
अप्रयुक्त या परित्यक्त प्लगइनों को हटा दें और तीसरे पक्ष के कोड को प्रतिष्ठित स्रोतों से अपडेट रखें।.
- ऑडिट लॉग और घटना रिपोर्ट
रिकॉर्ड टाइमस्टैम्प, आईपी और की गई क्रियाएँ। यदि समझौता किया गया है, तो पेशेवर घटना प्रतिक्रिया पर विचार करें।.
- फॉलो-ऑन गतिविधियों की निगरानी करें
सुधार के बाद, लॉग की निगरानी करें ताकि पुनरावृत्त प्रयासों का पता लगाया जा सके, फ़ाइल अखंडता निगरानी सक्षम करें और स्थायीता/बैकडोर के लिए स्कैन करें।.
वर्डप्रेस के लिए वर्चुअल पैचिंग का महत्व
वर्डप्रेस साइटें कोर, प्लगइन्स और थीम को मिलाती हैं। यहां तक कि अच्छी तरह से बनाए रखी गई साइटें एकल कमजोर प्लगइन द्वारा उजागर हो सकती हैं। जबकि अपडेट सही समाधान हैं, पैचिंग संगतता परीक्षण या चरणबद्ध रोलआउट के लिए विलंबित हो सकती है। एक WAF के साथ वर्चुअल पैचिंग विशेष CVEs के लिए शोषण प्रयासों को रोकने में मदद करती है जब तक कि अपडेट लागू नहीं होते, स्वचालित शोर को कम करती है और सावधानीपूर्वक अपडेट प्रक्रियाओं के लिए समय खरीदती है।.
साइट मालिकों के लिए व्यावहारिक चेकलिस्ट (चरण-दर-चरण)
- प्लगइन संस्करण की जांच करें।.
- यदि कमजोर है, तो यदि संभव हो तो अब 2.0.4 में अपडेट करें।.
- यदि आप तुरंत अपडेट नहीं कर सकते: प्लगइन को निष्क्रिय करें या mu-प्लगइन लागू करें या ऊपर वर्णित WAF नियम लागू करें।.
- फ़ाइलों और डेटाबेस का बैकअप लें।.
- व्यवस्थापक सत्र रीसेट करें और पासवर्ड बदलें।.
- साइट को मैलवेयर स्कैनर के साथ स्कैन करें और लॉग की समीक्षा करें।.
- यदि आवश्यक हो तो बैकअप से हटाए गए मेटाडेटा को पुनर्स्थापित करें।.
- केवल पैचिंग और सत्यापन के बाद प्लगइन को फिर से सक्षम करें।.
हम इस कमजोरियों के लिए जोखिम का आकलन कैसे करते हैं
जोखिम आकलन तीन ध्रुवों पर विचार करता है:
- शोषणीयता: प्रमाणीकरण और उपयोगकर्ता इंटरैक्शन की आवश्यकता होती है; CSRF स्वचालित शोषण को कम करता है लेकिन सामाजिक इंजीनियरिंग के माध्यम से व्यावहारिक है।.
- प्रभाव: डेटा का विलोपन या भ्रष्टाचार—इस मामले में साइट की अखंडता के लिए मध्यम प्रभाव।.
- प्रचलन: प्लगइन इंस्टॉल आधार अवसरवादी लक्ष्यों को बढ़ाता है।.
मिलाकर, ये कारक त्वरित सुधार को उचित ठहराते हैं: अब अपडेट करें और यदि तत्काल अपडेट संभव नहीं है तो वर्चुअल शमन लागू करें।.
उदाहरण घटना परिदृश्य
एक हमलावर एक पृष्ठ होस्ट करता है जिसमें एक /wp-admin/?delete=meta_keyname&id=123. एक व्यवस्थापक जो wp-admin में लॉग इन है, पृष्ठ पर जाता है; ब्राउज़र प्रमाणित अनुरोध भेजता है और कमजोर प्लगइन मेटा पंक्ति को हटा देता है। दृश्य परिणाम: एक टूटी हुई गैलरी या गायब मेटाडेटा। हमलावर इसे व्यवस्थापकों को सामूहिक ईमेल के माध्यम से बढ़ा सकते हैं।.
शमन: प्लगइन को अपडेट करें, किनारे पर स्थिति-परिवर्तन GET को अवरुद्ध करें (WAF), 2FA सक्षम करें और व्यवस्थापक पहुंच को सीमित करें।.
एजेंसियों और होस्ट के लिए संचालन संबंधी सलाह
- प्रबंधित साइटों में प्लगइन संस्करणों का इन्वेंटरी करें।.
- उन उदाहरणों को अपडेट करने को प्राथमिकता दें जो ≤ 2.0.3 चला रहे हैं।.
- अपडेट रोल आउट होने तक प्रबंधित साइटों में लक्षित WAF सिग्नेचर लागू करें।.
- स्पष्ट सुधार समयसीमा के साथ ग्राहकों को सूचित करें।.
- यदि आप प्रबंधित होस्टिंग प्रदान करते हैं, तो सामूहिक शोषण को रोकने के लिए बेड़े में एक आपातकालीन आभासी पैच पर विचार करें।.
वर्डप्रेस प्लगइन डेवलपर्स के लिए सीख
- कभी भी GET अनुरोधों के माध्यम से विनाशकारी संचालन न करें।.
- हमेशा व्यवस्थापक क्रियाओं के लिए वर्डप्रेस नॉन्स का उपयोग करें और उन्हें सर्वर-साइड पर सत्यापित करें।.
- डेटाबेस को हटाने या लिखने से पहले इनपुट को साफ और मान्य करें।.
- एक तेज, पारदर्शी सुरक्षा पैचिंग प्रक्रिया और स्पष्ट अपग्रेड मार्गदर्शन बनाए रखें।.
अतिरिक्त रक्षात्मक नियंत्रण
- प्रशासनिक खातों के लिए दो-कारक प्रमाणीकरण लागू करें।.
- प्रशासनिक कार्यों के लिए भूमिका विभाजन और न्यूनतम विशेषाधिकार का उपयोग करें।.
- समवर्ती सत्रों को सीमित करें और जहां संभव हो, सत्र की अवधि को छोटा करें।.
- क्रॉस-साइट सामग्री के संपर्क को कम करने के लिए सामग्री सुरक्षा नीति (CSP) और ब्राउज़र नियंत्रणों का उपयोग करें।.
- कस्टम थीम और प्लगइन्स के लिए आवधिक सुरक्षा ऑडिट और कोड समीक्षाएँ निर्धारित करें।.
अंतिम शब्द — आपको अभी क्या करना चाहिए
- प्लगइन संस्करण की जांच करें; यदि ≤ 2.0.3 है, तो तुरंत 2.0.4 में अपडेट करें।.
- यदि आप अपडेट नहीं कर सकते हैं, तो प्लगइन को अक्षम करें या ऊपर वर्णित अस्थायी mu-plugins और/या WAF नियम लागू करें।.
- साइट का बैकअप लें और ऑडिट लॉग्स।.
- व्यवस्थापक पहुंच को मजबूत करें और 2FA सक्षम करें।.
- यदि आप कई साइटों का प्रबंधन करते हैं, तो अपनी पूरी फ्लीट में वर्चुअल पैचिंग लागू करें जब तक कि सभी उदाहरण पैच न हो जाएं।.
यह CSRF घटना एक पुनरावृत्त विषय को उजागर करती है: छोटे चूक (गायब नॉन्स जांच) विनाशकारी परिणामों का कारण बन सकते हैं। समय पर अपडेट और परतदार रक्षा—एज फ़िल्टरिंग, पहुँच नियंत्रण और निगरानी—जोखिम को प्रभावी ढंग से कम करते हैं।.
यदि आपको WAF नियम लागू करने, बैकअप से मेटाडेटा पुनर्स्थापित करने, या घटना समीक्षा करने में सहायता की आवश्यकता है, तो एक विश्वसनीय सुरक्षा भागीदार या अनुभवी घटना प्रतिक्रिया प्रदाता से संपर्क करें।.
