موقع ووردبريس اتهكر؟ خطة الاستعادة الصحيحة خطوة بخطوة

فتحت موقعك لقيته بيحوّل الزوار لصفحات غريبة، أو جوجل حاطط عليه تحذير أحمر “موقع مخادع”؟ أول حاجة هتيجي في بالك إنك تنزّل إضافة حماية وتدوس “تنظيف”. استنى شوية، لأن الخطوة دي بالذات هي اللي بترجّع الاختراق تاني بعد أيام.

ووردبريس لتضيف له ميزة جديدة، مثل متجر أو نموذج تواصل أو تحسين للسيو، دون كتابة كود. اختر الإضافات الموثوقة المحدّثة، ولا…">الإضافة تزيل العرَض الظاهر، لكنها غالبًا لا تغلق الطريق الذي دخل منه المهاجم. وفي أغلب الحالات يكون هذا الطريق إضافة (Plugin) قديمة لم تُحدَّث، لا ضعفًا في ووردبريس نفسه.

أول ساعة: الترتيب أهم من السرعة

معظم الأخطاء في هذه المرحلة سببها الاستعجال. اتبع الخطوات بهذا الترتيب:

1. أوقف الموقع مؤقتًا. فعّل صفحة صيانة، أو احجب الموقع من لوحة الاستضافة أو من Cloudflare. هكذا تحمي زوارك وتوقف نشر الشيفرة الخبيثة أثناء عملك.
2. غيّر كل بيانات الدخول، لا كلمة مرور المدير فقط. يشمل ذلك لوحة الاستضافة (cPanel أو غيرها)، ومستخدم السيرفر.">قاعدة البيانات (Database)، وحسابات FTP ومفاتيح SSH، وأي مفاتيح API محفوظة في wp-config.php.
3. احفظ الأدلة قبل أي تعديل. خذ نسخة كاملة من الملفات وقاعدة البيانات كما هي الآن، ونزّل سجلات الوصول (Access Logs) لآخر 30 يومًا على الأقل، لأن كثيرًا من الاستضافات تحذفها بعد أيام قليلة.
4. لا تسترجع نسخة احتياطية ولا تحذف أي ملف بعد. الاسترجاع الآن يمحو الدليل، وغالبًا يعيد الثغرة نفسها.

ملاحظة للاستضافات المشتركة: لو كنت على استضافة مشتركة رخيصة، اطلب من الدعم الفني السجلات فورًا قبل أن تُدوَّر. بعض الشركات لا تحتفظ بها أكثر من أسبوع.

كيف دخل المهاجم؟ أربعة فحوصات تكشف الثغرة

التنظيف دون تشخيص هو السبب الأول لعودة الاختراق. هذه الفحوصات الأربعة تكشف السبب في معظم الحالات.

1. إصدارات الإضافات والقوالب

سجّل كل إضافة وقالب (Theme) مع رقم إصداره، وابحث هل صدر تحديث أمني لم تطبقه. انتبه خصوصًا للإضافات المدفوعة منتهية الترخيص، فهي تتوقف عن استقبال التحديثات وتظل مفعّلة كأن شيئًا لم يحدث.

وهذه مشكلة منتشرة جدًا عندنا مع النسخ “المنقولة” (Nulled) من الإضافات المدفوعة: لا تحديثات أمنية أبدًا، وأحيانًا تأتي ومعها الباب الخلفي جاهزًا.

لو عندك وصول SSH و WP-CLI، هذا الأمر يعرض الإضافات التي لها تحديث متاح:

wp plugin list --update=available --fields=name,version,update_version,status

2. سجلات الوصول حول بداية المشكلة

ابحث في السجلات عن طلبات POST إلى مسارات غير معتادة، وطلبات إلى ملفات لا يُفترض وجودها، ونشاط مكثف من اسم النطاق مثل arabcms.com إلى عنوان IP السيرفر الذي يستضيف الموقع. أي تعديل في سجلاته قد يحتاج ساعات…">DNS…">عنوان IP واحد قبيل ظهور الاختراق. غالبًا ستجد الإجابة هنا.

3. ملفات لا تنتمي للموقع

أي ملف PHP داخل مجلد wp-content/uploads إشارة قوية، لأن هذا المجلد لا يجب أن ينفذ أي شيفرة إطلاقًا. راجع كذلك الملفات بأسماء تبدو طبيعية لكنها غريبة، وأي تعديل حديث على wp-config.php أو .htaccess.

# PHP files inside uploads (there should be none)
find wp-content/uploads -name "*.php"

# PHP files modified in the last 14 days
find . -name "*.php" -mtime -14 -not -path "./wp-content/cache/*"

4. حسابات المدير والمهام المجدولة

المهاجم عادةً يضيف حساب مدير (Administrator) ليعود منه، ويسجّل مهمة مجدولة (WP-Cron) تعيد زرع الشيفرة بعد تنظيفها. لو الموقع يرجع يتهكر كل كام يوم بانتظام، فغالبًا فيه مهمة مجدولة محدش بص عليها.

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp cron event list

لماذا تفشل فكرة “رجّع نسخة احتياطية وخلاص”؟

استرجاع النسخة الاحتياطية (Backup) ينجح فقط إذا اجتمعت ثلاثة شروط: تعرف تاريخ الاختراق بدقة، ولديك نسخة أقدم منه، وأصلحت الثغرة التي دخل منها المهاجم. غياب أي شرط منها يعني الفشل.

قد تسترجع نسخة الأسبوع الماضي ويكون الموقع مخترقًا منذ أسبوعين لكنه كان هادئًا. وقد تسترجع دون تحديث الإضافة المصابة، فتعيد فتح الباب نفسه.

وفي المتاجر ومواقع العضويات، الاسترجاع يعني خسارة كل الطلبات والتسجيلات منذ تاريخ النسخة، وهذا غالبًا غير مقبول.

البديل الأضمن: إعادة البناء بدل الاسترجاع

بهذه الطريقة تضمن أن كل الشيفرة التنفيذية نظيفة، وهو ما لا يضمنه التنظيف ملفًا بملف.

تنظيف قاعدة البيانات

ماسحات الأمان تركز على الملفات، لذلك تبقى قاعدة البيانات المكان الذي تتسرب منه بقايا الاختراق.

• المحتوى: ابحث في جدول المقالات عن روابط مخفية، ووسوم <script> و <iframe> لم تضعها أنت.
• جدول الإعدادات wp_options: يُخزَّن فيه كثير من سكربتات التحويل، وفيه أيضًا المهام المجدولة داخل الخيار cron.
• الشيفرات المرمّزة: أي كتلة طويلة بترميز base64 أو نطاق (Domain) لا تعرفه تحتاج فحصًا وفك ترميز، لا افتراض أنها إضافة “بتعمل حاجة ذكية”.
• المستخدمون: راجع كل حساب بصلاحية مدير، وقارن تاريخ تسجيله بسجلاتك.

استعلام سريع لاكتشاف الحقن في المحتوى والإعدادات (غيّر البادئة wp_ لو موقعك يستخدم بادئة أخرى):

SELECT ID, post_title FROM wp_posts
WHERE post_content LIKE '%<script%' OR post_content LIKE '%<iframe%';

SELECT option_name FROM wp_options
WHERE option_value LIKE '%base64_decode%' OR option_value LIKE '%eval(%';

رفع تحذير جوجل واستعادة الترتيب

التنظيف وحده لا يزيل التحذير، لازم تطلب مراجعة بنفسك.

افتح تقرير مشاكل الأمان (Security Issues) في Google Search Console لتعرف ما الذي رصدته جوجل، ثم اطلب المراجعة بعد التأكد التام من نظافة الموقع، لأن رفض المراجعة يطيل المدة.

راجع كذلك قوائم الحظر الخاصة بالمتصفحات ومزودي البريد الإلكتروني، فلكل منها قائمته وإجراءات إزالته. ثم ابحث في نتائج البحث عن صفحات سبام فهرستها جوجل باسم موقعك، واطلب إزالتها.

لو الموقع فيه بيانات عملاء

إذا كان الموقع متجرًا أو يحفظ بيانات شخصية، فالمسألة ليست تقنية فقط. قوانين حماية البيانات في المنطقة، مثل قانون حماية البيانات الشخصية المصري رقم 151 لسنة 2020 ونظام حماية البيانات الشخصية في السعودية، تفرض التزامات عند حدوث تسريب.

لا تنتظر حتى تنتهي من التنظيف. استشر مختصًا قانونيًا مبكرًا لتعرف هل يلزمك إبلاغ جهة رسمية أو العملاء أنفسهم، وفي أي مهلة.

إزاي تمنع ده يتكرر؟

الاستعادة دون تحصين تعني فقط أنك أعدت ضبط العداد.

• انضباط التحديثات: أغلب الاختراقات تستغل ثغرة لها تحديث متاح بالفعل. حدّث بانتظام، واحذف أي إضافة غير مدعومة، وجدّد تراخيص الإضافات المدفوعة أو استبدلها.
• قلّل ما يمكن تنفيذه: امنع تشغيل PHP في مجلد uploads، وعطّل محرر الملفات من لوحة التحكم.
• المصادقة الثنائية (2FA): فعّلها لكل حسابات المدير، مع تحديد عدد محاولات تسجيل الدخول.
• حسابات قليلة وبأسماء أصحابها: لا حساب admin مشترك بين الفريق.
• نسخ احتياطي مُختبَر: احتفظ بعدة أجيال من النسخ، وجرّب استرجاع واحدة منها فعليًا. النسخة التي لم تجرب استرجاعها مجرد افتراض.

تعطيل محرر الملفات يتم بسطر واحد في wp-config.php:

define( 'DISALLOW_FILE_EDIT', true );

ومنع تشغيل PHP داخل uploads على خوادم Apache يتم بملف .htaccess داخل المجلد نفسه:

<FilesMatch ".php$">
    Require all denied
</FilesMatch>

في Elementor: المواقع المبنية على Elementor Pro و JetEngine تعتمد على إضافات مدفوعة كثيرة، فتأكد أن تراخيصها كلها سارية وأنها تُحدَّث تلقائيًا أو أسبوعيًا على الأقل. إضافة واحدة منتهية الترخيص تكفي لفتح الباب.

الأسئلة الشائعة

س: ما أول شيء أفعله لو اتهكر موقعي على ووردبريس؟
ج: أوقف الموقع مؤقتًا، وغيّر كل بيانات الدخول (الاستضافة وقاعدة البيانات و FTP وحسابات المدير)، واحفظ نسخة من الملفات وقاعدة البيانات والسجلات قبل أي تعديل أو استرجاع.

س: لماذا يعود الاختراق بعد تنظيف الموقع؟
ج: لأن التنظيف أزال الشيفرة الخبيثة ولم يُزل طريق الوصول. ابحث عن حسابات مدير غريبة، وملفات PHP في مجلد uploads، ومهام مجدولة تعيد زرع الشيفرة.

س: هل يكفي استرجاع نسخة احتياطية قديمة؟
ج: فقط إذا عرفت تاريخ الاختراق، وكانت النسخة أقدم منه، وأصلحت الثغرة. غير ذلك، إعادة البناء بنسخ نظيفة من النواة والإضافات أضمن.

س: كيف أزيل تحذير جوجل من موقعي؟
ج: نظّف الموقع بالكامل، ثم اطلب مراجعة من تقرير مشاكل الأمان في Google Search Console، وراجع قوائم حظر المتصفحات والبريد كل على حدة.

س: هل إضافات الحماية تكفي لمنع الاختراق؟
ج: تساعد، لكنها لا تغني عن تحديث الإضافات بانتظام، والمصادقة الثنائية، ومنع تنفيذ PHP في مجلد الرفع، ونسخ احتياطي مُختبَر.

الخلاصة

الاختراق في الغالب بيدخل من إضافة قديمة، والتنظيف السريع من غير ما تقفل الباب ده بيرجّعه تاني. ابدأ بالأدلة، اعرف الثغرة، ابنِ من نسخ نظيفة، وبعدها حصّن الموقع. ولو موقعك لسه سليم، خد قسم “إزاي تمنع ده يتكرر” وطبّقه النهارده قبل ما تحتاج الباقي.

مرجع المقال (بالإنجليزية): WordPress Hacked: Malware Removal and Recovery Guide
المقال ده مش ترجمة حرفية: متكيّف للقارئ العربي ومضاف عليه سياق ووردبريس وElementor وJetEngine.