तत्काल: ऑटो पोस्ट शेड्यूलर <= 1.84 — CSRF → स्टोर्ड XSS (CVE‑2026‑1877) — वर्डप्रेस साइट के मालिकों को अब क्या करना चाहिए

एक मध्यम-गंभीर सुरक्षा दोष (CVE‑2026‑1877, CVSS 7.1) ऑटो पोस्ट शेड्यूलर वर्डप्रेस प्लगइन (संस्करण ≤ 1.84) को प्रभावित करता है। यह दोष क्रॉस-साइट अनुरोध धोखाधड़ी (CSRF) की अनुमति देता है जो प्लगइन के विकल्प प्रबंधन (aps_options_page) के भीतर स्टोर किए गए क्रॉस-साइट स्क्रिप्टिंग (XSS) का परिणाम बनता है। संक्षेप में: एक हमलावर प्लगइन विकल्पों में जावास्क्रिप्ट लिखवा सकता है और बाद में इसे प्रशासनिक संदर्भ में या जहां भी उन विकल्पों को प्रस्तुत किया जाता है, निष्पादित कर सकता है। यदि प्रशासकों को लक्षित किया जाता है तो वह निष्पादन साइट के समझौते का कारण बन सकता है।.

यह सलाह—हांगकांग में सुरक्षा विशेषज्ञों द्वारा तैयार की गई—समस्या, व्यावहारिक दुरुपयोग परिदृश्यों, समझौते का पता लगाने के तरीके, और आधिकारिक प्लगइन पैच की प्रतीक्षा करते समय आप लागू कर सकते हैं तत्काल शमन कदमों को समझाती है।.

कार्यकारी सारांश (TL;DR)

• प्रभावित सॉफ़्टवेयर: ऑटो पोस्ट शेड्यूलर प्लगइन (वर्डप्रेस) — संस्करण ≤ 1.84।.
• सुरक्षा दोष का प्रकार: CSRF जो प्लगइन विकल्प पृष्ठ (aps_options_page) के माध्यम से स्टोर किए गए XSS को सक्षम करता है।.
• CVE: CVE‑2026‑1877
• गंभीरता: मध्यम (CVSS 7.1)
• शोषण क्षमता: एक विशेषाधिकार प्राप्त, लॉगिन किए हुए उपयोगकर्ता (आमतौर पर एक प्रशासक) को धोखा देने की आवश्यकता होती है। एक हमलावर बाहरी रूप से शोषण पृष्ठ होस्ट कर सकता है; पीड़ित को प्रमाणित होना चाहिए और हमले के पृष्ठ पर जाना चाहिए।.
• जोखिम: प्रशासनिक संदर्भ में स्टोर किया गया XSS पूर्ण साइट अधिग्रहण का कारण बन सकता है — प्रशासनिक खाते बनाना, बैकडोर स्थापित करना, डेटा निकालना।.
• तत्काल कार्रवाई: यदि संभव हो तो प्लगइन को निष्क्रिय करें। यदि नहीं, तो लक्षित WAF नियम लागू करें, प्रशासनिक क्रेडेंशियल्स को घुमाएं, और इंजेक्टेड स्क्रिप्ट के लिए स्कैन करें।.

भेद्यता वास्तव में क्या है?

प्लगइन एक विकल्प हैंडलर (aps_options_page) को उजागर करता है जो POST किए गए विकल्प मानों को स्वीकार करता है जो पर्याप्त CSRF सत्यापन के बिना और प्रस्तुत करते समय आउटपुट को साफ़ या एस्केप किए बिना संग्रहीत होते हैं। विशेष रूप से:

• स्थिति-परिवर्तन अनुरोध पर कोई उचित नॉनस या अनुपस्थित क्षमता जांच लागू नहीं की जाती है।.
• विकल्पों में संग्रहीत इनपुट बाद में सुरक्षित एस्केपिंग के बिना प्रस्तुत किया जाता है, जो स्थायी XSS को सक्षम करता है।.
• क्योंकि निष्पादन प्रशासनिक पृष्ठों में हो सकता है, हमलावर उच्च-विशेषाधिकार जावास्क्रिप्ट निष्पादन प्राप्त करता है।.

यह एक CSRF → स्टोर किया गया XSS श्रृंखला बनाता है: एक हमलावर एक अनुरोध बनाता है जो विकल्पों में दुर्भावनापूर्ण सामग्री लिखता है; बाद में उन विकल्पों का दृश्यन लोड करता है।.

हमले का प्रवाह (कैसे एक हमलावर इसका दुरुपयोग करता है)

1. हमलावर एक वेबपृष्ठ होस्ट करता है जो लक्षित वर्डप्रेस साइट के aps_options_page पर जावास्क्रिप्ट पेलोड वाले फ़ील्ड के साथ POST जारी करता है।.
2. हमलावर एक प्रशासक (या अन्य विशेषाधिकार प्राप्त उपयोगकर्ता) को लॉगिन करते समय दुर्भावनापूर्ण पृष्ठ पर जाने के लिए धोखा देता है।.
3. प्रशासक का ब्राउज़र सक्रिय कुकीज़ का उपयोग करके स्वचालित रूप से POST सबमिट करता है; प्लगइन दुर्भावनापूर्ण इनपुट को संग्रहीत करता है।.
4. जब एक व्यवस्थापक बाद में प्लगइन सेटिंग्स (या कहीं और विकल्प प्रस्तुत किया गया है) को देखता है, तो संग्रहीत स्क्रिप्ट उस व्यवस्थापक के ब्राउज़र में निष्पादित होती है।.
5. स्क्रिप्ट विशेषाधिकार प्राप्त क्रियाएँ करती है (उपयोगकर्ता बनाना, प्लगइन स्थापित करना, फ़ाइलें संशोधित करना) या डेटा को बाहर निकालती है।.

नोट: हमलावर को दुर्भावनापूर्ण पृष्ठ को होस्ट या भेजने के लिए प्रमाणित होने की आवश्यकता नहीं है - केवल पीड़ित को पर्याप्त विशेषाधिकार के साथ लॉग इन होना चाहिए।.

वास्तविक प्रभाव परिदृश्य

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

व्यवस्थापक पृष्ठों के अंदर संग्रहीत XSS उच्च प्रभाव डालता है क्योंकि यह प्रभावी रूप से हमलावर को ब्राउज़र के माध्यम से व्यवस्थापक की क्षमताएँ सौंपता है।.

कैसे जांचें कि आपकी साइट कमजोर है या पहले से ही समझौता की गई है

1. प्लगइन संस्करण जांचें:
   • व्यवस्थापक UI: प्लगइन्स → स्थापित प्लगइन्स → ऑटो पोस्ट शेड्यूलर। यदि संस्करण ≤ 1.84 है, तो इसे संवेदनशील मानें।.
   • WP‑CLI: wp प्लगइन प्राप्त करें auto-post-scheduler --field=version
2. संग्रहीत विकल्पों का निरीक्षण करें:
   • देखें 11. संदिग्ध सामग्री के साथ। तालिका में विकल्प नामों के लिए जिसमें “aps”, “auto_post_scheduler”, आदि शामिल हैं।.
   • उदाहरण क्वेरी:

     SELECT option_name, option_value FROM wp_options WHERE option_name LIKE '%aps%' OR option_name LIKE '%auto_post%';

   • के लिए खोजें 9. या विशेषताओं जैसे onload=, त्रुटि होने पर=, या जावास्क्रिप्ट: विकल्प मानों में।.
3. प्लगइन सेटिंग्स और सार्वजनिक आउटपुट की जाँच करें:
   • व्यवस्थापक के रूप में प्लगइन विकल्प पृष्ठ खोलें और इंजेक्टेड स्क्रिप्ट टैग या इनलाइन इवेंट हैंडलर्स के लिए पृष्ठ स्रोत देखें।.
   • इंजेक्टेड पेलोड के लिए बैकअप और निर्यातित विकल्पों की खोज करें।.
4. लॉग:
   • संदिग्ध POSTs के लिए वेब सर्वर और एक्सेस लॉग की समीक्षा करें जो प्रशासनिक एंडपॉइंट्स और असामान्य Content‑Type या पेलोड्स के लिए हैं।.
5. समझौते के संकेत:
   • अप्रत्याशित व्यवस्थापक खाते।.
   • नए या संशोधित प्लगइन्स/थीम्स जिन्हें आपने स्थापित नहीं किया।.
   • असामान्य आउटबाउंड ट्रैफिक या क्रॉन जॉब्स।.
   • स्पैम सामग्री या SEO इंजेक्शन।.

यदि आप संदिग्ध संकेत देखते हैं, तो तुरंत नीचे दिए गए घटना प्रतिक्रिया चेकलिस्ट के साथ आगे बढ़ें।.

तात्कालिक समाधान — अभी क्या करना है

अपने वातावरण के आधार पर कार्यों को प्राथमिकता दें। नीचे हांगकांग की घटना प्रतिक्रियाओं में अक्सर उपयोग किए जाने वाले व्यावहारिक कदम हैं।.

1. प्लगइन को निष्क्रिय करें यदि संभव हो।.
   • प्रशासनिक UI: प्लगइन्स → ऑटो पोस्ट शेड्यूलर को निष्क्रिय करें
   • WP‑CLI: wp प्लगइन निष्क्रिय करें ऑटो-पोस्ट-शेड्यूलर
2. 12. (होस्टिंग प्रतिबंध), सर्वर पर प्लगइन निर्देशिका को हटा दें या नाम बदलें, उदाहरण के लिए: (व्यावसायिक कारणों से), प्लगइन प्रशासनिक पृष्ठों तक पहुंच को प्रतिबंधित करें:
   • गैर-आवश्यक प्रशासनिक खातों के लिए अस्थायी रूप से विशेषाधिकार कम करें।.
   • IP या क्षमता द्वारा प्लगइन के प्रशासनिक UI तक पहुंच को ब्लॉक करने के लिए एक mu‑plugin तैनात करें।.
3. लक्षित WAF नियम लागू करें (यदि आप WAF को नियंत्रित करते हैं) शोषण पैटर्न को ब्लॉक करने के लिए:
   • उन प्लगइन विकल्प एंडपॉइंट्स पर POSTs को ब्लॉक करें जो स्क्रिप्ट मार्कर्स को शामिल करते हैं (9. या विशेषताओं जैसे onload=, त्रुटि होने पर=).
   • ऐसे एंडपॉइंट्स पर POSTs को ब्लॉक करें जैसे aps_options_page जिनमें मान्य nonce या referer की कमी है।.
4. क्रेडेंशियल्स को घुमाएं:
   • सभी प्रशासनिक खातों और किसी भी उच्च विशेषाधिकार वाले उपयोगकर्ताओं के लिए पासवर्ड रीसेट करने के लिए मजबूर करें।.
   • जहां संभव हो, प्रशासनिक उपयोगकर्ताओं के लिए दो-कारक प्रमाणीकरण सक्षम करें।.
5. स्कैन और साफ करें:
   • पूर्ण फ़ाइल अखंडता और मैलवेयर स्कैन करें।.
   • डेटाबेस और फ़ाइलों से इंजेक्टेड स्क्रिप्ट टैग खोजें और हटाएं; साफ़ बैकअप से संशोधित फ़ाइलों को पुनर्स्थापित करें।.
6. लॉग और निगरानी करें:
   • व्यवस्थापक क्रियाओं और फ़ाइल परिवर्तनों का विस्तृत लॉगिंग सक्षम करें।.
   • प्लगइन एंडपॉइंट्स पर दोहराए गए POST और असामान्य व्यवस्थापक गतिविधियों की निगरानी करें।.
7. यदि समझौता होने का संदेह है:
   • साइट को ऑफ़लाइन लें या पहुँच को प्रतिबंधित करें और पूर्ण फोरेंसिक सफाई करें।.

सुझाए गए शॉर्ट कोड शमन (अस्थायी आपातकालीन पैच)

केवल तभी लागू करें जब आप कोड संपादित करने में सहज हों और आपके पास बैकअप/स्टेजिंग हो। ये विकल्पों को संग्रहीत करने से पहले नॉन्स और क्षमता जांच जोड़ने के लिए आपातकालीन उपाय हैं। पहले स्टेजिंग पर परीक्षण करें।.

// mu-plugin आपातकालीन पैच: APS विकल्पों के लिए अप्रमाणित CSRF अपडेट को रोकें;

नोट्स:

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

अनुशंसित WAF नियम — व्यावहारिक उदाहरण

इन्हें अपने फ़ायरवॉल सिंटैक्स (mod_security, NGINX, Cloud WAF, आदि) के अनुसार अनुकूलित करें। झूठे सकारात्मक से बचने के लिए पहले मॉनिटर मोड में परीक्षण करें।.

1. इनलाइन स्क्रिप्ट के साथ POST को ब्लॉक करें
   • शर्तें:
     • विधि = POST
     • URI में “aps” या “auto-post-scheduler” या “aps_options_page” शामिल है”
     • शरीर में “
   • Action: Block (HTTP 403) and log.
2. Block suspicious options updates
   • Conditions:
     • URI equals “/wp-admin/admin-post.php” or “/wp-admin/options.php”
     • POST contains XSS indicators (<, >, on*, javascript:)
     • Missing or invalid referer header (optional)
   • Action: Challenge (captcha) or block.
3. Block cross‑origin admin POSTs
   • Condition:
     • Method = POST
     • Host header = yourdomain.com
     • Origin header not equal to yourdomain.com or empty
   • Action: Block or require extra verification.
4. Rate limit repeated attempts
   • If multiple blocked POSTs to aps endpoints originate from same IP, throttle or block.
5. Monitoring rule
   • Log any POSTs to plugin endpoints that contain script tags to detect attempts without blocking immediately.

Incident response checklist (step‑by‑step)

1. Snapshot and preserve: Take full backups of files and database for forensic analysis.
2. Isolate: Put the site into maintenance mode or restrict access.
3. Identify: Confirm plugin version and search for injected scripts in DB and files.
4. Contain: Deactivate the vulnerable plugin and apply WAF rules; rotate credentials.
5. Eradicate: Remove injected scripts, clean modified files, restore from clean backups.
6. Recover: Test on staging, then redeploy a cleaned site.
7. Hardening & follow‑up: Enable 2FA, apply least privilege, and monitor logs for 7–14 days.
8. Post‑incident review: Document timeline, root cause, and improvements.

Hardening recommendations for WordPress administrators

• Principle of least privilege: avoid daily use of admin accounts; create roles with specific capabilities.
• Use strong passwords and enforce two‑factor authentication for admin users.
• Protect the admin area by IP allow‑listing where feasible.
• Maintain regular, tested backups and practice restoration procedures.
• Schedule automated scans for file integrity and malware.
• Limit plugins to those you trust and that are actively maintained.
• Regularly review user accounts and remove unused admins.

How to safely audit your database for stored XSS payloads

Run these queries from a secure environment and back up the database before changes.

-- Search options for script tags
SELECT option_name, option_value
FROM wp_options
WHERE option_value LIKE '%