Elementor Pro کی سنگین خامی؛ update کے بعد uploads بھی چیک کریں

26 اگست 2026 کی F5 Labs threat bulletin نے Elementor Pro کی CVE-2026-32475 خامی کو critical قرار دیتے ہوئے CVSS اسکور 9.0 بتایا ہے۔ اس کے مطابق 4.2.1 تک کے ورژن میں Forms module کی file-upload handling ایسی تیار کردہ درخواست کو remote code execution تک پہنچا سکتی ہے جس کے لیے WordPress login درکار نہیں۔

منتظم کے لیے فوری جواب یہ ہے کہ Elementor Pro کو 4.2.2 یا بعد کے مستحکم ورژن پر update کیا جائے، پھر wp-content/uploads/elementor/forms/ میں غیر متوقع PHP فائلیں تلاش کی جائیں۔ 26 اگست کی bulletin نے یہ دونوں اقدامات الگ الگ رکھے ہیں: update آئندہ exploitation کا راستہ بند کرتا ہے، لیکن پہلے سے upload ہوئی فائل کی موجودگی کا فیصلہ directory audit سے ہوگا۔

کون سے ورژن اور forms خطرے میں ہیں؟

CERT-In کے vulnerability note میں Elementor Pro کے 4.2.2 سے پہلے تمام ورژن متاثرہ درج ہیں۔ نوٹ کے مطابق File Upload module فائلوں کی validation اور processing کے لیے الگ loops استعمال کرتا ہے، جو خالی filename کو مختلف انداز سے سنبھالتے ہیں؛ crafted multipart درخواست اسی فرق سے executable فائل upload کروا سکتی ہے۔

اس لیے 4.2.1 یا اس سے پرانا فعال ورژن پہلی فیصلہ کن شرط ہے۔ بیان کردہ حملہ Forms module کے File Upload field سے متعلق ہے، لہٰذا internet سے قابلِ رسائی ایسا form فوری ترجیح بنتا ہے؛ تاہم field کو حذف یا غیر فعال کرنا patch کا متبادل نہیں، کیونکہ پرانا plugin بدستور متاثرہ code رکھتا ہے اور پہلے موصول ہونے والی فائل خود بخود ختم نہیں ہوتی۔

یہ CVE مفت Elementor plugin کے عمومی استعمال کا بیان نہیں، بلکہ Elementor Pro کے مخصوص upload workflow سے متعلق ہے۔ Plugins صفحے، hosting panel یا plugin files سے Pro کا حقیقی فعال version دیکھیں؛ صرف directory کے نام، theme یا مرکزی management dashboard کے سبز status پر انحصار نہ کریں۔

متاثرہ حالت کی decision tree

1. پہلے ہر public WordPress installation پر تصدیق کریں کہ Elementor Pro نصب اور فعال ہے۔ Production، staging، subdomain اور پرانی قابلِ رسائی copies کو الگ installations سمجھیں۔
2. اگر فعال version 4.2.1 یا اس سے پرانا ہے تو اسے متاثرہ شمار کرکے 4.2.2 یا دستیاب اس سے نئے مستحکم ورژن پر update کریں۔
3. اگر موجودہ version 4.2.2 یا بعد کا ہے تو update کی تاریخ دیکھیں۔ اگر site پہلے متاثرہ version چلاتی رہی تھی تو موجودہ patch status سابقہ compromise کے امکان کو ختم نہیں کرتا۔
4. Elementor forms میں File Upload field تلاش کریں، خصوصاً ایسے forms میں جن تک login کے بغیر رسائی رہی ہو۔ ایسا form ملنے پر directory audit کو patch کے فوراً بعد انجام دیں۔
5. اگر site کبھی متاثرہ version پر نہیں چلی اور ہر متعلقہ instance کم از کم 4.2.2 پر ہے تو اس CVE کی version condition پوری نہیں ہوتی؛ پھر بھی uploads میں script execution روکنا مفید مستقل control ہے۔

ایک installation کا update دوسری copy کو محفوظ نہیں کرتا۔ اسی طرح update کا کامیابی پیغام کافی نہیں اگر deployment ادھورا رہا ہو، cache سے پرانا package بحال ہوا ہو یا کسی node پر پرانی plugin files موجود ہوں؛ فیصلہ فعال code کے version سے کریں۔

Update کے بعد forms directory کیسے جانچیں؟

Elementor کی سرکاری Pro changelog entry میں 4.2.2 کی تاریخ 19 اگست 2026 درج ہے اور Form widget کے ساتھ Dynamic Tags کے لیے بہتر code-security enforcement شامل ہے۔ Changelog اس entry میں CVE نمبر نہیں لکھتا، اس لیے محفوظ حد کی نسبت vulnerability advisories سے آتی ہے، جبکہ vendor page 4.2.2 میں متعلقہ security تبدیلی کی تصدیق کرتا ہے۔

Update مکمل ہونے کے بعد file manager، SFTP یا محفوظ shell access کے ذریعے wp-content/uploads/elementor/forms/ اور اس کی ذیلی directories دیکھیں۔ جائز uploads کی متوقع اقسام سے موازنہ کرتے ہوئے .php یا دوسری executable script، غیر مانوس نام اور update سے پہلے کا غیر معمولی timestamp نشان زد کریں۔ محض عجیب نام compromise ثابت نہیں کرتا، مگر uploads کے اس مقام پر غیر متوقع PHP فائل فوری investigation کا مضبوط سبب ہے۔

مشکوک فائل کو browser سے کھول کر نہ آزمائیں اور ثبوت محفوظ کیے بغیر فوراً حذف نہ کریں۔ پہلے اس کی محفوظ copy، مکمل path، size، modification time اور دستیاب logs محفوظ کریں؛ پھر فائل کو web-accessible directory سے quarantine کرکے hosting یا incident-response ٹیم سے تجزیہ کرائیں۔

اگر executable فائل مل جائے تو جانچ صرف اسی folder پر ختم نہیں ہونی چاہیے۔ متعلقہ وقت کے HTTP access logs، باقی uploads، غیر متوقع administrator accounts اور حالیہ plugin، theme یا configuration تبدیلیاں دیکھیں، کیونکہ ایک PHP فائل کا حذف ہونا یہ ثابت نہیں کرتا کہ حملہ آور نے کوئی دوسری تبدیلی نہیں کی۔ یہ وسیع جانچ مشکوک فائل ملنے کے بعد incident response ہے، ہر صاف site پر compromise کا مفروضہ نہیں۔

Execution block اور WAF کس ترتیب میں آئیں؟

ترتیب واضح رکھیں: پہلے vulnerable plugin patch کریں، پھر سابقہ exposure کی وجہ سے uploads کا audit کریں، اور اس کے بعد server controls مضبوط کریں۔ Web server پر wp-content/uploads اور اس کی ذیلی directories سے PHP یا دوسرے server-side scripts کا اجرا روکیں، جبکہ تصاویر اور جائز دستاویزات کی معمول کی ترسیل برقرار رہے۔

Apache، Nginx اور managed WordPress hosting میں اس control کی configuration مختلف ہو سکتی ہے۔ تبدیلی سے پہلے موجودہ configuration کا قابلِ بحالی backup لیں اور staging یا محدود validation سے تصدیق کریں کہ upload files serve ہو رہی ہیں مگر script کے طور پر execute نہیں ہوتیں۔

WAF کو form submission endpoints پر PHP extensions اور executable upload patterns روکنے کی اضافی تہہ سمجھیں۔ یہ patch کا بدل نہیں، کیونکہ filename encoding، multipart parsing اور hosting stack کے فرق سے ایک عمومی rule نامکمل ہو سکتا ہے؛ جائز forms اگر تصاویر یا دستاویزات وصول کرتے ہیں تو enforcement سے پہلے false positives بھی دیکھیں۔

• پہلی ترجیح: ہر Elementor Pro instance کا فعال version معلوم کرکے 4.2.2 یا بعد کے ورژن پر update۔
• اسی maintenance window میں: forms upload directory کا recursive audit اور مشکوک PHP فائل کی محفوظ investigation۔
• سرور کی مستقل حفاظت: تمام uploads directories میں script execution بند کرنا۔
• اضافی دفاع: form endpoints پر موزوں WAF filtering اور executable files کی تبدیلی پر نگرانی۔

دستیاب advisories خامی، متاثرہ version range اور patch threshold کی تصدیق کرتی ہیں، مگر کسی مخصوص پاکستانی WordPress site کے compromise کا فیصلہ عمومی bulletin سے نہیں ہو سکتا۔ حتمی نتیجہ اسی site کی version history، exposed forms، upload directories اور logs کے مقامی شواہد سے نکلے گا۔