في الأسبوع الممتد من 17 إلى 23 أكتوبر 2026 ضرب المهاجمون الطبقات التي تُبنى عليها أغلب المواقع ومنتجات الذكاء الاصطناعي. ثغرتان حرجتان في لغة PHP التي تشغّل 69.3% من المواقع المعروفة لغتها الخلفية دفعتا حكومات إلى إيقاف مواقعها الرسمية مؤقتًا حتى تنتهي من التحديث. ونسخة ملغومة من LiteLLM، وهي بوابة شائعة لربط التطبيقات بنماذج الذكاء الاصطناعي، بقيت على مستودع الحزم الرسمي أقل من ساعتين وبداخلها برنامج لسرقة بيانات الدخول. وأعلنت منصة الاستضافة السحابية Railway أن متسللًا ربما اطّلع على المفاتيح السرية لعملائها، وأُفرغت محافظ رقمية قبل صدور الإعلان الرسمي. وفي اليابان عثر مزوّد خدمة على برامج خبيثة داخل خوادم يستضيفها لعملائه فأوقف كل الباقات وأعلن أن 26739 خادمًا ربما تأثرت. وفي السعودية ادّعت مجموعات إجرامية اختراق مقاول لأحد ملاعب كأس العالم ومزوّد لأنظمة ERP سحابية. نشرح في هذا المقال كل حادثة: كيف دخل المهاجمون ومتى وما الذي انكشف وما الذي يجب أن تفعله اليوم. والدرس المشترك بسيط: بياناتك آمنة بقدر أمان المفاتيح التي تفتحها، والذكاء الاصطناعي صار يسرّع المهاجم والمدافع معًا، والقرارات الصعبة يجب أن يتخذها إنسان خلال ساعات.
ماذا حدث في أكتوبر 2026 في جدول واحد؟
| الحادثة | التوقيت (UTC) | كيف دخل المهاجمون | ما الذي كان معرّضًا للخطر | الوضع الحالي |
|---|---|---|---|---|
| PHP2Shell (ثغرتان في PHP) | أول محاولة رُصدت في 17 أكتوبر والتحديث في 21 أكتوبر | أخطاء في إدارة الذاكرة داخل مفسّر PHP نفسه يمكن الوصول إليها بطلب ويب واحد | السيطرة الكاملة على خادم الموقع وكلمات المرور والمفاتيح الموجودة في ذاكرته | صدر التحديث وتأكدت محاولات الاستغلال |
| LiteLLM 1.107.0 | 21 أكتوبر من نحو 11:40 حتى 13:23 على PyPI | رموز دخول GitHub CLI مسروقة من ثلاثة مهندسين | مفاتيح السحابة ومفاتيح SSH وبيانات المتصفح ومفاتيح أدوات الذكاء الاصطناعي | حُذفت النسخة ويجب إعادة بناء الأجهزة المتأثرة |
| Railway | 21 أكتوبر وأوقفت المنصة عمليات البناء في 07:24 | لم يُكشف | متغيرات البيئة الخاصة بالعملاء وفُكّ تشفير بعضها | التحقيق مستمر والعملاء مطالبون بتغيير مفاتيحهم |
| Zeabur (الاختراق الثاني) | 14 و15 أكتوبر | رموز إدارية لم تُغيَّر بعد اختراق أغسطس | بيانات 321810 حسابات وأكثر من 3.2 مليون سجل لمتغيرات البيئة | الشركة تغلق أبوابها |
| أداة سطر الأوامر من OVHcloud | 19 أكتوبر من 12:47 حتى 14:21 | حساب GitHub مخترق لأحد المساهمين | الأسرار المحفوظة على أجهزة المستخدمين | صدرت نسخة نظيفة |
| Onamae Desktop Cloud (اليابان) | تأكد في 20 أكتوبر بتوقيت اليابان | قيد التحقيق | البيانات على ما يصل إلى 26739 خادمًا ومنها كلمات مرور التداول | كل الخوادم موقوفة |
| تحالف سما وشركة CRCC (السعودية) | ادّعاء عن 3 أكتوبر | لم يُكشف | أكثر من 1.5 مليون ملف وفق ادّعاء المهاجمين | ادّعاء غير مؤكد |
| نظام Nodhom السحابي للـ ERP (السعودية) | ادّعاء في 13 أكتوبر | لم يُكشف | غير محدد | ادّعاء غير مؤكد |
ما هي ثغرة PHP2Shell ولماذا أوقفت حكومات مواقعها؟
PHP2Shell هو الاسم الذي أُطلق على ثغرتين هما CVE-2026-109618 وCVE-2026-109619، وتقييم كل منهما 9.2 من 10. والثغرتان في لغة PHP نفسها لا في إضافة أو قالب، لذلك قد يكون الموقع مكشوفًا حتى لو كانت شيفرته مكتوبة بإتقان. ويشمل ذلك مواقع WordPress وLaravel لأن كليهما يعمل بلغة PHP. وبحسب The Hacker News تتأثر كل إصدارات PHP تقريبًا حتى الإصدار 5.4، والإعداد المعروف باسم Apache mod_php هو الأعلى خطرًا لأن طلبًا واحدًا دون تسجيل دخول يكفي لبدء الهجوم قبل أن تعمل أي شيفرة خاصة بالتطبيق. ويمكن للثغرتين أيضًا تسريب محتوى ذاكرة عملية PHP بما قد يكشف كلمات مرور ورموز دخول ومفاتيح API وشهادات تخص طلبات زوار آخرين.
وحجم الانتشار يفسّر حالة الاستنفار. فبحسب W3Techs تعمل لغة PHP على 69.3% من كل المواقع المعروفة لغتها الخلفية حتى 24 أكتوبر 2026. وحين تصيب ثغرة بهذه الخطورة لغة بهذا الانتشار لا توجد قائمة أهداف صغيرة.
ويوضح التسلسل الزمني ضيق الوقت الذي كان أمام المدافعين:
- 17 أكتوبر: رصدت شبكة المصائد التابعة لأمازون محاولة استغلال قبل الإعلان العام بأربعة أيام. وتقول أمازون إنه من غير الواضح كيف وصلت التفاصيل إلى المهاجم في هذا الوقت المبكر.
- 20 أكتوبر: تسرّبت أرقام الثغرتين على الإنترنت فقدّم فريق PHP موعد التحديث الأمني يومًا كاملًا. وفي مساء اليوم نفسه نشرت إحدى شركات البحث عن طريق الخطأ مقطع فيديو لاستغلال يعمل فعليًا.
- 21 أكتوبر في الساعات الأولى: فعّلت Cloudflare قواعد حماية في الساعة 03:02 بتوقيت UTC فغيّر المهاجمون أساليبهم للالتفاف عليها.
- 21 أكتوبر بعد الظهر: صدرت الإصدارات المصححة 8.5.12 و8.4.27 و8.3.36 و8.2.35. وفي الساعة 14:19 بتوقيت UTC أعلنت شركة watchTowr رصد محاولات استغلال نشطة للثغرتين.
ورأت بعض الجهات أن الإيقاف هو الخيار الأكثر أمانًا. ففي هولندا خرجت خدمتا DigiD وMijnOverheid الحكوميتان وموقع مجلس النواب وعدد من الأنظمة التعليمية عن الخدمة احترازيًا، وأوقفت شركة برمجيات الموارد البشرية BambooHR خدمتها في الولايات المتحدة وكندا وأيرلندا بحسب ما نشرته The Hacker News. وكان ذلك قرارًا بشريًا: قبول ساعات من التوقف بدلًا من المخاطرة باختراق.
وفي هذه القصة جانب يخص الذكاء الاصطناعي. فقد اكتشف الثغرتين فريق Wiz Research وشركة الأمن Calif وفريق Codex Security في OpenAI، وقال الباحثون إن نماذج الذكاء الاصطناعي ساعدتهم في تحويل الأخطاء إلى استغلال يعمل. والأدوات نفسها التي تساعد المدافع على كشف خطأ عمره أكثر من عشر سنوات يمكن أن تساعد المهاجم على تحويله إلى سلاح خلال ساعات من التسريب.
ماذا تفعل بخصوص PHP الآن؟
- اعرف إصدار PHP على كل خادم. تعرضه لوحة الاستضافة أو يمكن لمطوّر تشغيل الأمر php -v. وتكتشف شركات كثيرة في هذه الخطوة مواقع منسية: صفحة حملة قديمة أو نسخة تجريبية أو مدونة WordPress لا يحدّثها أحد.
- حدّث إلى إصدار مصحح. أي 8.5.12 أو 8.4.27 أو 8.3.36 أو 8.2.35 أو ما بعدها. وقد تقدّم توزيعات Linux الإصلاح تحت رقم إصدار يبدو قديمًا لذلك راجع ملاحظات الحزمة بحثًا عن رقمي الثغرتين. أما الإصدارات 7.4 و8.0 و8.1 فنشر فريق PHP لها تصحيحات في الشيفرة المصدرية فقط، وينتهي دعم الإصدار 8.2 في 31 ديسمبر 2026 فخطّط للترقية من الآن.
- إن لم تستطع التحديث اليوم فقلّل الخطر أو أوقف الموقع. يذكر فريق PHP إجراءات جزئية مثل تعطيل خاصية متابعة رفع الملفات في الجلسات (session.upload_progress.enabled=0) وفرض حدود لحجم الطلبات. لكنها لا تغلق الثغرتين معًا. وتنصح Rapid7 بالتحديث بشكل طارئ خارج دورات التحديث المعتادة.
- راجع السجلات بدءًا من 17 أكتوبر لا من تاريخ التحديث فقط. ومن العلامات المريبة: طلبات multipart غير معتادة تتبعها أخطاء في الذاكرة أو استجابات HTTP 500 متكررة وملفات تعريف PHPSESSID كبيرة الحجم بشكل غريب وإعادة تشغيل غير مفسرة لعمليات PHP وطلبات POST تحتوي على PHP_SESSION_UPLOAD_PROGRESS.
- إن بدا شيء غير طبيعي فغيّر الأسرار التي يحتفظ بها الموقع. كلمات مرور قواعد البيانات ومفاتيح بوابات الدفع وبيانات البريد ومفاتيح API المحفوظة في ملفات الإعداد يجب استبدالها لأن تسريب الذاكرة وحده قد يكشفها.
كيف لغّم المهاجمون LiteLLM ومن تأثر؟
LiteLLM بوابة مفتوحة المصدر واسعة الاستخدام تتيح للشركات توجيه طلباتها إلى نماذج ذكاء اصطناعي مختلفة من واجهة واحدة، لذلك تحمل غالبًا مفاتيح كل مزوّدي الذكاء الاصطناعي الذين تتعامل معهم الشركة. وفي 21 أكتوبر نُشر الإصدار 1.107.0 وبداخله برنامج لسرقة بيانات الدخول. ويحدد تحليل StepSecurity النافذة الزمنية: رُفعت الحزم الخبيثة إلى PyPI بين 11:39 و11:40 بتوقيت UTC وحُذفت قبل 13:23، وظلت وسوم Docker تشير إلى الصور المصابة حتى 14:20.
وطريقة الدخول أهم من البرنامج الخبيث نفسه. تقول الشركة المطوّرة إن نسخة داخلية من النظام كانت مكشوفة على الإنترنت العام، وإن سجلاتها احتوت على رموز دخول GitHub لثلاثة مطورين أحدهم مالك للمؤسسة على GitHub. واستخدم المهاجم رمز المالك لتجاوز حماية الفرع الرئيسي وتوجيه عملية الإصدار إلى مستودع شبيه بالاسم. وبحسب The Hacker News أطلق حساب الإصدار ووافق عليه حساب آخر، فمرّ فحص الشخصين المعتاد بهويات مسروقة. وهذا هو الاختراق الثاني للمشروع هذا العام بعد اختراق سابق في مارس.
وكان البرنامج الخبيث يعمل كلما بدأ تشغيل Python على الجهاز حتى لو لم تُستدعَ مكتبة LiteLLM أصلًا. وجمع بيانات الدخول إلى AWS وAzure وGoogle Cloud ومفاتيح SSH وTLS الخاصة وكلمات المرور وملفات التعريف المحفوظة في المتصفح وبيانات الدخول لأكثر من 20 أداة برمجة بالذكاء الاصطناعي، وعلى خوادم LiteLLM الوسيطة جمع مفاتيح المزوّدين المحفوظة. ثم كانت عملية في الخلفية تتصل كل ساعة لجلب شيفرة جديدة وتشغيلها.
إذا ثبّت أي جهاز أو حاوية الإصدار 1.107.0 أو سحب صورة متأثرة فتعامل معه على أنه مخترق بالكامل: أعد بناءه وثبّت الإصدار 1.106.2 وغيّر كل بيانات الدخول التي كان يصل إليها من جهاز نظيف.
ماذا حدث في Railway ولماذا كانت مفاتيح الذكاء الاصطناعي هي الهدف؟
تستضيف Railway تطبيقات المطورين والشركات الناشئة وتحفظ متغيرات البيئة الخاصة بها: مفاتيح API وكلمات مرور قواعد البيانات ورموز الدخول التي يحتاجها التطبيق ليعمل. وفي 21 أكتوبر أعلنت Railway أن طرفًا غير مصرح له ربما اطّلع على متغيرات البيئة المشفرة وحصل في بعض الحالات على محتواها بعد فك تشفيره. ولم تكشف المنصة كيف دخل المهاجم.
والتوقيت هو الجزء المؤلم. ويعرض موقع Crypto.news التسلسل: أوقفت Railway عمليات البناء في 07:24 بتوقيت UTC، ووقعت أول سرقة معروفة من محفظة كان مفتاحها الخاص محفوظًا على Railway في 19:36، ثم صدر الإعلان العام نحو 21:51. وقدّر الباحث Taylor Monahan الخسائر بنحو 371 ألف دولار عبر 19 شبكة بلوك تشين على الأقل، وهو رقم خارجي لم تؤكده Railway.
وقالت Railway إنها تعتقد أن الهجوم جزء من سلسلة تستهدف شركات المنصات بهدف اختراق مزوّدي تشغيل نماذج الذكاء الاصطناعي. وبعبارة بسيطة: صارت مفاتيح API الخاصة بالذكاء الاصطناعي غنيمة، فالمفتاح المسروق يتيح لغيرك تشغيل أعمال ذكاء اصطناعي مكلفة على حسابك أو الوصول إلى أي بيانات تراها أدوات الذكاء الاصطناعي لديك. وطلبت Railway من عملائها تغيير متغيراتهم وبيانات دخول السجلات الخاصة ومراجعة السجلات وإعادة النشر ببيانات تخزين جديدة وإعادة ربط GitHub.
وتُظهر منصة أصغر ما يحدث حين يكون التنظيف ناقصًا. فقد اختُرقت منصة الاستضافة Zeabur في أغسطس ثم مرة أخرى في 14 و15 أكتوبر ببيانات دخول إدارية سقطت من عملية التغيير بعد اختراق أغسطس. ويذكر موقع BleepingComputer أن الرموز الإدارية بلا تاريخ انتهاء ولم تُغيَّر منذ إنشائها في يناير 2024. وكشف الاختراق الثاني بيانات 321810 حسابات وأكثر من 3.2 مليون سجل لمتغيرات البيئة، وأعلنت الشركة أنها ستغلق خدماتها بحلول 31 ديسمبر 2026.
ماذا حدث لخدمة Onamae Desktop Cloud في اليابان؟
Onamae Desktop Cloud خدمة خوادم افتراضية تديرها شركة GMO Internet وتسوّقها لمن يشغّلون برامج تداول العملات الآلية على مدار الساعة. وفي تقريرها الثاني تقول GMO إن التحقيق بدأ في 19 أكتوبر بعد استفسار من أحد العملاء، وإنها تأكدت في 20 أكتوبر من تثبيت برنامج خبيث في بيئات خوادم بعض العملاء. فأوقفت لوحة التحكم والاشتراكات الجديدة، ثم بدأت من الساعة 04:00 بتوقيت اليابان يوم 21 أكتوبر إيقاف الخوادم في كل الباقات. ويبلغ عدد الخوادم التي ربما تأثرت 26739 خادمًا.
وتحذّر GMO من أن المعلومات المحفوظة على الخوادم ومنها كلمات مرور أدوات التداول وحسابات التداول ربما اطّلع عليها طرف ثالث، وتقول إن عملاء أبلغوا عن عمليات غير مصرح بها على حسابات التداول. وتواصلت الشركة مع الشرطة في 22 أكتوبر، وما زال مسار الاختراق قيد التحقيق. وطُلب من العملاء تغيير كلمات مرور التداول من جهاز آخر ومراجعة الأرصدة وسجل المعاملات وتفعيل التحقق بخطوتين وتغيير أي كلمة مرور مكررة في خدمات أخرى.
والدرس لكل شركة تستأجر خوادم: حين تُخترق البنية التحتية للمزوّد ينكشف كل ما هو محفوظ على خادمك حتى لو لم ترتكب أي خطأ. لذلك تعامل مع كلمات المرور المحفوظة على أي خادم على أنها قد تقع يومًا في يد شخص آخر.
ماذا حدث في السعودية؟
تصدّر ادعاءان العناوين هذا الشهر. وكلاهما صادر عن المهاجمين ولم تؤكده الشركات المذكورة.
- مقاول ملعب جدة. ادّعت مجموعة تُعرف باسم WallStreet أنها اخترقت تحالف سما للإنشاءات الذي يضم شركة China Railway Construction Corporation في 3 أكتوبر. ووصفت شركة التحليل الإماراتية Hackmanac التحالف بأنه المقاول الرئيسي لملعب جدة المركزي أحد ملاعب كأس العالم 2034. ويشمل الادعاء أكثر من 1.5 مليون ملف بحجم نحو 17 تيرابايت منها عقود ومعلومات دفع وتصميمات للملعب وبيانات شخصية لـ150 ألف موظف. ولم ترد الشركة على طلب صحيفة The National للتعليق.
- مزوّد سعودي لأنظمة ERP السحابية. في 13 أكتوبر ادّعت مجموعة الفدية HYFLOCK علنًا مهاجمة شركة Nodhom السعودية لأنظمة ERP السحابية وهددت بنشر البيانات ما لم تتواصل معها الشركة. ولم يُذكر نوع البيانات أو حجمها ولا يوجد تأكيد مستقل.
وحتى بوصفهما ادعاءين يحمل كلاهما رسالة واضحة للشركات في السعودية والخليج: بياناتك لا تعيش في أنظمتك وحدها. إنها عند مقاوليك ومستشاريك وكل أداة سحابية يستخدمها فريقك ومنها نظام ERP الذي يحمل حساباتك ورواتب موظفيك. فاسأل كل مزوّد ثلاثة أسئلة: كيف تحمي مفاتيح الوصول إلى بياناتنا؟ وكم من الوقت تحتاج لتخبرنا بأي حادثة؟ وهل نستطيع تصدير بياناتنا إن احتجنا إلى المغادرة؟
والقانون أيضًا يضع ساعة للعد التنازلي. فبموجب نظام حماية البيانات الشخصية في السعودية يجب على جهة التحكم إبلاغ سدايا خلال 72 ساعة من علمها بالتسرب متى كان قد يسبب ضررًا. وفي مصر تُلزم اللائحة التنفيذية للقانون رقم 151 لسنة 2020 بإبلاغ مركز حماية البيانات الشخصية خلال 72 ساعة وإخطار الأفراد المتأثرين خلال ثلاثة أيام عمل. ولا يمكنك الالتزام بهذه المواعيد إن لم يلاحظ أحد الاختراق أصلًا.
ما القاسم المشترك بين كل هذه الحوادث؟
- المفاتيح كانت الغنيمة. متغيرات البيئة ومفاتيح API ورموز GitHub وكلمات المرور المحفوظة تظهر في كل حادثة تقريبًا. والمهاجمون يتجاوزون بابك الأمامي بشكل متزايد ويذهبون مباشرة إلى المفاتيح المحفوظة في استضافتك وأدوات البناء وخوادمك.
- الرموز المسروقة فتحت الأبواب. دخل المهاجمون إلى LiteLLM وZeabur وأداة سطر الأوامر من OVHcloud ببيانات دخول صالحة لا بثغرات معقدة. وفي حالة OVHcloud استبدل حساب مساهم مخترق ملفات الإصدار لمدة 94 دقيقة.
- الذكاء الاصطناعي في الجهتين. ساعد الذكاء الاصطناعي الباحثين على اكتشاف PHP2Shell واستغلالها. وطارد المهاجمون مفاتيح الذكاء الاصطناعي في Railway. وذكرت رويترز أن مخترقًا واحدًا استخدم وكلاء ذكاء اصطناعي يعملون ذاتيًا لاختراق مواقع أكثر من 100 شركة خلال أسبوعين تقريبًا بتعليمات أقل من 100 حرف صيني وبتكلفة تقديرية تبلغ نحو 50 دولارًا للاختراق الناجح الواحد.
- السرعة تحدد حجم الضرر. كانت PHP2Shell تُختبر قبل وجود التحديث. وفي Railway أُفرغت المحافظ قبل الإعلان بأكثر من ساعتين. والفارق بين «هناك شيء غير طبيعي» و«وقع الضرر» صار يُقاس بالساعات.
لماذا لا يكفي الذكاء الاصطناعي وأين يجب أن يتدخل الإنسان؟
صار الذكاء الاصطناعي جزءًا من الدفاع الجيد. فهو يفحص كل الخوادم بحثًا عن الإصدارات المصابة في دقائق ويقرأ سجلات لا يجد أي شخص وقتًا لقراءتها وينبّه إلى تسجيل دخول غريب في الثالثة فجرًا. لكن انظر إلى من اتخذ القرارات التي حدّت من الضرر هذا الشهر:
- في OVHcloud كانت مهمة بناء آلية لدى أحد العملاء قد ثبّتت البصمة الدقيقة لملف ما فبدأت تفشل حين تغيّر الملف. ثم نشر شخص بلاغًا علنيًا في الساعة 13:50 بتوقيت UTC فحُذفت الملفات الخبيثة في 14:21. الآلة أطلقت الإنذار والبشر تصرفوا.
- في Onamae بدأ التحقيق من استفسار أحد العملاء.
- في هولندا وفي BambooHR اختار أشخاص ساعات من التوقف بدلًا من خطر الاختراق.
- وفي Zeabur كان الإخفاق بشريًا أيضًا: رموز إدارية كان يجب تغييرها بعد الاختراق الأول بقيت كما هي، فأنهى الاختراق الثاني الشركة.
والنموذج الناجح واضح: دع الذكاء الاصطناعي يراقب ويفرز وينبّه بسرعة الآلة، ودع شخصًا محددًا بالاسم يقرر ما الذي يُوقف وأي المفاتيح تُغيَّر وماذا نقول للعملاء ومتى نبلغ الجهة الرقابية، وسجّل كل إجراء من هذه الإجراءات. ونشرح كيف تضع هذه القواعد في دليلنا عن حوكمة الذكاء الاصطناعي: الصلاحيات والبيانات والموافقات، ولماذا يبقى حكم الإنسان مهمًا في ملخصنا عن حدود الذكاء الاصطناعي.
ماذا تفعل شركتك خلال الساعات الأربع والعشرين القادمة؟
- اكتب قائمة. كل موقع وخادم ومنصة سحابية تستخدمها وإصدار PHP على كل منها وكل مكان تُحفظ فيه مفاتيح API وكلمات المرور.
- حدّث أو أوقف. حدّث PHP إلى إصدار مصحح. وإن تعذّر تحديث موقع اليوم ففكّر في إيقافه حتى يمكن تحديثه.
- افحص المنتجات المحددة. هل ثبّت أحد في فريقك LiteLLM 1.107.0 أو أداة سطر الأوامر من OVHcloud يوم 19 أكتوبر؟ هل تستضيف على Railway أو Zeabur أو Onamae Desktop Cloud؟ إن كانت الإجابة نعم فاتبع تعليمات كل مزوّد المذكورة أعلاه.
- غيّر الأسرار من جهاز نظيف. غيّر المفاتيح وكلمات المرور من جهاز تثق به لا من الخادم الذي قد يكون مخترقًا، وألغِ القديمة.
- فعّل التحقق بخطوتين على لوحات الاستضافة وGitHub ولوحات السحابة وبوابات الدفع والبريد الإلكتروني.
- اقرأ السجلات بدءًا من 17 أكتوبر. استخدم أدوات آلية لاكتشاف المؤشرات الغريبة واجعل شخصًا يراجع ما تنبّه إليه.
- استعد للإبلاغ. إن كانت بيانات شخصية قد انكشفت فمهلة 72 ساعة في مصر والسعودية تبدأ من لحظة علمك. حدّد من الآن من المسؤول عن هذا القرار.
والاختراق لا يأتي دائمًا في صورة رسالة فدية. وقد رأينا ذلك بأنفسنا: ففي دراسة حالة PCE نشرح كيف نظّفنا اختراقًا خفيًا ملأ موقع أحد العملاء بصفحات يابانية مزعجة في نتائج جوجل.
لو موقعك أو نظامك شغال على PHP أو مفاتيحك محفوظة على منصة استضافة، متستناش العنوان الجاي. كلّم فريق HBS وهنساعدك تعرف إصدار PHP عندك ونقفل الثغرات ونغيّر مفاتيحك بأمان ونجهّز لك متابعة بتجمع بين التنبيهات الآلية وشخص بيتصرف فيها على طول. ولو إحنا اللي بنبني أو بندير موقعك، فريق تطوير المواقع عندنا يقدر يحدد معاك ميعاد التحديث النهاردة.
