absholi7ly/elementor-pro-unauthenticated-arbitrary-file-upload-to-rceCVE-2026-32475 Elementor Pro Forms का File Upload फ़ील्ड सत्यापन और फ़ाइल प्रोसेसिंग को दो अलग-अलग लूपों में संभालता है, जिनमें खाली अपलोड प्रविष्टियों (UPLOAD_ERR_NO_FILE) के लिए अलग-अलग हैंडलिंग होती है। एक अनप्रमाणित हमलावर मल्टीपार्ट सबमिट कर सकता है
Elementor Pro Forms File Upload फ़ील्ड, वैलिडेशन और फ़ाइल प्रोसेसिंग को दो अलग-अलग लूपों में संभालती है, जिनमें खाली अपलोड प्रविष्टियों (UPLOAD_ERR_NO_FILE) के लिए अलग-अलग हैंडलिंग होती है। एक अनप्रमाणित हमलावर उसी फ़ील्ड के लिए खाली पहले फ़ाइल भाग के बाद एक PHP पेलोड के साथ मल्टीपार्ट अनुरोध सबमिट कर सकता है, जिससे validation() समय से पहले return कर जाता है, जबकि process_field() फिर भी PHP फ़ाइल को एक सार्वजनिक निर्देशिका में ले जाता है: wp-content/uploads/elementor/forms/.php
लक्ष्य पृष्ठ से post_id, form_id, और field_id स्वचालित रूप से प्राप्त करता है:
python poc.py -t http://localhost/wp --page-url "http://localhost/wp/?page_id=16" -c "whoami"
या:
python poc.py -t http://localhost/wp --page-id 16 -c "whoami"
एक इंटरैक्टिव सत्र प्रारंभ करें:
python poc.py -t http://localhost/wp --page-id 16 -i
इस भेद्यता का मूल तत्व फ़ाइल अपलोड तंत्र को ही बायपास करना है। यह भाग इस बात पर निर्भर नहीं करता कि आप परीक्षण स्थानीय लैब में करते हैं या वास्तविक सर्वर के विरुद्ध: अपलोड फ़ील्ड में खाली पहला फ़ाइल भाग + PHP पेलोड एक्सटेंशन वैलिडेशन को बायपास कर देता है, फिर भी फ़ाइल process_field() द्वारा प्रोसेस की जाती है। हमने प्रदर्शित किया कि फ़ाइल सफलतापूर्वक लिखी जाती है, जो वास्तव में वही है जो इसका वर्णन करता है।
हार्डकोडेड Laragon पथ के संबंध में:
वह केवल स्थानीय सत्यापन की सुविधा के लिए था।
वास्तविक लक्ष्य पर, निर्देशिका पैटर्न ज्ञात और निश्चित है:
/wp-content/uploads/elementor/forms/
जो निश्चित नहीं है वह अंतिम फ़ाइल नाम है।
Elementor मूल फ़ाइल नाम को बरकरार नहीं रखता। process_field() में, संग्रहीत फ़ाइल नाम इस प्रकार उत्पन्न होता है:
इसलिए, यदि आप shell.php अपलोड करते हैं, तो फ़ाइल नाम कुछ ऐसा हो सकता है:
66f3a1c2e9b47.php
इसके अंदर:
/wp-content/uploads/elementor/forms/
uniqid() समय-आधारित है और कोई मजबूत रैंडम मान नहीं है; यह लगभग टाइमस्टैम्प + माइक्रोसेकंड पर आधारित होता है। इसलिए, फ़ाइल को दूरस्थ रूप से पुनर्प्राप्त करना अपलोड समस्या के बजाय फ़ाइल-नाम खोज की समस्या बन जाता है।
उदाहरण के लिए, आप सर्वर के Date हेडर और अनुरोध समय के आधार पर एक टाइमिंग विंडो का उपयोग कर सकते हैं, अपलोड समय के आसपास एक संकीर्ण सीमा में खोज कर सकते हैं, या यदि फ़ॉर्म [all-fields] युक्त ईमेल भेजता है तो सटीक URL पुनर्प्राप्त कर सकते हैं।
मैंने PoC को मूल समस्या को ही स्पष्ट और सीधे सिद्ध करने पर केंद्रित रखा, जो कि अनप्रमाणित फ़ाइल अपलोड है। uniqid() मान की दूरस्थ पुनर्प्राप्ति को पूरी तरह समझाने से प्रदर्शन स्वयं भेद्यता को मान्य करने के लिए आवश्यकता से कहीं अधिक लंबा हो जाता।