📄 Description (English)
The weMail - Email Marketing, Lead Generation, Optin Forms, Email Newsletters, A/B Testing, and Automation plugin for WordPress is vulnerable to unauthorized form deletion in all versions up to, and including, 2.0.7. This is due to the `Forms::permission()` callback only validating the `X-WP-Nonce` header without checking user capabilities. Since the REST nonce is exposed to unauthenticated visitors via the `weMail` JavaScript object on pages with weMail forms, any unauthenticated user can permanently delete all weMail forms by extracting the nonce from the page source and sending a DELETE request to the forms endpoint.
🤖 AI Executive Summary
The weMail WordPress plugin (versions up to 2.0.7) contains a critical authorization bypass vulnerability allowing unauthenticated users to permanently delete all email marketing forms. The vulnerability stems from inadequate capability checks in the REST API endpoint, relying solely on nonce validation while exposing the nonce to unauthenticated visitors. This affects any WordPress site using weMail for email campaigns, lead generation, and marketing automation, with no patch currently available.
📄 Description (Arabic)
🤖 AI Intelligence Analysis Analyzed: May 11, 2026 01:01
🇸🇦 Saudi Arabia Impact Assessment
Saudi organizations heavily reliant on WordPress-based marketing platforms are at significant risk, particularly: (1) Banking sector (SAMA-regulated) using weMail for customer communications and lead generation; (2) E-commerce and retail companies conducting email marketing campaigns; (3) Government agencies and municipalities using WordPress for public engagement; (4) Telecommunications companies (STC, Mobily) managing customer newsletters; (5) Healthcare providers using email for patient communications. The permanent deletion of marketing forms could disrupt business continuity, compromise customer communication channels, and result in loss of critical lead generation data.
🏢 Affected Saudi Sectors
Banking and Financial Services
E-commerce and Retail
Government and Public Administration
Telecommunications
Healthcare
Education
Marketing and Advertising Agencies
Real Estate
🎯 MITRE ATT&CK Techniques
T1190 - Exploit Public-Facing Application (REST API exploitation)
T1566 - Phishing (email marketing forms targeted)
T1531 - Account Access Removal (form deletion as denial of service)
T1562 - Impair Defenses (nonce-based security bypass)
T1485 - Data Destruction (permanent form deletion)
T1491 - Defacement (disruption of marketing communications)
⚖️ Saudi Risk Score (AI)
7.8
/ 10.0
🔧 Remediation Steps (English)
IMMEDIATE ACTIONS:
1. Audit all WordPress installations running weMail plugin versions ≤2.0.7 across your organization
2. Disable the weMail plugin immediately if not actively required for critical operations
3. Review access logs for suspicious DELETE requests to /wp-json/wemail/v1/forms/ endpoints
4. Backup all weMail form configurations and associated data immediately
COMPENSATING CONTROLS (until patch available):
1. Implement Web Application Firewall (WAF) rules to block unauthenticated DELETE requests to weMail REST endpoints
2. Restrict REST API access to authenticated users only via .htaccess or nginx configuration
3. Implement IP whitelisting for REST API endpoints if possible
4. Disable REST API entirely if weMail forms are not actively used
5. Add HTTP authentication layer in front of WordPress installation
DETECTION RULES:
1. Monitor for DELETE requests to /wp-json/wemail/v1/forms/ from unauthenticated sessions
2. Alert on multiple failed form deletion attempts from same IP
3. Track changes to form count and configuration in weMail database tables
4. Monitor for extraction of nonce values from page source (unusual script activity)
PATCHING STRATEGY:
1. Monitor weMail GitHub repository and official channels for security patch release
2. Plan immediate upgrade to patched version once available
3. Test patch in staging environment before production deployment
4. Document all form deletions and restore from backups if needed
🔧 خطوات المعالجة (العربية)
الإجراءات الفورية:
1. تدقيق جميع تثبيتات WordPress التي تقوم بتشغيل مكون weMail الإضافي بإصدارات ≤2.0.7 عبر مؤسستك
2. تعطيل مكون weMail الإضافي فوراً إذا لم يكن مطلوباً بشكل نشط للعمليات الحرجة
3. مراجعة سجلات الوصول للطلبات المريبة DELETE إلى نقاط نهاية /wp-json/wemail/v1/forms/
4. عمل نسخة احتياطية من جميع تكوينات نماذج weMail والبيانات المرتبطة فوراً
الضوابط التعويضية (حتى توفر التصحيح):
1. تنفيذ قواعد جدار حماية تطبيقات الويب (WAF) لحظر طلبات DELETE غير المصرح لها إلى نقاط نهاية weMail REST
2. تقييد وصول REST API للمستخدمين المصرح لهم فقط عبر .htaccess أو تكوين nginx
3. تنفيذ القائمة البيضاء للعناوين IP لنقاط نهاية REST API إن أمكن
4. تعطيل REST API بالكامل إذا لم تكن نماذج weMail قيد الاستخدام النشط
5. إضافة طبقة مصادقة HTTP أمام تثبيت WordPress
قواعد الكشف:
1. مراقبة طلبات DELETE إلى /wp-json/wemail/v1/forms/ من جلسات غير مصرح لها
2. تنبيه عند محاولات حذف نماذج متعددة فاشلة من نفس عنوان IP
3. تتبع التغييرات في عدد النماذج والتكوين في جداول قاعدة بيانات weMail
4. مراقبة استخراج قيم nonce من مصدر الصفحة (نشاط البرنامج النصي غير المعتاد)
استراتيجية التصحيح:
1. مراقبة مستودع weMail GitHub والقنوات الرسمية لإصدار تصحيح الأمان
2. التخطيط للترقية الفورية إلى الإصدار المصحح بمجرد توفره
3. اختبار التصحيح في بيئة التدريج قبل نشره في الإنتاج
4. توثيق جميع حذف النماذج والاستعادة من النسخ الاحتياطية إذا لزم الأمر
📋 Regulatory Compliance Mapping
🟢 NCA ECC 2024
5.1.1 - Access Control Policy (inadequate authorization checks)
5.1.2 - User Registration and Access Rights Management (missing capability validation)
5.2.1 - User Access Management (unauthenticated access to sensitive operations)
6.1.1 - Information Security Incident Management (data loss from unauthorized deletion)
🔵 SAMA CSF
AC-2: Account Management (inadequate access controls)
AC-3: Access Enforcement (missing authorization enforcement)
AC-6: Least Privilege (excessive permissions for unauthenticated users)
SI-4: Information System Monitoring (detection of unauthorized API calls)
🟡 ISO 27001:2022
A.5.1.1 - Policies for information security (access control policy gaps)
A.6.1.2 - Information security roles and responsibilities (authorization failures)
A.8.1.1 - User endpoint devices (API security controls)
A.9.2.1 - User registration and access rights (capability validation missing)
A.9.4.3 - Password management (nonce exposure to unauthenticated users)
🟣 PCI DSS v4.0.1
6.5.1 - Injection flaws (API authorization bypass)
7.1 - Limit access to system components by business need to know
7.2 - Restrict access to cardholder data by business need to know (if processing payments)
🔗 References & Sources 5
🔗
🔗
🔗
🔗
🔗
https://plugins.trac.wordpress.org/browser/wemail/tags/2.0.6/includes/FrontEnd/Scripts....
security@wordfence.com
https://plugins.trac.wordpress.org/browser/wemail/tags/2.0.6/includes/Rest/Forms.php#L124
security@wordfence.com
https://plugins.trac.wordpress.org/browser/wemail/tags/2.0.6/includes/Rest/Forms.php#L222
security@wordfence.com
https://plugins.trac.wordpress.org/changeset?sfp_email=&sfph_mail=&reponame=&new=344240...
security@wordfence.com
https://www.wordfence.com/threat-intel/vulnerabilities/id/16dd90c3-3962-4c8e-993f-b6824...
security@wordfence.com