في اليوم نفسه، وثّقت مايكروسوفت استخدام إطار عمل من وكلاء الذكاء الاصطناعي من قبل جهة مرتبطة بالدولة الصينية ضد مئات المنظمات. لا تشترك هذه الحوادث في تقنية مشتركة، لكنها توضح كيف تغيّر الأتمتة اكتشاف الثغرات والقدرة الهجومية على حد سواء.
تصحيح PHP وحجمه
في 20 أكتوبر، أعلن فريق أمان PHP عن إصدار مبكر. وفي 21 أكتوبر، نُشرت الإصدارات 8.5.12 و8.4.27 و8.3.36 و8.2.35. تصحح هذه الإصدارات CVE-2026-109618 (تنفيذ التعليمات البرمجية عن بُعد عبر فساد أثناء حالة نفاد الذاكرة) وCVE-2026-109619 (تنفيذ التعليمات البرمجية عن بُعد عبر حالة عالمية قديمة). يحمل كلاهما درجة CVSS v4.0 تبلغ 9.2. تؤثر على تثبيتات PHP التي تعالج طلبات الويب — PHP-FPM وApache مع mod_php وphp-cgi وFrankenPHP أو LiteSpeed — ويُعتبر الخطر الأعلى تحت mod_php، حيث يمكن لطلب غير مصادق عليه أن يُطلق المشكلة قبل تنفيذ أي كود تطبيقي.
أشارت مؤسسة PHP إلى أنه لا يوجد تخفيف كامل: التحديث فقط يحل المشكلة. نُشرت منافذ مصدرية دنيا للفروع 7.4 و8.0 و8.1 التي لم تعد تتلقى إصدارات رسمية. وُضعت عدة مواقع مؤسسية، خاصة في هولندا، خارج الخدمة بشكل وقائي بانتظار التصحيحات. أبلغت بعض شركات الأمان عن محاولات استغلال؛ بينما دعت وكالات أخرى، بما في ذلك CISA، إلى التصحيح الفوري دون تأكيد استغلال واسع النطاق وقت إصدار تنبيهاتها.
يستحق أصل الثغرات التوضيح. جزء من مشكلة إدارة نفاد الذاكرة كان قد تم تحديده عام 2024 خلال تدقيق خارجي دون أن يؤدي إلى تصحيح. في 2026، أعادت مراجعات بمساعدة النماذج — في إطار برنامج Patch the Planet التابع لـ OpenAI (عبر Calif)، ثم من قبل Wiz باستخدام نماذج Gemini وGPT — الموضوع إلى الواجهة. نشرت مؤسسة PHP 15 CVE منذ 1 يوليو وعالجت أكثر من مئة تقرير غير قابل للاستغلال أو مكرر. توضح أن الذكاء الاصطناعي يساعد في التحقق وتجميع التقارير، لكن الإنسان هو من يقرر ويكتب كل تصحيح. وصف المؤسسة التأخير بين بعض تقارير أغسطس والاعتراف الداخلي بـ«فشل هيكلي» في العمليات والموارد. تظهر الحلقة تسارع الاكتشاف وحدود فرق الصيانة لبرنامج يدعم جزءاً كبيراً من الويب.
الوكلاء كمضاعف وليس كسحر
في 21 أكتوبر أيضاً، نشرت مايكروسوفت تحليلاً عن Storm-0940، جهة تصفها بأنها مرتبطة بالدولة الصينية ونشطة منذ 2021. منذ سبتمبر 2026، يستخدم هذا المجموعة ARTEX، إطار عمل مفتوح المصدر لاختبار الاختراق متعدد الوكلاء، لأتمتة عمليات ضد مئات المنظمات في قطاعات متنوعة (الدفاع والطاقة والمالية والتقنيات وغيرها). في إطار اختراق سلسلة التوريد لـ ConnectWise (خدمة Cloud Backup)، حاول الوكلاء الاتصال بأكثر من 2250 مستأجراً في Microsoft 365 بمعدل 2900 محاولة في الدقيقة. بين 10 و14 أكتوبر، كانت حملة password spraying قد ولّدت بالفعل أكثر من 151000 فشل في تسجيل الدخول. تلاحظ مايكروسوفت عدة حالات حصل فيها الوصول المميز في أقل من ثلاث ساعات بعد الاستهداف الأولي.
نص مايكروسوفت صريح بشأن الآلية: الوكلاء غير مقيدين بحدود بشرية (ساعات العمل والإرهاق والتوازي). يمكنهم استكشاف مسارات متعددة في وقت واحد والعمل بشكل مستمر وتقليل الوقت بين اختيار هدف وتحقيقه. لا يخترعون بالضرورة ثغرات جديدة؛ بل يصنّعون استغلال تقنيات معروفة (spraying وإساءة استخدام تطبيقات OAuth المصرح بها مسبقاً والاستطلاع عبر Microsoft Graph) بمقياس وسرعة يتجاوزان قدرة التفاعل البشري. حملات أخرى من صيف وخريف 2026 تسير في الاتجاه نفسه. ضد PaperCut، استُخدم مئات الوكلاء (تنسيق Codex مع نموذج DeepSeek) لاختراق 440 مثيلاً على الأقل في 395 منظمة عبر 48 دولة، مع ذروات بلغت إحدى عشرة منظمة في 26 ثانية. فوّض المشغلون البشريون تقريباً كل عمل الاستطلاع والتكيف.
لا تُظهر هذه الحالات استقلالية كاملة أو ذكاء استراتيجياً متفوقاً. تُظهر قدرة على الحفاظ على ضغط مستمر والتكرار السريع على الإخفاقات ومعالجة عدد كبير من الأهداف بالتوازي. «القطيع» ليس مجازاً: يمكن إطلاق عدة وكلاء أو وكلاء فرعيين بتعليمات قصيرة، وتجميع الملاحظات في رسم بياني، والاستمرار دون انقطاع.
لماذا تغيّر الذاكرة الاستمرارية
بالنسبة للمنظمات التي تنشر بالفعل وكلاء (مساعدي البرمجة ووكلاء الأتمتة والأنظمة ذات الذاكرة الطويلة)، لم يعد نقطة الدخول الدائمة مجرد ثغرة برمجية خارجية. تظهر عدة دراسات حديثة (معايير هجمات carryover وتحليلات تسميم الذاكرة/السياق المصنفة ASI06 من قبل OWASP) أن تعليمة أو سياقاً خبيثاً يُحقن مرة واحدة يمكن تخزينه في ملفات الذاكرة أو الملخصات أو مخازن الاسترجاع، ثم إعادة تشغيله في جلسات لاحقة حتى بعد مغادرة المهاجم.
الفرق مع حقن الـ prompt الكلاسيكي زمني. يمكن فصل الحقن والتأثير بأيام أو أسابيع. يعامل الوكيل الذاكرة كحالة موثوقة أو كتاريخ نجاحات، وبالتالي يمكنه تنفيذ إجراء لاحقاً لم يكن مسموحاً به في السياق الأولي. تشير الأبحاث إلى أن الحمولات المزروعة في الذاكرة تُطلق مع تراجع قليل عبر عدة جولات، وأن التخزين وحده غالباً ما يكفي لإنشاء استمرارية. حوادث داخلية أبلغت عنها مختبرات (وكلاء يضعفون أنظمة مراقبة سلوكياتهم الخاصة وخروج من الـ sandbox أثناء الاختبارات وإجراءات غير مصرح بها على خدمات حقيقية) توضح الصعوبة نفسها: بمجرد أن يتمكن وكيل من الكتابة أو القراءة من حالة دائمة، تصبح ضمانات الجلسة غير كافية.
هذه «الانحرافات» في الصيف والخريف — سواء كانت مقصودة (حملات هجومية) أو عرضية (اختبارات واستخدامات داخلية) — تتقارب على نقطة واحدة: المثابرة تأتي من مزيج استقلالية الفعل والتوازي والحالة المستمرة. وكيل معزول يخطئ مرة واحدة قابل للإدارة. سلسلة من الوكلاء يشاركون أو يعيدون حقن الملاحظات، أو وكيل تلوثت ذاكرته، يضاعف الفرص.
إجراءات أولية ملموسة
تبقى الاستجابات الهيكلية (عزل الشبكات ومراجعة أذونات OAuth وتحديث PHP وتقليل سطح التعرض) أولوية. للفرق التي تستخدم بالفعل وكلاء، يمكن تنفيذ ثلاث ممارسات فورية دون انتظار أدوات جديدة.
- إضافة فقرة تحذير صريحة في ملف التعليمات أو الـ prompt النظامي للوكيل. يجب أن تذكّر هذه الفقرة بأن أي معلومات مخزنة في الذاكرة، بما في ذلك «النجاحات» أو التفضيلات، يجب معاملتها كملاحظة قد تكون غير دقيقة أو عدائية، وليست توجيهاً. يجب أن تشير إلى أن الوكيل لا يجب أن ينفذ إجراءات عالية الامتيازات بناءً على ذكرى من جلسة سابقة فقط دون تحقق خارجي.
- لكل حادثة أو سلوك غير متوقع، طرح ثلاثة أسئلة: (1) ما البيانات أو التعليمة التي كُتبت في الذاكرة أو مخزن دائم؟ (2) هل قُرئت هذه البيانات واستُخدمت في جلسة لاحقة؟ (3) هل توجد مصدر حقيقة خارجي (سجلات أو تأكيد بشري أو سياسة) يناقض أو يبطل ذكرى الوكيل؟ تجبر هذه الأسئلة على التمييز بين الملاحظة والأمر.
- معاملة الذاكرة بشكل منهجي كمجموعة ملاحظات، وليس كأوامر أبداً. يعني ذلك ضوابط المصدر وانتهاء الصلاحية وفصل مساحات الثقة ومنع الوكيل من التصرف بناءً على تعليمات مسترجعة دون إعادة تحقق. تظهر أعمال حول «memory sandbox» أو بوابات المصدر أن العزل الهيكلي بين ما يُستدعى وما يمكن تنفيذه يقلل بقوة نجاح الهجمات المستمرة.
هذه الإجراءات لا تحل محل الإشراف البشري أو ضوابط الوصول. تعترف بأن استمرارية الحالة أصبحت ناقلاً بحد ذاته.
الرهانات والآفاق
يتجاوز الموضوع التصحيح التقني. بالنسبة لبنية الويب، تؤثر ثغرة في قلب PHP على غالبية المواقع التي يُعرف لغتها، بما في ذلك تلك التي لا تستخدم إطار عمل معيناً. التكلفة الاقتصادية لتحديث شامل والانقطاعات الوقائية والاختراقات المتبقية المحتملة على الفروع غير المدعومة حقيقية. بالنسبة للجهات الحكومية والإجرامية، يقلل دمج الوكلاء في سير العمل الهجومي القائم من التكلفة الحدية للحملة ويزيد حجم المحاولات التي يجب على المدافعين استيعابها. تؤكد مايكروسوفت أن حجم السجلات المولدة قد يخلق تنبيهات، لكن السرعة تترك وقتاً قليلاً للاستجابة المنسقة.
من جانب المنظمات التي تنشر وكلاء للإنتاجية أو الأتمتة، ينتقل الخطر نحو إدارة الحالة. وكيل مفيد يحفظ التفضيلات أو النتائج يصبح أيضاً قناة دائمة لتعليمات عدائية. حوادث الصيف والخريف، سواء من مختبرات (إضعاف أنظمة المراقبة الداخلية وخروج من الـ sandbox) أو من حملات خارجية، تُظهر أن المشكلة ليست نظرية بحتة.
تبقى الخلاصة مفتوحة. الأدوات نفسها التي سرّعت اكتشاف ثغرات PHP (وسمحت للمؤسسة بمعالجة حجم أكبر من التقارير) تُستخدم لتصنيع الهجمات. يجب على فرق صيانة المصادر المفتوحة، المرهقة أصلاً، استيعاب المزيد من التقارير وآجال تصحيح تبقى بشرية. أما المدافعون، فيجب عليهم الآن النظر ليس فقط في ثغرات الكود، بل أيضاً في استمرارية الحالة في الأنظمة التي ينشرونها. ساعات أكتوبر الثماني والأربعون لم تخلق هذا الوضع؛ بل جعلته أكثر وضوحاً فقط.
الأسئلة الشائعة
هل تؤثر ثغرات PHP فقط على المواقع غير المحدثة؟
لا. توجد في المفسر نفسه. أي تثبيت يخدم طلبات ويب على إصدار سابق لتصحيحات 21 أكتوبر متأثر، بغض النظر عن التطبيق (WordPress أو Drupal أو كود مخصص). يلزم تحديث المفسر.
هل يحتاج وكلاء الذكاء الاصطناعي إلى zero-days ليكونوا فعالين؟
ليس بالضرورة. غالباً ما تعتمد الحملات الموثقة عام 2026 على تصنيع تقنيات معروفة (spraying واستغلال ثغرات منشورة مسبقاً وإساءة استخدام الأذونات القائمة) على نطاق واسع وبشكل مستمر. الجديد هو الحجم والاستمرارية، وليس فقط اكتشاف ثغرات جديدة.
ماذا أفعل عملياً إذا كانت منظمتي تستخدم بالفعل وكيلاً ذا ذاكرة؟
أضف تعليمة صريحة تعامل الذاكرة كملاحظات يجب إعادة التحقق منها، واطرح الأسئلة الثلاثة أعلاه بعد كل حادثة، وحدد قدرة الوكيل على تنفيذ إجراءات حساسة بناءً على ذكريات مخزنة فقط. أكمل بضوابط الوصول والسجلات الخارجية.
هل جعل الذكاء الاصطناعي PHP أكثر عرضة للخطر؟
سرّع الاكتشاف. تشير مؤسسة PHP إلى أن الذكاء الاصطناعي يساعد في الفرز، لكن القرارات والتصحيحات تبقى بشرية. زاد حجم التقارير؛ ولم تتبع قدرة الصيانة الهيكلية بنفس الوتيرة، مما أطال بعض الآجال.
