موقع ووردبريس مخترق: تصرف بسرعة في 10 خطوات

إذا تم تحويل صفحتك الرئيسية فجأة إلى موقع كازينو، أو إذا رأيت حسابات إدارية لم تقم بإنشائها مطلقًا، فأنت لا تتعامل مع خطأ برمجي. WordPressأنت تواجه حلاً وسطاً، وكل دقيقة تقضيها في "النقر في كل مكان" يمكن أن تزيد الضرر سوءاً.

المتطلبات الأساسية الوصول إلى خادم استضافة موقعك (عبر بروتوكول نقل الملفات FTP/SFTP أو مدير الملفات)، والوصول إلى قاعدة البيانات (عبر phpMyAdmin أو ما يعادله)، ويفضل الوصول عبر SSH/WP-CLI، ونسخة احتياطية حديثة (حتى لو كانت مُعرّضة للإصابة). جميع العناصر التالية مُستهدفة WordPress 6.9.4 (أبريل 2026) و PHP 8.1 +لا تقم بتعديل ملفات ووردبريس الأساسية (الملفات الموجودة في wp-includes / wp-admin) لـ "الإصلاح": نقوم بإعادة التثبيت بشكل نظيف.

التهديد

إن موقع ووردبريس المخترق ليس مجرد "موقع يعرض رسائل غير مرغوب فيها". يمكن للمهاجم أن:

جلسات السرقة (ملفات تعريف الارتباط) وإعادة الاتصال كمسؤول حتى إذا قمت بتغيير كلمة المرور.
حقن البريد العشوائي لتحسين محركات البحث (الصفحات الوهمية، والروابط المخفية) مما يضر بظهورك وسمعتك.
تركيب باب خلفي (من الباب الخلفي) للعودة بعد التنظيف.
استخراج البيانات (البريد الإلكتروني، عنوان IP، النماذج، طلبات WooCommerce).
استخدم خادمك لإرسال رسائل غير مرغوب فيها أو مهاجمة مواقع أخرى (وإدراجك في القائمة السوداء).

أكثر ما أراه في عملية استكشاف الأخطاء وإصلاحها هو أن ووردبريس ليس "المشكلة"، بل هو مزيج من العوامل. إضافة ضعيفة + بيانات اعتماد غير دقيقة + نقص التحديثات + صلاحيات متساهلة للغايةوالنقطة التي تُفاجئ المبتدئين: يمكن اختراق موقع إلكتروني دون ظهور أي أعراض واضحة.عمليات إعادة التوجيه والتشويه هي أحيانًا الخطوة الأخيرة، وليست الأولى.

باختصار، المخاطرة تكمن في أن ووردبريس منصة واسعة الانتشار، وبالتالي فهي هدف رئيسي للهجمات. تاريخيًا، تنجم معظم اختراقات ووردبريس عن ثغرات في الإضافات/القوالب أو كلمات المرور المعاد استخدامها/المسروقة، وليس عن ثغرة في نواة ووردبريس. لذا، تبقى الاستراتيجية الأمثل هي: تقليل مساحة الهجوم et اجعل الوصول إلى صلاحيات المسؤول صعب التجاوز.

موارد مفيدة لـ WordPress (عادة جيدة: اقرأ الصفحات الرسمية عندما تكون لديك أي شكوك):

مخطط التشخيص السريع

عرض	السبب المحتمل	التحقق	الحلول
إعادة التوجيه إلى موقع طرف ثالث	تم حقن جافا سكريبت، وتم اختراق الملحق `.htaccess` تعديل	اطلع على شفرة المصدر، وتحقق منها. `.htaccess`الإضافات الحديثة	تنظيف الملفات + إعادة تثبيت النظام الأساسي + مسح ذاكرة التخزين المؤقت/شبكة توصيل المحتوى
حسابات إدارية جديدة غير معروفة	بيانات اعتماد مسروقة، نقطة نهاية إدارية غير محمية	قائمة المستخدمين، سجلات الاتصال	حذف الحسابات، وإعادة تعيين كلمات المرور والجلسات بالقوة
صفحات "البريد العشوائي" المفهرسة على جوجل	البريد العشوائي لتحسين محركات البحث عبر المحتوى المخفي أو التوجيه الديناميكي	وحدة تحكم بحث جوجل، بحث `site:votredomaine`	تنظيف قاعدة البيانات + حذف الصفحات + طلبات المراجعة
تنبيهات المتصفح بشأن "البرامج الضارة"	البرامج النصية الخبيثة، والإطارات المضمنة	افحص الملفات، وقارن بين مكونات ووردبريس الأساسية	استبدل الملفات، وتحقق من عمليات التحميل، وعزز أمان العناوين.
خادم بطيء / استهلاك عالٍ لوحدة المعالجة المركزية	مُعدِّن العملات الرقمية، مُرسِل الرسائل المزعجة، طلبات غير طبيعية	سجلات الخادم، العمليات، جدولة مهام ووردبريس	عزل الموقع، تنظيفه، تغيير المفاتيح، إلغاء الوصول

ملخص سريع

عزل : ضع الموقع في وضع الصيانة، واحظر الوصول المشبوه، واحفظ نسخة للتحليل.
إلغاء قم بتغيير جميع كلمات المرور (ووردبريس، FTP/SFTP، قاعدة البيانات، الاستضافة) و فصل قسري من بين جميع الجلسات.
أعد تثبيت النظام بشكل صحيح قم بتثبيت WordPress 6.9.4 (الأساسي) واستبدل القوالب/الإضافات من مصادر موثوقة.
نظيف ابحث عن الثغرات الأمنية (غالباً في wp-content/uploads, mu-plugins, wp-config.phpثم نظف القاعدة.
هاردن : الأذونات، DISALLOW_FILE_EDITرؤوس الرسائل، وجدار حماية تطبيقات الويب/شبكة توصيل المحتوى، والمصادقة الثنائية، والتحديثات التلقائية.
مراقب : السجلات، سلامة الملفات، التنبيهات، وحدة تحكم البحث، عمليات المسح المنتظمة.

الكود المعرض للثغرات الأمنية - ما لا يجب فعله

مثال كلاسيكي: "مقتطف صغير" تم العثور عليه في منتدى، ولصقه في functions.php أو إضافة مقتطفات برمجية، تُضيف نقطة نهاية AJAX. الهدف مشروع (مثلاً، "تحديث خيار من واجهة المستخدم")، لكن طريقة التنفيذ تُسهّل الاستحواذ.

تذكير بالمفردات:

Un صنارة صيد هو خطاف في ووردبريس. هناك الإجراءات (رمز التشغيل) و مرشحات البحث (تعديل قيمة).
AJAX في ووردبريس، غالباً ما يمر الأمر بـ admin-ajax.php وخطافات wp_ajax_* (متصل) / wp_ajax_nopriv_* (غير متصل).
Un السفير البابوي هو رمز مضاد لهجمات CSRF (الحماية من الإرسال القسري). إنه ليس "كلمة مرور"، ولكنه حماية أساسية.

مثال خطير عن قصد

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

<?php
/**
 * EXEMPLE VULNÉRABLE — NE PAS UTILISER
 * Collé dans functions.php : mauvaise idée + aucune protection.
 */

add_action('wp_ajax_nopriv_bpcab_update_option', 'bpcab_update_option_vulnerable');
add_action('wp_ajax_bpcab_update_option', 'bpcab_update_option_vulnerable');

function bpcab_update_option_vulnerable() {
	// ❌ Pas de nonce : vulnérable CSRF
	// ❌ Pas de contrôle de droits : n'importe qui peut appeler l'action
	// ❌ Entrées non validées : injection de valeurs inattendues

	$option_name  = $_POST['option_name'] ?? '';
	$option_value = $_POST['option_value'] ?? '';

	update_option($option_name, $option_value);

	wp_send_json_success(array(
		'message' => 'Option mise à jour',
	));
}

كيف يعمل الهجوم (بدون "وصفة استغلال")

إليكم ما يحدث خلف الكواليس:

بما أن الحدث متاح في nopriv, زائر غير مسجل دخوله يمكنني الاتصال به.
بدون السفير البابوييمكن للمهاجم أن يبدأ الإجراء من موقع آخر (CSRF) أو بشكل مباشر.
بدون فحص القدرات (التحكم في الأذونات)، لا يقوم ووردبريس بحظر العملية.
اعتمادًا على الخيار الذي تم تعديله، يمكن للمهاجم تعطيل الموقع، أو حقن الإعدادات، أو إعداد خطوة تالية (على سبيل المثال، تفعيل التسجيل + دور المسؤول عبر ثغرة أخرى، أو تعديل عناوين URL، وما إلى ذلك).

كثيراً ما رأيت اختلافات أكثر خطورة: كتابة الملفات عبر file_put_contents()تنفيذ أوامر النظام، أو "استيراد" المحتوى دون التحقق من صحته. في أغلب الأحيان، يتم نسخ المقتطف إلى المكان الخطأ، أو يُساء فهمه، ويُترك في بيئة الإنتاج دون تدقيق.

الكود الآمن - التنفيذ الصحيح

نستخدم نفس الفكرة (تحديث إعداد ما)، لكننا نقوم بذلك مثل كود ووردبريس نظيف 6.9.4+: قدرات, السفير البابوي, التحقق الصارمولا nopriv إذا لم يكن ذلك ضرورياً.

أين يجب أن ألصق هذا الكود؟ الخيار الأكثر أمانًا: إضافة صغيرة على (موصى به) أو أ مو البرنامج المساعد (إضافة "إلزامية"). تجنب functions.php إذا كنت مبتدئًا: يمكن أن يتسبب خطأ في بناء الجملة (نسيان الفاصلة المنقوطة) في عرض الموقع لشاشة فارغة.

الخيار أ (موصى به): mu-plugin

أنشئ الملف: wp-content/mu-plugins/bpcab-security-safe-ajax.php (أنشئ المجلد إذا لم يكن موجودًا). يتم تحميل إضافات mu تلقائيًا.

<?php
/**
 * Plugin Name: BPCAB - AJAX sécurisé (exemple)
 * Description: Exemple pédagogique : mise à jour d'une option via AJAX de façon sécurisée.
 * Version: 1.0.0
 * Requires at least: 6.9
 * Requires PHP: 8.1
 */

if ( ! defined('ABSPATH') ) {
	exit; // Sécurité : empêche l'accès direct au fichier
}

add_action('wp_ajax_bpcab_update_site_setting', 'bpcab_update_site_setting_secure');

function bpcab_update_site_setting_secure() {
	// 1) Vérifie le nonce (anti-CSRF)
	// Le champ attendu côté JS : security: '...'
	check_ajax_referer('bpcab_site_setting', 'security');

	// 2) Vérifie les droits : ici, seuls les admins (capacité "manage_options")
	if ( ! current_user_can('manage_options') ) {
		wp_send_json_error(array(
			'message' => 'Droits insuffisants.',
		), 403);
	}

	// 3) Whitelist stricte : on n'autorise que certaines options
	$allowed_options = array(
		'bpcab_banner_text',
	);

	$option_name = isset($_POST['option_name']) ? sanitize_key(wp_unslash($_POST['option_name'])) : '';
	if ( ! in_array($option_name, $allowed_options, true) ) {
		wp_send_json_error(array(
			'message' => 'Option non autorisée.',
		), 400);
	}

	// 4) Validation / sanitation de la valeur
	$option_value = isset($_POST['option_value']) ? wp_unslash($_POST['option_value']) : '';
	$option_value = sanitize_text_field($option_value);

	update_option($option_name, $option_value, true);

	wp_send_json_success(array(
		'message' => 'Option mise à jour en toute sécurité.',
	));
}

لماذا هو أكثر أماناً (شرح بسيط ثم شرح تقني)

الاشارات أنت تشترط أن يكون الطلب صادرًا من مسؤول مسجل الدخول وأن يحتوي على رمز مميز صالح. كما أنك تقيد ما يمكن تعديله. ونتيجة لذلك، حتى لو رأى أحدهم عنوان URL الخاص بطلب AJAX، فلن يتمكن من استخدامه.

تقنية :

check_ajax_referer() يحظر الطلبات التي لا تحتوي على قيمة عشوائية صالحة. المرجع: developer.wordpress.org.
current_user_can('manage_options') يتطلب ذلك إمكانية استخدام ووردبريس. المرجع: developer.wordpress.org.
sanitize_key(), sanitize_text_field() et wp_unslash() تجنب بعض الإدخالات غير المتوقعة. المرجع: تعقيم البيانات.
La القائمة البيضاء يمنع هذا تحويل نقطة النهاية الخاصة بك إلى "خيار تحديث عام". إنه تفصيل صغير، ولكنه غالبًا ما يكون نقطة ضعف أمنية.

منشئو صفحات الملاحظات (Divi 5، Elementor، Avada)

لا تمنع Divi و Elementor و Avada حدوث ذلك نوع الثغرة الأمنية: يكمن الخطر في كود PHP الذي يعالج الطلب. إذا كنت تضيف نماذج عبر أداة إنشاء، فضع هذا في اعتبارك:

جانب الواجهة الأمامية: nonce + طلب مصادق عليه في حالة الإجراءات الحساسة؛
جانب الخادم: الأذونات + القائمة البيضاء + التنظيف + التحقق؛
لا تكشف أبدًا عن إجراءات "المسؤول" في nopriv.

تكوين الخادم

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

ملف wp-config.php: الحد الأدنى من التحسينات الأمنية مفيد

يحرر wp-config.php (في المجلد الرئيسي). قم بعمل نسخة احتياطية من الملف أولاً. أضف أو حدد:

<?php
// Empêche l'édition de fichiers via l'admin (cible fréquente après compromission)
define('DISALLOW_FILE_EDIT', true);

// Optionnel : empêche aussi l'installation/mise à jour via l'admin (à activer si vous gérez via Git/CI)
define('DISALLOW_FILE_MODS', false);

// Force SSL sur l'admin si votre site est en HTTPS (recommandé)
define('FORCE_SSL_ADMIN', true);

// Limite la fenêtre d'autosave/ révisions (pas sécurité pure, mais réduit bruit en DB)
define('WP_POST_REVISIONS', 20);

نقطة التركيز إذا كنت تستخدم خادم وكيل/شبكة توصيل محتوى (CDN)، FORCE_SSL_ADMIN قد يتسبب ذلك في حدوث حلقات تكرارية إذا لم يقم مزود الاستضافة بالنقل بشكل صحيح X-Forwarded-Protoفي هذه الحالة، قم بتصحيح إعدادات الوكيل من جانب الخادم بدلاً من تعطيل SSL.

ملف .htaccess (أباتشي): منع تنفيذ PHP في عمليات التحميل

تختبئ العديد من برامج ووردبريس الخبيثة في wp-content/uploadsفي موقع ويب عادي، ليس لديك لا يوجد سبب لتشغيل PHP في هذا المجلد.

إنشاء (أو تعديل) wp-content/uploads/.htaccess :

# Bloque l'exécution de PHP dans uploads (Apache)
<FilesMatch ".php$">
  Require all denied
</FilesMatch>

إذا كان مزود خدمة الاستضافة الخاص بك يستخدم Nginx، فسيتم تنفيذ ما يُماثل ذلك في إعدادات الخادم (تواصل مع الدعم الفني). لا تحاول إنشاء توجيه Nginx في ملف WordPress: لن ينجح ذلك.

رؤوس HTTP: تقليل تأثير هجمات XSS / اختطاف النقرات

إذا كان بإمكانك ضبط رؤوس الرسائل (عبر مزود الاستضافة الخاص بك، أو إضافة أمان، أو المضيف الافتراضي الخاص بك)، فإن هذه الثلاثة تمثل نقطة انطلاق جيدة:

# Exemples de headers (à adapter à votre serveur/CDN)
Content-Security-Policy: frame-ancestors 'self';
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

واحد حقيقي CSP النسخة الكاملة أكثر تعقيدًا (خاصةً مع أدوات البناء التي تُضمّن أكواد جافا سكريبت/سي إس إس المضمنة). ابدأ بـ frame-ancestors للحد من عمليات اختطاف النقرات، فهي عموماً ليست مدمرة للغاية.

أذونات الملفات: الحد الأدنى الواقعي

الملفات: 755
Fichiers: 644
wp-config.php : غالباً 640 ou 600 حسب نوع الإقامة

تجنب رد الفعل المتسرع المتمثل في "سأضبط كل شيء على 777 لجعله يعمل". لقد رأيت مواقع "تم إصلاحها" بهذه الطريقة... ثم تم اختراقها مرة أخرى في غضون ساعة.

تحقق مما إذا كان موقعك عرضة للاختراق

الهدف: العثور على حيث دخل المهاجم، و si لا يزال هناك باب خلفي. بدونه، ستكون عملية التنظيف بلا جدوى.

باستخدام WP-CLI: الجرد والإشارات الضعيفة

يُعدّ WP-CLI أداة سطر الأوامر الأكثر فائدة للتشخيص السريع. المرجع: أوامر WP-CLI.

# Version WordPress (vérifiez que vous êtes bien en 6.9.4+)
wp core version

# Liste des plugins + statut
wp plugin list

# Liste des thèmes
wp theme list

# Liste des utilisateurs admins
wp user list --role=administrator --fields=ID,user_login,user_email,registered

# Vérifie l'intégrité des fichiers core (détecte les fichiers modifiés)
wp core verify-checksums

ترجمة :

Si wp core verify-checksums إعادة تثبيت الملفات المعدلة: نعتبر أن النظام الأساسي قد تعرض للاختراق. سنقوم بإعادة تثبيته.
إذا رأيت مسؤولين غير معروفين: احذفهم بعد تأمين الوصول (وإلا فسيعودون).

البحث عن الملفات المشبوهة (دون تعطيل الموقع)

على خادم لينكس، تُعد هذه الأوامر مفيدة. إنها ليست "سحرية"، لكنها توفر الوقت.

# Cherche du PHP dans uploads (souvent anormal)
find wp-content/uploads -type f -name "*.php" -print

# Cherche des fonctions typiques d'obfuscation (signal, pas preuve)
grep -R --line-number "base64_decode|gzinflate|str_rot13|eval(" wp-content | head -n 50

لا تحذف "كل ما يحتوي على base64_decode" بشكل عشوائي: فقد تستخدمه بعض الإضافات المشروعة. ما تبحث عنه هو مزيج من: ملف في موقع خاطئ + رمز غير قابل للقراءة + تواريخ حديثة + اسم غريب.

التحقق من السجلات: خطوة أساسية

سجلات الوصول : ارتفاعات مفاجئة في عمليات البحث على /wp-login.php, /xmlrpc.php (في حال تفعيلها) /wp-json/, /admin-ajax.php.
سجلات الخطأ : أخطاء PHP متكررة (غالباً ما تكون ناجمة عن برامج ضارة سيئة البرمجة)، تحذيرات في ملفات غير معروفة.
سجلات WAF/CDN (Cloudflare، إلخ): الكتل، عناوين IP، البلدان، الأنماط.

ما أبحث عنه أولاً هو: تسلسل "تحميل ملف" متبوعًا باستدعاء مباشر لهذا الملف، أو دفعة على نقطة نهاية محددة لمكون إضافي.

استعلامات SQL التشخيصية (استخدمها بحذر)

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

-- Utilisateurs admins
SELECT u.ID, u.user_login, u.user_email
FROM wp_users u
JOIN wp_usermeta m ON m.user_id = u.ID
WHERE m.meta_key = 'wp_capabilities'
AND m.meta_value LIKE '%administrator%';

-- Options chargées automatiquement (autoloader) : cible fréquente d'injection
SELECT option_name, LENGTH(option_value) AS len
FROM wp_options
WHERE autoload = 'yes'
ORDER BY len DESC
LIMIT 30;

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

أخطاء شائعة في مجال الأمن

خطأ	صعب	الحلول
قم بالتنظيف "يدويًا" عن طريق حذف ملفين أو ثلاثة ملفات عشوائيًا	الباب الخلفي المتبقي، إعادة اختراق سريعة	إعادة تثبيت النظام الأساسي + استبدال الإضافات/القوالب + تدقيق التحميلات + قاعدة البيانات
انسخ مقتطفًا إلى `functions.php` بدون فهم	RCE/CSRF/رفع الامتيازات	إضافة مخصصة + قيمة عشوائية + إمكانيات + تحقق صارم
نسيان مسح ذاكرة التخزين المؤقت (المكون الإضافي، الخادم، شبكة توصيل المحتوى)	أنت تعتقد أن الاختراق مستمر، أو أنك لا ترى عودة إلى الوضع الطبيعي.	قم بمسح جميع الملفات المؤقتة بعد التنظيف
اختبر مباشرة في بيئة الإنتاج بدون نسخ احتياطي	فقدان البيانات، عدم التوفر	الاستنساخ/التجهيز، اللقطة، خطة التراجع
استخدام خطاف غير مناسب (إجراء مقابل فلتر)، أولوية خاطئة	لم يتم إجراء الفحوصات الأمنية	تحقق من الخطاف والأولوية، واختبر باستخدام السجلات.
انسَ أمر الأرقام العشوائية في النماذج/AJAX	CSRF (إجراءات إدارية يتم تنفيذها دون علمك)	`wp_nonce_field()` / `check_admin_referer()` / `check_ajax_referer()`
الأذونات مفتوحة جدًا (777)، مشاركة FTP	كتابة البرامج الضارة، التعديل الصامت	644/755، حسابات منفصلة، SFTP، مفاتيح SSH
إصدار PHP قديم جدًا	توافق منخفض، سطح هجوم أكبر	PHP 8.1+ (ويُفضل استخدام إصدار أحدث إذا كان مزود خدمة الاستضافة الخاص بك يوفره)
اتباع برنامج تعليمي قديم (قبل الإصدار 6.x) دون تعديله	شفرة معيبة، حماية زائفة	المراجع: developer.wordpress.org + اختبارات على ووردبريس 6.9.4
لم يتم إعادة إنشاء الروابط الدائمة بعد الاستعادة	404، سلوك غريب، إنذارات كاذبة	الإعدادات > الروابط الدائمة > حفظ

قائمة التحقق من التصلب

تحديثات قم بتحديث ووردبريس، والإضافات، والقوالب (قم بإزالة ما هو غير نشط).
حسابات : لا يوجد مسؤولو "احتياطيون" منسيون، كلمات مرور فريدة، وتفعيل المصادقة الثنائية إن أمكن.
الجلسات : فرض قطع الاتصال العالمي بعد وقوع حادث.
ملفات لا يوجد PHP في uploadsلا توجد ملفات غير معروفة في mu-plugins.
الفسفور الابيض بين config.php ل : DISALLOW_FILE_EDIT تم تفعيلها، وتم إعادة إنشاء مفاتيح الأمان.
أذونات : 644/755، رقم 777.
الوصول إلى الخادم SFTP/SSH، لا يوجد FTP واضح، حسابات منفصلة.
حماية تسجيل الدخول : تحديد عدد المحاولات، واختبار CAPTCHA إذا كان ذلك مناسبًا، وجدار حماية تطبيقات الويب/شبكة توصيل المحتوى.
النسخ الاحتياطي : النسخ الاحتياطي التلقائي + اختبار الاستعادة (وإلا فلن يتم احتسابه).
مراقبة تنبيهات بشأن إنشاء المسؤول، وتعديل الملفات، ووقت التشغيل.

ماذا لو كان الموقع مخترقاً بالفعل؟

نحن بصدد الانتقال إلى وضع التعامل مع الحوادث. يكمن الخطأ الشائع في البدء بـ"إزالة البرامج الضارة" دون... قطع الوصولفي تجربتي، الأمر أشبه بمسح تسرب الماء دون إغلاق الصنبور.

الخطوة الأولى - العزل دون إتلاف الأدلة

تفعيل صفحة الصيانة (عبر مزود خدمة الاستضافة، أو إضافة موثوقة). تجنب السماح للموقع بعرض برامج ضارة للزوار.
قم بعمل نسخة قم بتنزيل الملفات وقاعدة البيانات (ملف مضغوط + تصدير SQL). احتفظ بهذه النسخة خارج الخادم. تُستخدم هذه النسخة لتحليل المدخلات وإثبات ما حدث.
انتبه للوقت والأعراض (إعادة التوجيه، الحسابات، الملفات المعدلة). وهذا يساعد على الربط مع السجلات.

الخطوة الثانية - إلغاء جميع الصلاحيات (ليس فقط ووردبريس)

قم بتغيير كلمة مرور المضيف (اللوحة)، ثم قم بتمكين المصادقة الثنائية إذا كانت متاحة.
قم بتغيير كلمات المرور الخاصة بك SFTP/SSH (أو إعادة إنشاء مفاتيح SSH). احذف الحسابات غير الضرورية.
قم بتغيير كلمة المرور الخاصة بك من قاعدة البيانات وتحديث wp-config.php.
قم بتغيير جميع كلمات المرور WordPress (المسؤولون أولاً).

عندها فقط يجب عليك فرض تسجيل خروج عام لجلسات ووردبريس. أسهل طريقة من جانب لوحة التحكم هي إعادة تعيين كلمات المرور. إذا كنت تستخدم WP-CLI:

# Exemple : force un nouveau mot de passe (à faire pour chaque admin)
wp user update VOTRE_ID --user_pass="$(wp eval 'echo wp_generate_password(32, true, true);')"

VOUS pouvez aussi تجديد مفاتيح الأمن في wp-config.phpيؤدي هذا إلى إبطال ملفات تعريف الارتباط الخاصة بالجلسة. استخدم خدمة ووردبريس الرسمية لإنشاء المفاتيح الجديدة. أملاح المفاتيح السرية لموقع WordPress.org.

الخطوة 3 - تحديد نقطة الدخول (المكون الإضافي، القالب، بيانات الاعتماد)

قبل إعادة تشغيله، ابحث عن السبب المحتمل:

تم تثبيت أو تحديث الملحق/السمة مؤخرًا؛
المكون الإضافي "المُلغى" (المُخترق): هذا سبب رئيسي للاختراق؛
حساب مدير بكلمة مرور معاد استخدامها؛
يتم مشاركة الوصول إلى بروتوكول نقل الملفات (FTP) مع وكالة/مقدم خدمة؛
خادم مشترك ذو صلاحيات واسعة للغاية.

إذا لم تتمكن من تحديد نقطة الدخول، فافترض أنه يمكن تكرارها وقم بتشديد الأمان (جدار حماية تطبيقات الويب + المصادقة الثنائية + تقييد وصول المسؤول).

الخطوة 4 - إعادة تثبيت نواة ووردبريس بشكل نظيف (ووردبريس 6.9.4)

قم بتنزيل ووردبريس من المصدر الرسمي: wordpress.org/download.
يستبدل تماما wp-admin et wp-includes من خلال تنظيف الملفات.
استبدل أيضًا ملفات PHP في الدليل الجذر (index.php, wp-login.phpإلخ.) بواسطة نسخ نظيفة.
لا تستبدل wp-config.php et wp-content في الوقت الحالي (فهذا هو المكان الذي غالباً ما تختبئ فيه العدوى).

مع WP-CLI (إن كان متوفراً)، يصبح الأمر أكثر سلاسة:

# Réinstalle les fichiers core (sans toucher wp-content)
wp core download --force

الخطوة 5 - تنظيف مجلد wp-content (القوالب، الإضافات، الملفات المرفوعة)

الاستراتيجية الأكثر موثوقية: استبدل بدلاً من "تنظيف" كل إضافة على حدة.

الإضافات قم بإزالة جميع الإضافات، ثم أعد تثبيتها من wordpress.org/plugins أو مصادر الناشر. نعم، إنه طويل. نعم، هذا ما ينجح.
موضوع وأنا كذلك. إذا كنت تستخدم Divi 5 أو Elementor أو Avada: أعد التنزيل من حسابك الرسمي (Elegant Themes / Elementor / ThemeFusion). تجنب ملفات ZIP المشتركة.
تحميل ابحث عن ملفات PHP، والملفات التي تم تعديلها مؤخرًا، وأسماء الملفات غير المألوفة. قم بتطبيق حظر PHP في قسم التحميلات (الخادم).

خطأ شائع: إزالة إضافة مخترقة مع ترك إضافة أخرى mu-plugin خبيث. تحقق. wp-content/mu-plugins et wp-content/plugins لأي ملف لم تقم بتثبيته.

الخطوة 6 - تنظيف قاعدة البيانات (دون إتلاف أي شيء)

أقوم بالخطوات التالية:

مرور 1 : حسابات المستخدمين، الخيارات، المحتوى المرئي (المقالات/الصفحات).
مرور 2 : عمليات حقن سرية (خيارات التحميل التلقائي، والأدوات، والرموز المختصرة، وHTML المخفي).

فحوصات ملموسة:

إزالة المسؤولين غير المعروفين؛
تحقق من رسائل البريد الإلكتروني الخاصة بالمسؤولين؛
فحص wp_options (قيم ضخمة، نصوص برمجية)؛
تحقق من الأدوات والقوائم (حقن الروابط).

لا تستخدم استعلام SQL لحذف جماعي تجده في المنتديات. لقد استعدتُ مواقع بالفعل بعد أن قام أحدهم بحذف خيارات أساسية، مما أدى إلى تعطيل المحرر والروابط الدائمة و WooCommerce.

الخطوة 7 - المسح الضوئي، ثم التحميل تدريجياً عبر الإنترنت

قم بتفعيل إضافة أمان موثوقة (ماسح ضوئي + جدار حماية للتطبيقات) إذا سمحت ميزانيتك/مجموعة البرامج الخاصة بك بذلك.
أعد الموقع إلى الإنترنت مع المراقبة (السجلات + التنبيهات).
مراقبة لمدة 48-72 ساعة: عمليات إنشاء المستخدمين، وتعديلات الملفات، وعمليات إعادة التوجيه الجديدة.

الخطوة 8 - مسح ذاكرة التخزين المؤقت وشبكة توصيل المحتوى (وإلا ستعتقد أنها تعرضت للاختراق مرة أخرى)

إضافة مسح ذاكرة التخزين المؤقت (إذا كنت تستخدم ذاكرة تخزين مؤقت).
مسح ذاكرة التخزين المؤقت للخادم (إذا كان مزود خدمة الاستضافة لديه واحد).
تنظيف شبكة توصيل المحتوى (Cloudflare، إلخ).
قم أيضًا بمسح ذاكرة التخزين المؤقت للمتصفح للتحقق.

الخطوة 9 - ما بعد الحادثة: تحسين محركات البحث والسمعة

Google Search Console: تحقق من "مشكلات الأمان" والفهرسة.
إذا تمت فهرسة البريد العشوائي: قم بإزالة الصفحات، وأعد 404/410، واطلب إعادة الفحص إذا لزم الأمر.
إذا كانت لديك قائمة بريد إلكتروني: قم بإخطارهم إذا كان من المحتمل تسريب أي بيانات (حسب السياق القانوني الخاص بك).

نصائح الصيانة والتوافق

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

قواعد بسيطة تصمد أمام اختبار الزمن

حذف الإضافات/القوالب غير المستخدمة (تعطيلها لا يكفي).
قلل عدد المسؤولين : مدير النظام = سلطة كاملة.
2FA على حسابات المسؤولين، خاصة إذا كنت تستخدم Elementor/Divi/Avada مع إمكانية الوصول المشترك.
التدريج : اختبار التحديثات المهمة خارج بيئة الإنتاج.
تم اختبار النسخ الاحتياطية : النسخة الاحتياطية غير المختبرة هي مجرد افتراض.

توافق أدوات البناء (Divi 5، Elementor، Avada): نقاط أمنية يجب مراعاتها

القوالب المستوردة لا تستورد "حزمًا" من مصادر غير معروفة. حتى لو لم تكن بلغة PHP، فقد تقوم بحقن أكواد جافا سكريبت أو روابط مزعجة.
الأدوات/النماذج يجب أن يحتوي كل شيء يرسل البيانات على قيمة عشوائية (nonce) بالإضافة إلى التحقق من الصحة على جانب الخادم.
هاملت قد يُخفي بطء الموقع الإلكتروني أحيانًا ثغرة أمنية (مثل استخدام مهام cron المُرهِقة أو حقن البرامج الضارة). راقب أوقات الاستجابة.

كلمة حول PHP 8.1+

التزم بإصدار PHP مدعوم من مزود خدمة الاستضافة (يوصى هنا بالإصدار 8.1 كحد أدنى). المرجع: إصدارات PHP المدعومةيؤدي استخدام إصدار قديم إلى حرمانك من التحديثات ويزيد من تعقيد التوافق مع الإضافات الحديثة.

الموارد

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

هل أحتاج إلى استعادة البيانات من نسخة احتياطية؟

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

هل تغيير كلمة مرور ووردبريس كافٍ؟

لا. إذا تم اختراق الوصول إلى الخادم (SFTP/SSH) أو مزود خدمة الاستضافة، فبإمكان المهاجم إعادة حقن الملفات. وإذا لم تتغير مفاتيح SALT الخاصة بك، فقد تظل الجلسات سارية.

لماذا إعادة تثبيت نواة ووردبريس بدلاً من "التنظيف"؟

لأنه أسرع وأكثر موثوقية. استبدل wp-admin et wp-includes تقضي النسخ النظيفة على فئة كبيرة من الفيروسات.

موقعي مبني على Divi/Elementor/Avada: هل هذا يجعله أكثر عرضة للاختراق؟

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

ماذا أفعل إذا لم أتمكن من الوصول إلى لوحة تحكم ووردبريس؟

العمل من مزود الاستضافة: إعادة تسمية مؤقتة wp-content/plugins لتعطيل جميع الإضافات، قم بتسجيل الدخول مرة أخرى. إذا لم ينجح ذلك، فأعد تثبيت النظام الأساسي عبر WP-CLI أو عن طريق استبدال المجلدات.

هل يجب عليّ الحذف؟ `xmlrpc.php` ?

لا تحذف الملفات الأساسية. إذا كنت لا تستخدم XML-RPC، يمكنك حظره من جانب الخادم/جدار حماية تطبيقات الويب. قد تعتمد بعض الخدمات (التطبيقات، Jetpack، إشعارات التنبيه) عليه.

كيف يمكننا معرفة ما إذا كانت البيانات قد سُرقت؟

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

هل يكفي استخدام إضافة أمان؟

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

لقد قمت بلصق بعض الأكواد التي وجدتها على الإنترنت، ويظهر موقعي خطأً حرجاً.

شائع جدًا: نقص الأقواس، أو نسيان الفاصلة المنقوطة، أو استدعاء الدالة قبل الأوان (خطاف غير صحيح). عطّل إضافة المقتطفات البرمجية عبر بروتوكول نقل الملفات (FTP) (أو استعد الملف)، ثم حاول مرة أخرى في إضافة mu مع التحقق الصارم من الصحة. لا تختبر مباشرةً في بيئة الإنتاج دون وجود نسخة احتياطية.

لماذا ما زلت أرى عمليات إعادة التوجيه بعد التنظيف؟

غالباً ما يكون هذا بسبب التخزين المؤقت (الملحق/شبكة توصيل المحتوى/المتصفح) أو نص برمجي مُضاف إلى قاعدة البيانات (أداة، خيار التحميل التلقائي). امسح جميع ذاكرات التخزين المؤقت، ثم افحص صفحة HTML المُقدمة والخيارات الطويلة في wp_options.

ما هي أفضل طريقة وقائية "بسيطة"؟

إذا كنت ستفعل شيئًا واحدًا فقط: قم بإزالة الإضافات غير الضرورية et تفعيل المصادقة الثنائية فيما يتعلق بالمسؤولين، كان من الممكن تجنب معظم الحوادث التي أتعامل معها باتباع هذين الإجراءين، بالإضافة إلى التحديثات المنتظمة.