अपॉइंटमेंट बुकिंग कैलेंडर <= 1.3.95 — Broken Access Control (CVE‑2025‑64261) — What site owners must do now

लेखक: हांगकांग सुरक्षा विशेषज्ञ — दिनांक: 2025-11-18

सारांश: एक सार्वजनिक सलाह (CVE‑2025‑64261) रिपोर्ट करती है कि अपॉइंटमेंट बुकिंग कैलेंडर वर्डप्रेस प्लगइन में संस्करण 1.3.96 से पहले एक टूटा हुआ एक्सेस नियंत्रण सुरक्षा दोष है। एक सब्सक्राइबर-स्तरीय एक्सेस वाला हमलावर ऐसी कार्यक्षमता तक पहुँच सकता है जो प्रतिबंधित होनी चाहिए, जिससे अनधिकृत क्रियाएँ सक्षम होती हैं। इस मुद्दे का CVSS स्कोर 5.4 (कम) है लेकिन यह कई साइटों पर उपयोग किया जा सकता है जहाँ सब्सक्राइबर खाते प्राप्त करना आसान है। तुरंत 1.3.96 पर अपडेट करें; यदि यह संभव नहीं है, तो नीचे दिए गए शमन कदमों को लागू करें और WAF या समान परिधीय नियंत्रण के माध्यम से आभासी पैचिंग पर विचार करें।.

TL;DR — अब क्या करना है

• If you run Appointment Booking Calendar and your plugin version is <= 1.3.95, update to 1.3.96 immediately.
• यदि आप तुरंत अपडेट नहीं कर सकते हैं, तो आपातकालीन शमन करें:
  • जब तक आप अपडेट नहीं कर सकते, प्लगइन को निष्क्रिय करें।.
  • वेब सर्वर नियमों या परिधीय नियंत्रण के माध्यम से प्लगइन-फेसिंग एंडपॉइंट्स (admin-ajax.php, REST API रूट) तक पहुँच को प्रतिबंधित करें।.
  • अविश्वसनीय सब्सक्राइबर खातों को हटा दें, कड़ी पंजीकरण लागू करें, और उच्च-privilege उपयोगकर्ताओं के लिए 2FA सक्षम करें।.
• विक्रेता पैच लागू होने तक प्लगइन के एंडपॉइंट्स को लक्षित करने वाले संदिग्ध अनुरोधों को रोकने के लिए WAF या एज फ़िल्टरिंग के माध्यम से आभासी पैचिंग पर विचार करें।.
• समझौते के संकेतों (अनधिकृत बुकिंग, नए व्यवस्थापक उपयोगकर्ता, बदले गए सेटिंग्स, संशोधित प्लगइन फ़ाइलें) के लिए लॉग और साइट की अखंडता की समीक्षा करें।.

पृष्ठभूमि — क्या रिपोर्ट किया गया

A broken access control vulnerability was disclosed for the Appointment Booking Calendar WordPress plugin affecting versions <= 1.3.95 (CVE‑2025‑64261). The issue allows a user with a subscriber role to invoke functionality that should be protected by higher privileges, due to missing or insufficient authorization/nonce checks in certain plugin endpoints. The plugin author released version 1.3.96 to address the problem.

टूटा हुआ एक्सेस नियंत्रण प्लगइन्स में एक सामान्य सुरक्षा दोष वर्ग है: या तो एक क्षमता जांच (current_user_can()) अनुपस्थित है, एक REST रूट में उपयुक्त permission_callback की कमी है, या नॉन्स जांच/CSRF सुरक्षा अनुपस्थित हैं। हालांकि इस मामले में आवश्यक विशेषाधिकार को सब्सक्राइबर (एक कम-विशेषाधिकार भूमिका) के रूप में सूचीबद्ध किया गया है, इसका मतलब यह नहीं है कि समस्या हानिरहित है — सब्सक्राइबर खाते कई साइटों पर सामान्य रूप से मौजूद होते हैं (उपयोगकर्ता पंजीकरण, परीक्षक, कर्मचारी) और समझौता या कमजोर पंजीकरण के माध्यम से बनाए जा सकते हैं।.

Why this matters (even when the CVSS score is “low”)

CVSS एक उपयोगी आधार रेखा प्रदान करता है, लेकिन संदर्भ महत्वपूर्ण है। एक सुरक्षा दोष जो सब्सक्राइबरों को ऐसे कार्य करने की अनुमति देता है जो केवल संपादक/व्यवस्थापक के लिए होने चाहिए, निम्नलिखित परिणाम दे सकता है:

• बुकिंग डेटा के साथ छेड़छाड़: ऐसी बुकिंग बनाना, संशोधित करना या हटाना जो सेवा को बाधित करे या धोखाधड़ी वाली नियुक्तियाँ बनाए।.
• जानकारी का खुलासा: बुकिंग सूचियों, ग्राहक विवरणों, या निजी नोट्स तक पहुँच।.
• विशेषाधिकार वृद्धि श्रृंखलाएँ: इस बग को किसी अन्य कमजोर क्षेत्र के साथ मिलाकर हमलावरों को व्यवस्थापक तक पहुँचने की अनुमति मिल सकती है।.
• प्रतिष्ठा और व्यवसाय पर प्रभाव: नियुक्ति प्रणाली अक्सर ग्राहक संपर्क जानकारी, रद्दीकरण कार्यप्रवाह, या स्वचालित ईमेल शामिल करती है - छेड़छाड़ से नियुक्तियाँ छूट सकती हैं, बिलिंग त्रुटियाँ हो सकती हैं, या कानूनी जोखिम हो सकता है।.

क्योंकि कई साइटों पर ग्राहक खातों को प्राप्त करना आसान है (खुले पंजीकरण, विरासती परीक्षण खाते), इस प्रकार की कमजोरियों को जोखिम में पड़े साइटों के लिए तत्काल माना जाना चाहिए।.

कमजोरियों का सामान्य रूप (तकनीकी अवलोकन)

वर्डप्रेस प्लगइन्स में टूटी हुई पहुँच नियंत्रण आमतौर पर निम्नलिखित तरीकों में से एक में प्रकट होती है:

• व्यवस्थापक AJAX एंडपॉइंट्स (admin-ajax.php) में क्षमता जांच का अभाव।.
  • उदाहरण बुरा पैटर्न: एक क्रिया पैरामीटर के साथ POST अनुरोध को संसाधित करना लेकिन current_user_can() या check_admin_referer() को कॉल करने में विफल रहना।.
• REST API मार्ग बिना सुरक्षित permission_callback के पंजीकृत होते हैं।.
  • Example bad pattern: register_rest_route(‘abc/v1’, ‘/do’, [‘methods’=>’POST’, ‘callback’=>’do_stuff’]); // no permission_callback
• फ्रंटेंड फॉर्म या एंडपॉइंट जो nonce सत्यापन की कमी रखते हैं या केवल उपयोगकर्ता स्थिति पर निर्भर करते हैं।.
• क्रियाएँ जो अनुरोध पैरामीटर या उपयोगकर्ता आईडी मानों पर भरोसा करती हैं बजाय कि प्रमाणित उपयोगकर्ता के खिलाफ मान्य करने के।.

विशिष्ट सलाह यह दर्शाती है कि शोषण के लिए आवश्यक विशेषाधिकार सब्सक्राइबर है; यह सुझाव देता है कि प्लगइन एक एंडपॉइंट को उजागर करता है जो सब्सक्राइबर (या सार्वजनिक) द्वारा पहुँचा जा सकता है जो बिना भूमिकाओं या nonces की जांच किए उच्च-विशेषाधिकार लॉजिक को निष्पादित करता है।.

संभावित हमले के परिदृश्य

1. खाता दुरुपयोग (कम प्रयास)

   हमलावर एक सब्सक्राइबर खाता पंजीकृत करता है (या एक मौजूदा को समझौता करता है) और प्रभावित एंडपॉइंट (AJAX या REST) को कॉल करता है ताकि बुकिंग बनाने या संशोधित करने, बुकिंग सूचियों को निर्यात करने, या उपलब्धता को बदलने जैसी क्रियाएँ की जा सकें। प्रभाव: खोई हुई बुकिंग, अनधिकृत ग्राहक सूचनाएँ, डेटा लीक।.

2. लॉगिन किए गए सब्सक्राइबरों के खिलाफ क्रॉस-साइट अनुरोध धोखाधड़ी (CSRF)

   यदि एंडपॉइंट nonce जांच की कमी रखते हैं और अन्य साइटों से ट्रिगर किए गए POST स्वीकार करते हैं, तो एक हमलावर एक लॉगिन किए गए सब्सक्राइबर को एक पृष्ठ पर लुभा सकता है और क्रियाएँ कर सकता है।.

3. विशेषाधिकार बढ़ाने के लिए श्रृंखला बनाना

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

पहचान — कैसे जानें कि क्या आप लक्षित या शोषित हुए थे

लॉग और साइट पर जांच से शुरू करें:

• असामान्य POST के लिए वेब सर्वर एक्सेस लॉग की समीक्षा करें:
  • /wp-admin/admin-ajax.php?action=*
  • /wp-json/* (REST API एंडपॉइंट)
• संदिग्ध IPs से या असामान्य User-Agent स्ट्रिंग के साथ अनुरोधों की तलाश करें।.
• असामान्य परिवर्तनों के लिए डेटाबेस की खोज करें:
  • अजीब टाइमस्टैम्प के साथ नए या संशोधित बुकिंग।.
  • संदिग्ध अनुरोधों के आसपास उसी समय बनाए गए नए खाते।.
• अनधिकृत संशोधनों के लिए प्लगइन फ़ाइलों का निरीक्षण करें: वर्तमान प्लगइन फ़ाइलों की तुलना ज्ञात-स्वच्छ संस्करण की ताजा प्रति से करें।.
• हाल के उपयोगकर्ताओं और भूमिकाओं की सूची के लिए WP-CLI का उपयोग करें:

  wp उपयोगकर्ता सूची --भूमिका=सदस्य --भूमिका=योगदानकर्ता --फॉर्मेट=तालिका

• यदि आपके पास सक्षम हैं तो वर्डप्रेस गतिविधि और ऑडिट लॉग की जांच करें।.

संदिग्ध संकेतक:

• एक ही सब्सक्राइबर खाते से उत्पन्न कई बुकिंग परिवर्तन।.
• अप्रत्याशित मानों या गलत फ़ॉर्मेटेड मेटा फ़ील्ड के साथ बुकिंग प्रविष्टियाँ।.
• बुकिंग डेटा से संबंधित अनधिकृत निर्यात या डाउनलोड अनुरोध।.

तात्कालिक शमन कदम (साइट के मालिक / प्रशासक)

यदि आप अपॉइंटमेंट बुकिंग कैलेंडर चलाते हैं और तुरंत अपडेट नहीं कर सकते हैं, तो इन शमन उपायों का पालन इस क्रम में करें:

प्लगइन को 1.3.96 (सिफारिश की गई) में अपडेट करें

सबसे अच्छा और सरल समाधान। स्टेजिंग पर परीक्षण करें, फिर उत्पादन में लागू करें।.

यदि आप तुरंत अपडेट नहीं कर सकते हैं, तो प्लगइन को निष्क्रिय करें

Plugins → Installed Plugins → Appointment Booking Calendar को निष्क्रिय करें। यह कमजोर कोड के निष्पादन को रोकता है।.

प्लगइन एंडपॉइंट्स के लिए वेब सर्वर-स्तरीय एक्सेस नियंत्रण लागू करें

ज्ञात प्लगइन एंडपॉइंट्स तक पहुंच को रोकें जहां संभव हो (AJAX क्रियाएँ या REST रूट) जब तक पैच न किया जाए। उदाहरण स्निपेट (अपने वातावरण के अनुसार समायोजित करें):

Apache (.htaccess) उदाहरण:

# Block requests that attempt to call a known vulnerable action name

  RewriteEngine On
  RewriteCond %{REQUEST_URI} ^/wp-admin/admin-ajax.php$ [NC]
  RewriteCond %{QUERY_STRING} action=(vulnerable_action_name) [NC,OR]
  RewriteCond %{REQUEST_METHOD} POST
  RewriteRule .* - [F,L]

Nginx उदाहरण:

if ($request_uri = "/wp-admin/admin-ajax.php") {

उपयोगकर्ता खातों को मजबूत करें

• अप्रयुक्त सदस्य खातों को हटा दें।.
• संदिग्ध खातों के लिए पासवर्ड रीसेट करने के लिए मजबूर करें।.
• यदि आवश्यक न हो तो सार्वजनिक पंजीकरण को निष्क्रिय करें।.
• नए पंजीकृत उपयोगकर्ताओं के लिए डिफ़ॉल्ट भूमिका असाइनमेंट को सीमित करें।.

परिधीय फ़िल्टरिंग / आभासी पैच जोड़ें

यदि आप एक एज WAF या फ़िल्टरिंग उपकरण संचालित करते हैं, तो प्लगइन के एंडपॉइंट्स (admin-ajax, प्लगइन का REST रूट, विशिष्ट POST पैटर्न) को लक्षित करने वाले अनुरोधों को ब्लॉक करने के लिए अस्थायी नियम जोड़ें। आधिकारिक अपडेट लागू करते समय आभासी पैचिंग जोखिम को कम कर सकती है।.

निगरानी और स्कैन करें

साइट पर पूर्ण मैलवेयर और अखंडता स्कैन चलाएँ। प्रारंभिक शमन के बाद दोहराए गए प्रयासों के लिए लॉग की निगरानी करें।.

यदि समझौता संदिग्ध है तो घटना प्रतिक्रिया

• यदि आप सक्रिय शोषण देखते हैं तो साइट को ऑफ़लाइन ले जाएँ या इसे रखरखाव मोड में डालें।.
• समझौते से पहले बनाए गए एक साफ़ बैकअप से पुनर्स्थापित करें।.
• WP सॉल्ट और API कुंजी घुमाएँ, व्यवस्थापक पासवर्ड बदलें, और सर्वर-स्तरीय पहुँच कुंजी की जाँच करें।.

सामान्य रक्षात्मक नियंत्रण (ऑपरेटरों और डेवलपर्स के लिए)

स्तरित नियंत्रण बनाए रखें और सुरक्षित विकास प्रथाओं का पालन करें:

• क्षमता जांच: संवेदनशील क्रियाओं के लिए हमेशा current_user_can() कॉल करें।.
• नॉनस सत्यापन: check_ajax_referer() या check_admin_referer() का उपयोग करें।.
• REST API permission_callback: अनुमति जांच के बिना कभी भी REST मार्ग पंजीकृत न करें।.
• इनपुट मान्यता और स्वच्छता: कभी भी क्लाइंट द्वारा प्रदान किए गए IDs या पैरामीटर पर भरोसा न करें।.
• न्यूनतम विशेषाधिकार का सिद्धांत: व्यवस्थापक-जैसी कार्यों के लिए सब्सक्राइबर-स्तरीय पहुँच देने से बचें।.
• स्वचालित परीक्षण और CI सुरक्षा स्कैन जो पुनरावृत्तियों को जल्दी पकड़ें।.

उदाहरण ModSecurity नियम (केवल चित्रण के लिए)

नीचे एक चित्रणात्मक ModSecurity नियम है जिसका उपयोग आप अस्थायी ब्लॉक के रूप में कर सकते हैं यदि आप कमजोर क्रिया नाम जानते हैं। action_name_here को उस विशिष्ट क्रिया से बदलें जिसे आप ब्लॉक करना चाहते हैं।.

SecRule REQUEST_URI "@streq /wp-admin/admin-ajax.php" "phase:1,chain,deny,log,msg:'संदिग्ध अपॉइंटमेंट बुकिंग कैलेंडर AJAX क्रिया को ब्लॉक करें'"

महत्वपूर्ण: स्टेजिंग का उपयोग करें और सावधानी से परीक्षण करें — व्यवस्थापक‑ajax को व्यापक रूप से ब्लॉक करना उन प्लगइन्स को तोड़ सकता है जो इस पर निर्भर करते हैं।.

डेवलपर्स को कोड कैसे ठीक करना चाहिए (प्लगइन लेखक / रखरखाव करने वाले)

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

1. क्षमताओं की पुष्टि करें:

   if ( ! current_user_can( 'manage_options' ) ) {
   

2. फ़ॉर्म और AJAX सबमिशन के लिए नॉनस का उपयोग करें:

   check_ajax_referer( 'my_plugin_nonce', 'security' );
   

3. REST API मार्गों के लिए, एक permission_callback सेट करें:

   register_rest_route( 'my-plugin/v1', '/do-action', array(;
   

4. इनपुट को साफ करें और मान्य करें - क्लाइंट से भेजे गए आईडी पर भरोसा करने से बचें।.
5. न्यूनतम विशेषाधिकार का सिद्धांत - ऐसे एंडपॉइंट्स का डिज़ाइन न करें जो केवल सब्सक्राइबर विशेषाधिकार की आवश्यकता हो ताकि प्रशासनिक कार्य किए जा सकें।.
6. Unit tests & security reviews — add tests covering role validation and endpoint protection; include security checks in CI.

यदि आपको समझौता होने का संदेह है - फोरेंसिक चेकलिस्ट

1. फोरेंसिक्स के लिए साइट और डेटाबेस का स्नैपशॉट लें।.
2. लॉग एकत्र करें (वेब सर्वर, एप्लिकेशन, फ़ायरवॉल/WAF)।.
3. संदिग्ध गतिविधि की समयरेखा पहचानें: प्लगइन एंडपॉइंट्स पर POSTs और सब्सक्राइबर खातों द्वारा किए गए कार्यों की तलाश करें।.
4. वेबशेल और संशोधित कोर/प्लगइन/थीम फ़ाइलों की खोज करें; ज्ञात-अच्छे प्रतियों के साथ हैश की तुलना करें।.
5. नए प्रशासनिक उपयोगकर्ताओं या परिवर्तित विशेषाधिकारों की जांच करें।.
6. यदि आवश्यक हो तो एक साफ बैकअप से पुनर्स्थापित करें; उत्पादन में पुनर्स्थापित करने से पहले सुनिश्चित करें कि भेद्यता पैच की गई है।.
7. सभी क्रेडेंशियल्स और वर्डप्रेस सॉल्ट्स (wp-config.php AUTH_KEY constants) को घुमाएँ, और API टोकन या एकीकरण कुंजियों को अपडेट करें।.

साइट मालिकों के लिए संचार मार्गदर्शन

• हितधारकों (ग्राहक, आंतरिक टीमें) को जोखिम, जोखिम स्तर और उठाए गए कार्यों के बारे में सूचित करें।.
• यदि बुकिंग या ग्राहक डेटा उजागर हो सकता है, तो गोपनीयता आवश्यकताओं और स्थानीय नियमों के आधार पर प्रभावित उपयोगकर्ताओं को सूचित करने पर विचार करें।.
• अनुपालन/ऑडिट उद्देश्यों के लिए जांच और शमन कदमों की समयरेखा बनाए रखें।.

दीर्घकालिक हार्डनिंग सिफारिशें

• सभी गैर-सब्सक्राइबर खातों के लिए दो-कारक प्रमाणीकरण (2FA) लागू करें।.
• उपयोगकर्ता पंजीकरण प्रवाह को सीमित और ऑडिट करें - यदि संभव हो तो आमंत्रण-आधारित या प्रशासनिक अनुमोदन का उपयोग करें।.
• नियमित रूप से प्लगइन/थीम भेद्यता स्कैन चलाएँ और वर्डप्रेस, प्लगइन्स और थीम को अद्यतित रखें।.
• एक घटना प्रतिक्रिया योजना बनाए रखें और बैकअप से नियमित पुनर्स्थापना अभ्यास करें।.
• भूमिकाएँ सौंपते समय न्यूनतम विशेषाधिकार का उपयोग करें; नियमित कार्यों के लिए प्रशासनिक खातों का उपयोग न करें।.
• महत्वपूर्ण एंडपॉइंट्स (admin‑ajax, REST रूट, लॉगिन एंडपॉइंट) के लिए लॉगिंग और निगरानी सक्षम करें।.
• जब आवश्यक हो, नए खोजे गए कमजोरियों के लिए त्वरित आभासी पैच प्रदान करने के लिए वेब एप्लिकेशन फ़ायरवॉलिंग या परिधीय फ़िल्टरिंग लागू करें।.

सामान्य प्रश्न — त्वरित उत्तर

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

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

प्रश्न: अगर मैंने अपडेट किया लेकिन फिर भी लॉग में हमले देखे?
उत्तर: हमलावर वेब को स्कैन करते हैं और शोषण का प्रयास करते रहेंगे। सुनिश्चित करें कि आपका अपडेट किया गया प्लगइन सही संस्करण है, निगरानी जारी रखें, और शोर करने वाले अभिनेताओं को ब्लॉक करने के लिए परिधीय नियम जोड़ें। यदि आप अपडेट करने के बाद संदिग्ध क्रियाओं को सफल होते हुए देखते हैं, तो साइट को संभावित रूप से समझौता किया गया मानें और एक पूर्ण जांच करें।.

अंतिम नोट्स

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

If you run Appointment Booking Calendar (<= 1.3.95), update to 1.3.96 now. If you manage many sites or have clients that rely on bookings, use perimeter filtering or virtual patching while you coordinate vendor updates and testing. If you need professional assistance with hardening or rapid mitigations across multiple sites, engage a trusted security consultant or your hosting provider’s security team.

CVE संदर्भ: CVE-2025-64261. प्रकटीकरण तिथि: 2025-11-17।.