CVE-2026-79387: PbootCMS V3.2.5 उपयोगकर्ता प्रबंधन मॉड्यूल में SQL इंजेक्शन

अवलोकन

फ़ील्ड	विवरण
CVE ID	CVE-2026-79387
उत्पाद	PbootCMS
प्रभावित संस्करण	3.2.0 – 3.2.5, और संभवतः पहले के भी
भेद्यता प्रकार	SQL इंजेक्शन (CWE-89)
आक्रमण वेक्टर	रिमोट (प्रमाणित)
CVSS गंभीरता	उच्च
खोजकर्ता	JiahaoLi
विक्रेता	https://www.pbootcms.com/

भेद्यता विवरण

PbootCMS V3.2.5 के उपयोगकर्ता प्रबंधन मॉड्यूल में एक SQL इंजेक्शन भेद्यता मौजूद है। यह भेद्यता /apps/admin/controller/system/UserController.php (पंक्ति 149) की mod() विधि और /apps/admin/model/system/UserModel.php की modUser() विधि में निहित है।

field पैरामीटर पूरी तरह से उपयोगकर्ता-नियंत्रित है, जो बिना किसी व्हाइटलिस्ट सत्यापन के GET अनुरोध के माध्यम से प्राप्त होता है। value पैरामीटर भी समान रूप से उपयोगकर्ता-नियंत्रित है और सीधे SQL UPDATE कथन में जोड़ा जाता है। एक प्रमाणित आक्रमणकारी field के रूप में किसी भी डेटाबेस कॉलम (जैसे, password, username, status, role) को निर्दिष्ट कर सकता है, जिससे मनमाना डेटा हेरफेर संभव हो जाता है।

मूल कारण

// UserController.php - mod() method
if (($field = get('field', 'var')) && ! is_null($value = get('value', 'var'))) {
    if ($this->model->modUser($ucode, "$field='$value',update_user='" . session('username') . "'")) {
        location(- 1);
    }
}

$field और $value सीधे $_GET सुपरग्लोबल से लिए जाते हैं और बिना किसी सैनिटाइज़ेशन, बिना व्हाइटलिस्ट, और बिना पैरामीटराइज़्ड क्वेरी के एक SQL स्ट्रिंग में जोड़ दिए जाते हैं। यह स्ट्रिंग फिर UserModel::modUser() को पास की जाती है, जो इसे बेस Model::update() मेथड को अग्रेषित करता है। चूँकि आर्ग्युमेंट एक स्ट्रिंग है (ऐरे नहीं), यह checkKey() फ़ील्ड-नाम वैलिडेशन को बायपास कर देता है और सीधे SET क्लॉज़ में जस का तस एम्बेड हो जाता है:

UPDATE ay_user SET <user-controlled>= '<user-controlled>', update_user='admin' WHERE ucode='<ucode>'

कॉल चेन

GET /admin.php?p=/User/mod&ucode=10002&field=password&value=<MD5>
  → UserController::mod()
    → UserModel::modUser($ucode, "password='<value>',update_user='admin'")
      → Model::table('ay_user')->where("ucode='$ucode'")->update($data_string)
        → SQL: UPDATE ay_user SET password='<value>',update_user='admin' WHERE ucode='10002'

प्रभाव

एक प्रमाणित हमलावर यह कर सकता है:

1. किसी भी उपयोगकर्ता का पासवर्ड बदल सकता है — जिसमें सुपर एडमिनिस्ट्रेटर भी शामिल है (अंतर्निहित संस्थापक ucode=10001 को छोड़कर)।
2. खाता स्थिति बदल सकता है — मनमाने खातों को सक्षम या अक्षम कर सकता है।
3. गहरा SQL इंजेक्ट कर सकता है — value पैरामीटर सिंगल-कोट एस्केप की अनुमति देता है, जो संभावित रूप से स्टैक्ड या टॉटोलॉजी-आधारित हमलों को सक्षम कर सकता है।

इससे खाता अधिग्रहण और CMS बैकएंड पर पूर्ण नियंत्रण होता है।

पुनरुत्पादन चरण

पूर्वापेक्षाएँ

• PbootCMS V3.2.5 स्थानीय रूप से स्थापित (192.168.1.104, Apache/PHP 7.2.1/SQLite पर परीक्षण किया गया)
• एक वैध बैकएंड एडमिन खाता

चरण 1: एडमिन पैनल में लॉगिन करें

PbootCMS एडमिन डैशबोर्ड तक पहुँचें और डिफ़ॉल्ट admin खाते से लॉगिन करें।

चरण 2: एक लक्ष्य उपयोगकर्ता बनाएँ

System Management → User Management → Add User पर जाएँ। एक नया उपयोगकर्ता बनाएँ:

• उपयोगकर्ता नाम: admin2
• पासवर्ड: admin
• भूमिका: System Administrator

चरण 3: उपयोगकर्ता के अस्तित्व की पुष्टि करें

उपयोगकर्ता सूची admin2 की पुष्टि करती है जिसका ucode=10002 है:

चरण 4: प्रारंभिक पासवर्ड की पुष्टि करें

एक नई ब्राउज़र विंडो खोलें। admin2 के रूप में पासवर्ड 123456 के साथ लॉगिन करने का प्रयास करें — यह विफल होता है क्योंकि वास्तविक पासवर्ड admin है:

चरण 5: पेलोड तैयार करें और निष्पादित करें

पहले से लॉग-इन किए गए एडमिन ब्राउज़र का उपयोग करते हुए, यहाँ नेविगेट करें:

http://192.168.1.104/PbootCMS/admin.php?p=/User/mod&ucode=10002&field=password&value=14e1b600b1fd579f47433b88e8d85291

14e1b600b1fd579f47433b88e8d85291, 123456 का MD5 हैश है।

mod() विधि इंजेक्शन निष्पादित करती है और location(-1) के माध्यम से रीडायरेक्ट करती है:

चरण 6: पासवर्ड परिवर्तन सत्यापित करें

अब admin2 / 123456 के साथ लॉग इन करने का प्रयास करें:

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

स्रोत कोड विश्लेषण

असुरक्षित कोड (UserController.php, पंक्ति ~149)

डेटाबेस परत (Model.php - update विधि)

जब update() को एक स्ट्रिंग आर्ग्युमेंट मिलता है, तो इसे बिना किसी एस्केपिंग के SET क्लॉज़ में जैसा है वैसा ही उपयोग किया जाता है:

final public function update($data = null)
{
    if (is_array($data)) {
        // Array path: checkKey() validates field names
        ...
    } else {
        // String path: NO VALIDATION AT ALL
        $update_string = $data;
    }
    $this->sql['value'] = $update_string;
    $sql = $this->buildSql($this->updateSql);
    return $this->getDb()->amd($sql);  // Direct execution, no prepared statement
}

उपचार

1. field पैरामीटर पर व्हाइटलिस्ट सत्यापन — केवल ज्ञात कॉलम नामों (status, username, realname, password) की अनुमति दें।
2. पैरामीटरयुक्त क्वेरी — स्ट्रिंग संयोजन के बजाय तैयार किए गए स्टेटमेंट का उपयोग करें।
3. उपयोगकर्ता इनपुट को एस्केप करें — कम से कम, उद्धरण-भंग को रोकने के लिए $value को सैनिटाइज़ करें।
4. पासवर्ड हैशिंग को बाध्य करें — यदि field password है, तो संग्रहण से पहले मान पर encrypt_string() लागू करें।
5. स्टैंडअलोन-मॉडिफ़ाई पथ को प्रतिबंधित करें — mod() में "एकल फ़ील्ड संशोधन" शाखा के लिए एक वैध CSRF टोकन और भूमिका-स्तरीय प्राधिकरण जाँच आवश्यक होनी चाहिए।

संदर्भ

• PbootCMS आधिकारिक वेबसाइट
• Gitee पर PbootCMS स्रोत
• CVE-2026-79387

---

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