شهد أحد مواقع ووردبريس هجوماً متكرراً من حملات سبام استغلت نموذج التسجيل لإرسال بيانات مزيفة إلى قاعدة البيانات، قبل أن تتحول الأزمة إلى مشروع إصلاح واسع اعتمد على أدوات ذكاء اصطناعي في التحليل والكتابة والاختبار. القصة هنا لا تتعلق فقط بإيقاف رسائل مزعجة، بل بكيفية استخدام نماذج توليدية لتشخيص الثغرات وإعادة بناء طبقات الحماية بسرعة لافتة.
الهجوم بدأ بطريقة تبدو بسيطة ظاهرياً: حقول اسم المستخدم والبريد الإلكتروني كانت تُستخدم لتمرير نصوص دعائية وروابط مشبوهة، مع إشارات مرتبطة بالعملات المشفرة مثل العبارات التي توحي بتحويل الأموال أو التحقق من الرصيد. النتيجة كانت تدفق آلاف رسائل إنشاء الحسابات إلى البريد، ثم تضخم قاعدة البيانات بشكل جعل إدارة الموقع أكثر صعوبة.
مع تراجع فعالية أداة أمنية مدفوعة كانت يفترض أن تمنع هذا النوع من التسجيلات، اتجه صاحب الموقع إلى بناء طبقة حماية جديدة داخل الإضافة الأمنية التي يطوّرها لووردبريس. الفكرة كانت عملية ومباشرة: بدل الاعتماد على منتج لم يعد يفي بالغرض، جرى استخدام أدوات ذكاء اصطناعي لإعادة صياغة الدفاعات من الداخل، مع الحفاظ على إمكانية نشر الإصلاح سريعاً للموقع نفسه وللمستخدمين الآخرين.
من الرصد إلى التشخيص باستخدام الذكاء الاصطناعي
الخطوة الأولى كانت جمع عينات من رسائل البريد التي امتلأت بالطلبات الوهمية ثم تمريرها إلى أداة Codex لاقتراح دالة برمجية تحد من هذا النمط من الهجمات. بهذه الطريقة لم يكن الهدف كتابة كود نظري، بل إنتاج معالجة قابلة للنشر الفوري داخل إضافة أمنية قائمة بالفعل. بعد دمج التحسين الأول، هدأ الهجوم مؤقتاً، لكن ذلك لم يكن نهاية المشكلة.
بعد أسابيع، عاد السبينر أو المهاجمون إلى الضغط على الموقع بصورة أعنف، ما أدى إلى تضخم الحسابات في قاعدة البيانات إلى ما يتجاوز 39 ألف حساب، مع أكثر من 700 ألف سجل بيانات وصفية للمستخدمين. هذا الحجم جعل لوحة إدارة الحسابات بطيئة إلى درجة غير عملية، وفرض على صاحب الموقع الانتقال من الدفاع الجزئي إلى حملة تنظيف شاملة.
هنا دخل Claude Cowork إلى المشهد بوصفه أداة تحليل ومراجعة. جرى استخدامه لفحص قاعدة البيانات واستخراج مؤشرات على الحسابات المشبوهة وأنماط السلوك المرتبطة بالسبام. المفاجأة كانت أن المهاجمين وجدوا أكثر من مسار للوصول إلى التسجيل، بما في ذلك مسار يتجاوز بعض الفحوصات الأمنية التقليدية. كما اكتشف النظام أن بعض الروابط المسيئة كانت تُدسّ داخل حقل السيرة الذاتية بدلاً من الحقول المخصصة للروابط، ما تطلب توسيع منطق التحقق.
ثماني ثغرات ومسارات تسجيل غير محمية
بعد ساعات من الفحص، ظهرت صورة أوضح: لم تكن المشكلة في نقطة دخول واحدة، بل في ثمانية مواضع مختلفة سمحت بإدخال حسابات سبام إلى النظام. بعض هذه المسارات تجاوز النماذج المحمية، وبعضها لم يطلب اختبار التحقق البشري في الوقت المناسب، فيما أتاحت واجهات أخرى مثل REST API وXML-RPC وadmin-ajax ونماذج مخصصة فرصاً إضافية للمهاجمين.
هذه النتيجة غيّرت طبيعة المهمة. بدلاً من معالجة فرع صغير من الشجرة، أصبح المطلوب تغطية كل الأسطح المفتوحة تقريباً. لذلك جرى تصميم استراتيجية أمنية أوسع تضمنت فرض CAPTCHA على كل مسار يمكن أن يؤدي إلى إنشاء حساب، وإضافة إشارات تصنيف جديدة للحسابات المريبة، ثم بناء أداة تنظيف قادرة على تحليل الحسابات على دفعات وحذف ما يثبت أنه حسابات سبام.
ولأن العمل كان يجري تحت ضغط الوقت، قُسمت الأدوار بين الأداتين: Claude للمراجعة، والتحليل، وصياغة الأوامر، وCodex لكتابة الشيفرة نفسها. هذه المقاربة تقلل من الوقت الضائع في التنقل بين الفرضيات وتسمح بتسريع الدورة الكاملة من التشخيص إلى التنفيذ. لكن العملية لم تكن آلية بالكامل؛ بل تطلبت مراجعة بشرية مستمرة لتصحيح أخطاء النماذج والحد من أي قرارات مدمرة قد تنشأ من تعليمات غير دقيقة.
أداة تنظيف ضخمة داخل الإضافة الأمنية
أهم ما خرج به المشروع لم يكن فقط سد الثغرات، بل إنشاء منظومة تنظيف متعددة المراحل داخل الإضافة نفسها. هذه المنظومة استخدمت إشارات متعددة لتقدير ما إذا كان الحساب مشبوهاً، ثم أضافت واجهة إدارة جديدة تسمح ببدء التحليل من المتصفح، مع إمكانية الاستئناف إذا توقف العمل. كما دمجت أدوات حذف تدريجية لضمان عدم تحميل الخادم فوق طاقته أثناء معالجة عشرات الآلاف من الحسابات.
اختبارات التنظيف كانت بطيئة بطبيعتها لأن بعضها تضمن الرجوع إلى قواعد تحقق خارجية مثل قاعدة StopForumSpam، ما جعل كل دورة اختبار تستغرق ساعات. ومع ذلك، أدى هذا النهج إلى نتيجة عملية: حين اكتمل النشر النهائي، لم يعد الموقع يرى نشاط السبام السابق، وأصبح الوصول إلى لوحة إدارة الحسابات ممكناً من جديد.
أثناء عملية التنظيف، جرى حذف 15,069 حساباً من أصل 39,314 حساباً، إلى جانب إزالة 275,567 سجلاً وصفياً من 723,799. هذه الأرقام توضح حجم التلوث الذي يمكن أن تصل إليه هجمات التسجيل الآلية عندما لا تُرصد مبكراً. كما تُظهر أن المشكلة لا تقتصر على الرسائل المزعجة، بل تمتد إلى استنزاف موارد الاستضافة وتعطيل الإدارة اليومية للموقع.
تكلفة الذكاء الاصطناعي مقابل الوقت البشري
من الزاوية التقنية والاقتصادية، كشف المشروع عن نقطة لافتة: تمكنت أدوات الذكاء الاصطناعي من إنجاز ما يُرجح أنه كان سيستغرق أسابيع من العمل البشري المتواصل. خلال عطلة نهاية أسبوع واحدة، أُضيفت نحو 4,700 سطر برمجي جديد، وحُذف 170 سطراً، ما أسفر عن صافي زيادة بلغ 4,530 سطراً عبر 138 دالة إجرائية جديدة. هذا النوع من الإنجاز يساوي، وفق تقدير عملي، عشرات أيام العمل الهندسي وربما ما يقارب ثمانية أسابيع في سياق تطوير تقليدي.
الأهم أن هذا لم يحدث عبر ترك النماذج تعمل بلا إشراف. بل كان هناك تدخل بشري مكثف، وقراءة دقيقة للمخرجات، واختبار متواصل لكل تحديث. في إحدى المرات قدم Claude اقتراحاً كان يمكن أن يؤدي إلى كود مدمّر لو نُفذ كما هو، ما يذكّر بأن أدوات الذكاء الاصطناعي قادرة على التسريع، لكنها ليست بديلاً عن الحكم الهندسي والرقابة الأمنية.
كما أظهر العمل حدوداً عملية تتعلق بالاستخدام: بعض الأدوات تعمل ضمن حصص زمنية أو حدود خدمة، وقد يضطر المطور إلى التوقف مؤقتاً أو استخدام خيارات إعادة التعيين حتى يواصل. لكن حتى مع هذه القيود، كانت النتيجة النهائية أوضح من أي وقت مضى: قيمة هذه النماذج لا تكمن فقط في كتابة الشيفرة، بل في اختصار دورة الاستجابة للأزمات التقنية.
ما الذي تعنيه التجربة لمطوري المواقع
تجربة هذا الموقع تقدم درساً مباشراً للمطورين ومديري الأنظمة. أولاً، حماية التسجيل في ووردبريس يجب أن تكون متعددة الطبقات، لأن المهاجمين لا يلتزمون غالباً بالمسار القياسي للنموذج. ثانياً، أدوات الفلترة الواحدة قد تفشل عندما يكتشف السبام مساراً ثانوياً مثل REST API أو الحقول الجانبية. ثالثاً، التحليل الذكي للبيانات المتراكمة يمكن أن يكون أكثر أهمية من الحظر الفوري، لأن تنظيف الأثر المتراكم قد يصبح أولوية تشغيلية.
كما أن التجربة توضح أن الذكاء الاصطناعي بات شريكاً عملياً في الأعمال البرمجية الطارئة، خاصة عندما يكون الفريق صغيراً أو المطور وحيداً أمام أزمة أمنية. في هذه الحالة، لا يتعلق الأمر بالاستبدال، بل بتوسيع القدرة التنفيذية تحت ضغط شديد. وإذا كان هناك شيء واحد ثابت في هذا النوع من الهجمات، فهو أن المهاجمين لا يتوقفون بمجرد ظهور الإصلاح الأول، بل يعودون لاختبار النظام من جديد. لذلك تبقى المرونة، والتدقيق، والاستجابة السريعة هي خط الدفاع الأهم.