إدارة الثغرات Vulnerability Management: هل سيرفرك متأثر؟

في يوم الأربعاء 21 أكتوبر 2026 وصلت ثلاث نشرات أمنية في يوم واحد، فشركة Oracle أصدرت تنبيهاً أمنياً Security Alert خارج مواعيدها الدورية لثغرة في Java تقييمها 9.1، وذلك بعد يوم واحد فقط من تحديثها الفصلي الذي حمل 1295 إصلاحاً منها 55 في Java SE وحدها، وفريق PHP أصدر أربعة إصدارات دفعة واحدة لإغلاق ثغرتين حرجتين تسمحان بتنفيذ الأوامر عن بعد Remote Code Execution دون تسجيل دخول، ومشروع Node.js أصدر تحديثات أمنية لثلاثة خطوط إصدار، ونشر المركز الوطني الإرشادي للأمن السيبراني تنبيهين بمستوى خطورة «عال جداً» عن PHP وOracle. وإذا كنت تدير خمسة سيرفرات أو خمسمئة فالسؤال الذي يهمك في هذه اللحظة ليس «ما هذه الثغرات؟» وإنما «أي سيرفر عندي متأثر، وماذا أفعل الآن؟».

وقد يبدو الجواب سهلاً من الوهلة الأولى، فتدخل إلى السيرفر وتكتب php -v وتقارن الرقم بالنشرة، ولكن في الواقع فالأمر غير ذلك، فعلى Ubuntu 24.04 سوف يقول لك الأمر إن النسخة هي PHP 8.3.6 بينما تقول النشرة إن كل نسخ 8.3 قبل 8.3.36 متأثرة، ومع ذلك فالسيرفر الذي جربناه عليه كان قد أصلح الثغرتين. وفي المقابل قد يكون السيرفر متأثراً بثغرة Node.js وأنت تبحث عن إصدار Node جديد، بينما الإصلاح الحقيقي في حزمة أخرى تماماً. وهذا بالضبط ما تحله إدارة الثغرات Vulnerability Management، فهي عملية مستمرة تعرف بها ماذا يعمل عندك، وأي ثغرة تمسه فعلاً، وما الذي تصلحه أولاً، ثم تتأكد أن الإصلاح تم.

في هذا المقال سوف نتناول:

• المصطلحات التي ستقابلها في كل نشرة: CVE وCNA وNVD وCVSS وEPSS وKEV، وماذا يقول كل واحد منها وماذا لا يقول.
• نشرات الموردين Vendor Advisories ومواعيدها: Oracle وPHP وNode.js والتوزيعات Debian وUbuntu وRed Hat، وتنبيهات الهيئة الوطنية للأمن السيبراني.
• لماذا يخدعك رقم الإصدار على التوزيعات بسبب الإصلاحات المنقولة Backports، بثلاث حالات حقيقية من ثغرات هذا الأسبوع.
• دورة إدارة الثغرات: الجرد Inventory، والمطابقة Matching، وترتيب الأولوية Prioritization، والإصلاح Patch أو التخفيف Mitigation، والتحقق Verification.
• ماذا تفعل في أول 24 ساعة بعد نشرة حرجة، بأوامر حقيقية.
• تجربة عملية نسأل فيها OSV وNVD وقائمة KEV وEPSS عن ثغرات هذا الأسبوع ونقرأ النتائج.

وإذا كنت تبحث عن فحص مكتبات مشروعك أثناء التطوير فقد شرحناه في فحص الاعتماديات SCA، وفحص ال Docker Images في خط CI في فحص ال Docker Images وملفات البنية ككود، أما هذا المقال فيتحدث عن السيرفرات والخدمات التي تعمل الآن في الإنتاج.

ماذا تعني CVE وCNA وNVD؟

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

• المعرف CVE (Common Vulnerabilities and Exposures): رقم فريد للثغرة مثل CVE-2026-109618، ومعه وصف قصير والنسخ المتأثرة والمراجع، وينشر في سجل CVE.org. وتشبيهه الأقرب هو رقم الهوية، فهو لا يقول عنك شيئاً كثيراً لكنه يضمن أن الجميع يتحدثون عن الشخص نفسه.
• الجهة المصدرة CNA (CVE Numbering Authority): الجهة التي تحجز الرقم وتنشر السجل، وغالباً هي المورد نفسه. فثغرة Java سجلتها Oracle، وثغرتا PHP سجلهما فريق PHP، أما ثغرة Brotli التي أصلحها Node.js فسجلتها Google لأن Brotli مشروعها، ولذلك تجد سجلها بعنوان Out-of-Bounds Write in Google Brotli Decoder رغم أنك قرأت عنها أول مرة في نشرة Node.js.
• قاعدة NVD (National Vulnerability Database): قاعدة بيانات أمريكية تأخذ سجلات CVE وتضيف إليها تقييماً من فريقها ومعرفات المنتجات CPE التي تستخدمها بعض أدوات الفحص للمطابقة. والمهم هنا أن NVD تتأخر عن المورد، فثغرة Brotli أصلحها Node.js في 21 أكتوبر، ونشر سجلها في CVE.org في 22 أكتوبر الساعة 13:35 بتوقيت UTC، ثم ظهرت في واجهة NVD الساعة 14:17 بحالة Received أي دون تحليل بعد. وأي أداة تعتمد على NVD وحدها لم تكن لترى هذه الثغرة طوال يوم كامل بعد صدور الإصلاح.

نشرات الموردين Vendor Advisories ومواعيدها

المصدر الأصلي لأي ثغرة هو نشرة المورد، وكل مورد له إيقاع مختلف، ومعرفة هذا الإيقاع تجعلك تتوقع العمل بدل أن تتفاجأ به. فلو كنت تعرف أن Oracle تصدر تحديثها الفصلي في الثلاثاء الثالث من أكتوبر فسوف تحجز يوماً للاختبار في الأسبوع نفسه، بدل أن تكتشفه بعد شهر من تقرير الفحص. والجدول التالي يلخص ما قرأناه اليوم من الصفحات الرسمية:

لاحظ أن تنبيه الهيئة عن Oracle يشير إلى التحديث الفصلي، بينما ثغرة Java ذات التقييم 9.1 جاءت في تنبيه منفصل بعده بيوم، لذلك لا تكتف بالتنبيه المحلي أو بخبر واحد، وارجع دائماً إلى صفحة المورد نفسها لأنها الأحدث والأدق.

لماذا يخدعك رقم الإصدار Version Number على التوزيعات؟

التوزيعات المستقرة مثل Debian وUbuntu وRHEL تعد مستخدميها بألا تغير سلوك البرامج في منتصف عمر الإصدار، لذلك عندما تظهر ثغرة في PHP 8.3 فإن Ubuntu لا ترفعك إلى 8.3.36 وإنما تأخذ تعديل الإصلاح وحده وتطبقه على النسخة 8.3.6 التي شحنت بها التوزيعة، وتسمى هذه العملية نقل الإصلاح Backport. والنتيجة أن الرقم الأصلي يبقى كما هو، والذي يتغير هو الجزء الأخير من رقم الحزمة. وقد جربنا ذلك على Docker Image رسمية لـ Ubuntu 24.04:

docker run --rm ubuntu:24.04 bash -c "apt-get update -qq >/dev/null && DEBIAN_FRONTEND=noninteractive apt-get install -y -qq php8.3-cli >/dev/null 2>&1; php -v; dpkg-query -W -f='\${Package} \${Version}\n' php8.3-cli"

والمخرج سوف يكون كما يلي:

PHP 8.3.6 (cli) (built: Oct 19 2026 15:16:58) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.3.6, Copyright (c) Zend Technologies
    with Zend OPcache v8.3.6, Copyright (c), by Zend Technologies
php8.3-cli 8.3.6-0ubuntu0.24.04.13

ومن سجل تغييرات الحزمة نفسها /usr/share/doc/php8.3-cli/changelog.Debian.gz نقرأ السطر الذي يحسم الأمر:

php8.3 (8.3.6-0ubuntu0.24.04.13) noble-security; urgency=medium

  * SECURITY UPDATE: Remote RCE via state corruption issue
    - debian/patches/CVE-2026-109618_109619.patch: Avoid state corruption via
      bailout in Zend/tests/bug40770.phpt, Zend/tests/bug54268.phpt,

في المخرج أعلاه لاحظ التالي:

• php -v يقول 8.3.6، ونشرة PHP تقول إن كل ما قبل 8.3.36 متأثر، فلو قارنت الرقمين لقلت إن السيرفر متأثر، وهذا خطأ.
• الرقم الذي يحسم هو رقم الحزمة كاملاً 8.3.6-0ubuntu0.24.04.13، وصفحة Ubuntu للثغرة تقول إنها أصلحت في هذا الرقم بالضبط لـ Ubuntu 24.04، وفي 8.1.2-1ubuntu2.28 لـ Ubuntu 22.04 رغم أن فرع 8.1 لم يعد مدعوماً من PHP أصلاً.

حالة Node.js على Debian: الإصلاح في حزمة Package أخرى

والحالة الثانية أغرب، فنشرة Node.js تقول إن ثغرة فك ضغط Brotli تمس الخطوط 22 و24 و26، فتبحث على سيرفر Debian 12 عن إصدار Node جديد. لكن Debian لا تبني Node مع نسخة Brotli مدمجة، وإنما تربطه بمكتبة النظام، والأمر التالي يبين ذلك على سيرفر Debian 12 ثبتنا عليه nodejs من مستودع التوزيعة:

node -v
dpkg-query -W -f='${Package} ${Version}\n' nodejs libbrotli1
ldd /usr/bin/node | grep -i brotli

والمخرج:

v18.20.4
libbrotli1 1.0.9-2+b6
nodejs 18.20.4+dfsg-1~deb12u3
	libbrotlidec.so.1 => /lib/x86_64-linux-gnu/libbrotlidec.so.1 (0x00007f01f6526000)
	libbrotlienc.so.1 => /lib/x86_64-linux-gnu/libbrotlienc.so.1 (0x00007f01f6493000)
	libbrotlicommon.so.1 => /lib/x86_64-linux-gnu/libbrotlicommon.so.1 (0x00007f01f56b3000)

وهذا يعني أن الكود المتأثر في هذا السيرفر هو المكتبة libbrotli1، وأن تحديث nodejs وحده لن يغير شيئاً. ومتتبع Debian يقول الشيء نفسه بوضوح: حزمة brotli متأثرة في bookworm وtrixie دون إصلاح حتى كتابة هذه السطور، وحزمة nodejs مصنفة unimportant مع ملاحظة «nodejs uses system provided brotli library». ولاحظ أيضاً أن Node 18 انتهى دعمه من المشروع الأصلي، ومع ذلك ما زالت Debian 12 تصلحه في حزمتها، فالذي يحدد هل نسختك مدعومة هو من بنى الحزمة لا المشروع الأصلي.

وحتى الإصدار الرسمي Official Release قد يخدعك

والحالة الثالثة مع Docker Image الرسمية لـ Node.js التي تحمل Brotli مدمجة فيها، حيث يقول سجل CVE إن نسخ Brotli من 1.2.0 حتى ما قبل 1.2.1 متأثرة. فلو سألت الإصدارين قبل التحديث وبعده عن نسخة Brotli:

docker run --rm node:24.21.0-bookworm-slim node -p "process.version + ' brotli=' + process.versions.brotli"
docker run --rm node:24.22.1-bookworm-slim node -p "process.version + ' brotli=' + process.versions.brotli"

v24.21.0 brotli=1.2.0
v24.22.1 brotli=1.2.0

فالإصدار 24.22.1 الذي تقول نشرة Node.js إنه يصلح الثغرة ما زال يعرض رقم Brotli القديم نفسه، لأن المشروع طبق تعديل الإصلاح على نسخته المدمجة دون أن يغير رقمها. والقاعدة التي تخرج بها من الحالات الثلاث: قارن نسخة الحزمة كاملة بنشرة الجهة التي بنت الحزمة، أي توزيعتك أو صاحب ال Docker Image أو المورد، ولا تقارن الرقم الأصلي بالنشرة الأصلية.

ترتيب الأولوية Prioritization: CVSS وEPSS وKEV

بعد أن تعرف أي سيرفر متأثر يأتي السؤال الثاني: بأي ثغرة تبدأ؟ فأداة الفحص على سيرفر واحد قديم قد تعطيك مئات النتائج، وقد رأينا في فحص ال Docker Images كيف يتجاوز العدد مئة نتيجة في Image واحدة. والترتيب يعتمد على ثلاث إشارات، ولكل واحدة سؤال تجيب عنه.

التقييم CVSS: ما أسوأ ما يمكن أن يحدث؟

نظام التقييم CVSS (Common Vulnerability Scoring System) يعطي الثغرة رقماً من 0 إلى 10 بحسب طريقة الوصول إليها وتعقيد الاستغلال والصلاحيات المطلوبة والأثر، والرقم الذي تراه في النشرات هو التقييم الأساسي Base Score، أي خطورة الثغرة في أسوأ إعداد ممكن دون أن يعرف شيئاً عن بيئتك. لذلك فإن مواصفة CVSS 4.0 تضيف مجموعات أخرى، منها مقاييس التهديد Threat ومقاييس البيئة Environmental، حيث تعدل أنت التقييم بحسب أهمية النظام عندك والحماية الموجودة حوله. وفي ثغرات هذا الأسبوع ترى الفرق بوضوح:

وحتى Oracle نفسها تكتب في جدول Java ضمن تحديث أكتوبر أن تقييماتها تفترض أن المستخدم يشغل Java بصلاحيات المدير كما هو شائع في Windows، وأن الأثر يصبح «Low» بدل «High» عندما لا يكون كذلك كما هو شائع في Linux، وهذا تعديل بيئي Environmental صريح من المورد.

احتمال الاستغلال EPSS: هل سيستغلها أحد قريباً؟

النظام EPSS (Exploit Prediction Scoring System) من منظمة FIRST يقدر احتمال أن تستغل الثغرة فعلاً خلال الثلاثين يوماً القادمة، برقم من 0 إلى 1 يتحدث كل يوم. فالثغرة CVE-2024-4577 في PHP على Windows احتمالها اليوم 0.99987، أي أنها تستغل فعلاً على نطاق واسع. أما ثغرة PHP الجديدة فلم يكن لها رقم في بيانات 21 أكتوبر أصلاً، وظهر رقمها 0.053 في بيانات 22 أكتوبر، لذلك لا تنتظر رقم EPSS لتتحرك في يومك الأول، فهو إشارة تأتي متأخرة بطبيعتها لأنها تعتمد على ما يرصد من نشاط.

قائمة KEV: هل استغلت فعلاً؟

قائمة CISA KEV (Known Exploited Vulnerabilities) هي أقوى إشارة عملية، لأن الثغرة لا تدخلها إلا بدليل على استغلالها في هجمات حقيقية، ومع كل ثغرة تاريخ إضافة وموعد نهائي للإصلاح تلتزم به الجهات الفدرالية الأمريكية بحسب التوجيه BOD 22-01. وفي نسخة 21 أكتوبر 2026 كان فيها 1754 ثغرة، ولم تكن ثغرات PHP وJava وNode الجديدة منها، بينما CVE-2024-4577 موجودة منذ 12 يونيو 2024 ومعلمة بأنها استخدمت في هجمات فدية Ransomware. وقاعدة العمل البسيطة أن أي ثغرة في KEV تمس خدمة عندك تتقدم على كل شيء آخر مهما كان تقييمها.

ويبقى بعد الإشارات الثلاث سؤال لا تجيب عنه أي قاعدة بيانات: ماذا يعني هذا السيرفر لك؟ فثغرة حرجة في سيرفر اختبار معزول أقل أهمية من ثغرة عالية في سيرفر يستقبل طلبات الإنترنت ويحمل بيانات العملاء. لذلك ستجد في المخطط أعلاه ثلاثة مستويات عملية: الآن خلال 24 ساعة، وهذا الأسبوع، ودورة التحديث العادية، ولكل مستوى شروط مكتوبة يتفق عليها الفريق قبل أن تصل النشرة القادمة.

دورة إدارة الثغرات: من الجرد Inventory إلى التحقق Verification

الآن بعد أن عرفنا من أين تأتي المعلومة وكيف نقرأها، كيف نحولها إلى عمل يومي؟ لنأخذ الطرق التي تجربها أغلب الفرق بالترتيب.

الطريقة البسيطة: نتابع الأخبار ونفحص يدوياً Manual Check

يقرأ أحد أعضاء الفريق خبر الثغرة، ثم يدخل إلى السيرفرات التي يتذكرها ويكتب php -v. وهذه الطريقة تفشل لثلاثة أسباب، فالذاكرة لا تعرف كل السيرفرات ولا كل ال Containers التي تحمل PHP داخلها، والمقارنة بالرقم تخطئ كما رأينا في Ubuntu وDebian، والنشرات التي لا تصل إلى الأخبار مثل نشرة Brotli لا يراها أحد أصلاً.

الطريقة الثانية: فحص شبكي Network Scan مرة في الشهر

والحل الثاني أن تشغل أداة فحص شبكي Network Scanner مثل OpenVAS على عناوين السيرفرات كل شهر. وهذا أفضل لأنه يرى ما هو مكشوف فعلاً على الشبكة، ولكن الفاحص الشبكي يخمن النسخة غالباً من رد الخدمة Banner، فيخطئ مع الإصلاحات المنقولة في الاتجاهين، ولا يرى المكتبات التي لا تفتح منفذاً مثل libbrotli1 أو Java داخل خدمة خلفية، وثغرة تنشر في اليوم الثاني من الشهر تنتظر عنده أربعة أسابيع.

الطريقة الصحيحة: دورة مستمرة Continuous Cycle من خمس خطوات

والطريقة الصحيحة أن تحول المسألة إلى دورة تعمل كل يوم، بحيث تكون إجابة سؤال «أي سيرفر متأثر؟» استعلاماً واحداً لا يوم عمل كاملاً:

1. الجرد Inventory: قائمة محدثة بكل سيرفر وكل Container وما يعمل فيه من حزم ونسخها الكاملة، ومن أين جاءت كل حزمة (من التوزيعة، أو من Docker Image رسمية، أو بنيتها بنفسك). وهذه القائمة تسمى في عالم البرمجيات SBOM (Software Bill of Materials).
2. المطابقة Matching: مقارنة الجرد بقاعدة بيانات الثغرات، بشرط أن تكون مطابقة حزم التوزيعة ببيانات التوزيعة نفسها، كما يفعل OSV وTrivy وGrype، لا برقم المشروع الأصلي.
3. ترتيب الأولوية Prioritization: KEV أولاً، ثم الحرج المكشوف للإنترنت، ثم بقية القائمة بحسب EPSS والتقييم وأهمية السيرفر.
4. الإصلاح Patch أو التخفيف Mitigation: التحديث هو الأصل، والتخفيف المؤقت لما لا تستطيع تحديثه الآن، بشرط أن يأتي من نشرة المورد وأن يكون له تاريخ انتهاء.
5. التحقق Verification: أن تتأكد أن النسخة الجديدة هي التي تعمل في الذاكرة، لا التي على القرص فقط، ثم تعيد المطابقة.

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

ماذا تفعل في أول 24 ساعة بعد نشرة حرجة Critical Advisory؟

لنفرض أن نشرة PHP وصلتك صباح الأربعاء، وعندك سيرفرات Debian وUbuntu وبعض ال Containers. والمخطط التالي يلخص الخطوات بالترتيب، ثم نمر عليها واحدة واحدة بالأوامر.

الخطوة الأولى: اقرأ النشرة الأصلية Advisory كاملة

اقرأ نشرة المورد نفسها، لا الخبر عنها، لأن التفاصيل التي تحدد أولويتك موجودة فيها فقط. فنشرة PHP للثغرة GHSA-w8hw-w9fx-j79w تقول إن تنفيذ الأوامر عن بعد أثبت عملياً ضد Apache مع mod_php بالإعدادات الافتراضية، وإن PHP-FPM قابل للإصابة بحسب تحليل الكود دون استغلال كامل منشور، وإن FrankenPHP غالباً مثل mod_php. وهذا وحده يغير ترتيبك، فسيرفر Apache مع mod_php أمام الإنترنت يأتي قبل سيرفر Nginx مع PHP-FPM، وكلاهما يصلح في اليوم نفسه.

الخطوة الثانية: حدد التعرض Exposure

هنا يظهر الفرق بين من عنده جرد ومن ليس عنده. فإن لم يكن عندك جرد مركزي فالأوامر التالية تجيب على كل سيرفر Debian أو Ubuntu، والمثال من سيرفر Debian 12 فيه PHP وNode.js وJava من مستودع التوزيعة:

dpkg -l | awk '/^ii/ && $2 ~ /^(php|nodejs|libbrotli|openjdk)/ {print $2, $3}'

والمخرج سوف يكون كما يلي:

libbrotli1:amd64 1.0.9-2+b6
nodejs 18.20.4+dfsg-1~deb12u3
openjdk-17-jre-headless:amd64 17.0.20.1+1-1~deb12u1
php-common 2:93
php8.2-cli 8.2.34-1~deb12u1
php8.2-common 8.2.34-1~deb12u1
php8.2-opcache 8.2.34-1~deb12u1
php8.2-readline 8.2.34-1~deb12u1

فهذا السيرفر متأثر بالثغرات الثلاث: PHP بالنسخة 8.2.34 والإصلاح في 8.2.35-1~deb12u1 بحسب متتبع Debian، وJava 17 من التوزيعة، ومكتبة Brotli التي يستخدمها nodejs.

وعلى توزيعات Red Hat يقابله rpm -qa 'php*' 'java-*' 'nodejs*'. ثم اسأل عن طريقة تشغيل PHP لأنها تغير الأولوية كما قرأنا في النشرة، والمثال التالي من Docker Image الرسمية php:8.4.26-apache:

docker run --rm php:8.4.26-apache bash -c "php -v | head -1; apache2ctl -M 2>/dev/null | grep -i php"

PHP 8.4.26 (cli) (built: Oct 21 2026 00:31:19) (NTS)
 php_module (shared)

فوجود php_module يعني أن PHP يعمل داخل Apache بطريقة mod_php، وهي الحالة التي أثبت فيها الاستغلال، والنسخة 8.4.26 أقدم من 8.4.27 التي تحمل الإصلاح، وهنا لا يوجد Backport لأن ال Image الرسمية تبني PHP من المصدر الأصلي، فالرقم هنا صادق. ولا تنس ال Containers، فالأمر docker ps --format '{{.Names}} {{.Image}}' على كل سيرفر يبين أي Image تعمل، وكل Image فيها نسختها الخاصة من PHP أو Java أو Node لا تتحدث مع تحديث السيرفر.

وأما Java فالسؤال الأول هو من أين جاءت، فالمثال التالي من Docker Image رسمية لـ Eclipse Temurin 21:

docker run --rm eclipse-temurin:21.0.12.1_1-jre bash -c "java -version 2>&1 | head -2; keytool -list -cacerts -storepass changeit 2>/dev/null | grep -ci emsign"

openjdk version "21.0.12.1" 2026-08-18 LTS
OpenJDK Runtime Environment Temurin-21.0.12.1+1 (build 21.0.12.1+1-LTS)
4

واخترنا البحث عن شهادات emSign لأن صفحة Red Hat للثغرة تربطها بشهادات وسيطة ضعيفة أصدرتها eMudhra، وتقول إن OpenJDK الذي يحمل مخزن شهاداته Truststore الخاص، مثل هذه ال Image، يتحدث بإصدار Java جديد، بينما حزم OpenJDK في RHEL تأخذ الإصلاح من حزمة ca-certificates. ونشرة Oracle نفسها لا تذكر هذه التفاصيل، لذلك اعتبرها تفسير Red Hat حتى يؤكدها مصدر آخر، والمهم هنا هو المبدأ: مكان الإصلاح يختلف بحسب طريقة بناء Java عندك.

الخطوة الثالثة: التخفيف المؤقت Mitigation من النشرة فقط

إذا لم تستطع التحديث خلال ساعات، بسبب اختبار مطلوب أو نافذة صيانة، فخذ التخفيف من نشرة المورد ولا تخترعه. ونشرتا PHP مثال جيد لأنهما صريحتان في حدود كل تخفيف:

• إذا كان التطبيق لا يستقبل نماذج multipart (رفع ملفات) فامنع هذه الطلبات في ال Reverse Proxy قبل أن تصل إلى PHP، بحسب نص النشرة.
• النشرة الأولى تذكر ضبط memory_limit=-1 إدارياً كتخفيف أساسي، وتقول بوضوح إنه ليس تخفيفاً كاملاً، وإن على كل عامل Worker أن يعاد تشغيله، وتحذر من استخدام RLIMIT_AS لأنه يفتح المسار المتأثر نفسه. وهذا الخيار يرفع حد الذاكرة عن كل طلب، فلا تقم به دون حد للذاكرة على مستوى ال Container أو cgroup.
• النشرة الثانية GHSA-6wmf-4rv5-p3rp تقترح session.upload_progress.enabled=0 إن لم تكن تستخدمه، وfatal_error_backtraces=0 في PHP 8.5، وتقول إنه لا يوجد تخفيف عام كامل.
• نشرتا Oracle وNode.js لا تذكران تخفيفاً، والحل الوحيد فيهما هو التحديث، وحتى ذلك الحين قلل الوصول إلى الخدمة من الشبكة قدر الإمكان.

وكل تخفيف تضعه سجله مع تاريخ انتهاء، لأن التخفيف الذي يبقى بعد التحديث ينسى، ثم يفاجئك بعد سنة بسلوك غريب لا يعرف أحد سببه.

الخطوة الرابعة: الإصلاح Patch

على Debian وUbuntu حدث الحزم المتأثرة وحدها بدل ترقية النظام كاملاً في يوم الطوارئ، لأن ذلك يقلل ما يمكن أن يتغير:

apt-get update
apt-get install --only-upgrade php8.2-cli php8.2-common php8.2-opcache php8.2-readline

وأما ال Containers فلا يصلحها تحديث السيرفر، وإنما تعيد بناء ال Image على Base Image جديدة بالأمر docker build --pull أو تنتقل إلى الوسم Tag الذي يحمل الإصلاح مثل php:8.4.27-apache، ثم تعيد إنشاء ال Container. وجرب التحديث في بيئة اختبار أولاً إن كانت عندك، فحتى التحديث الأمني قد يغير سلوكاً يعتمد عليه تطبيقك، وهذا مطلب صريح في ضوابط الهيئة كما سيأتي.

الخطوة الخامسة: التحقق Verification، والخطأ الذي يقع فيه الجميع

تحديث الحزمة يغير الملفات على القرص، لكن العملية التي بدأت قبل التحديث ما زالت تعمل بالكود القديم في الذاكرة حتى تعيد تشغيلها. ولنر ذلك عملياً على سيرفر Debian 12 كانت عليه الحزم القديمة، حيث نشغل عملية PHP طويلة، ثم نحدث PHP، ثم نسأل الأداة needrestart عن العمليات التي تعمل بملفات قديمة:

php -S 127.0.0.1:8080 -t /tmp >/dev/null 2>&1 &
PHP_PID=$!
ls -l /proc/$PHP_PID/exe | awk '{print $NF}'

/usr/bin/php8.2

ثم حدثنا PHP بأمر apt-get install --only-upgrade نفسه الذي في الخطوة السابقة، وسألنا عن نسخة الحزمة وعن الملفات التي تستخدمها العملية:

dpkg-query -W -f='${Package} ${Version}\n' php8.2-cli
ls -l /proc/$PHP_PID/exe | awk '{print $(NF-1), $NF}'
grep '(deleted)' /proc/$PHP_PID/maps | awk '{print $6, $7}' | sort -u

php8.2-cli 8.2.35-1~deb12u1
/usr/bin/php8.2 (deleted)
/dev/zero (deleted)
/usr/bin/php8.2 (deleted)
/usr/lib/php/20220829/calendar.so (deleted)
/usr/lib/php/20220829/ctype.so (deleted)
/usr/lib/php/20220829/exif.so (deleted)
/usr/lib/php/20220829/ffi.so (deleted)
/usr/lib/php/20220829/fileinfo.so (deleted)
/usr/lib/php/20220829/ftp.so (deleted)
/usr/lib/php/20220829/gettext.so (deleted)
/usr/lib/php/20220829/iconv.so (deleted)
/usr/lib/php/20220829/opcache.so (deleted)
/usr/lib/php/20220829/pdo.so (deleted)
/usr/lib/php/20220829/phar.so (deleted)
/usr/lib/php/20220829/posix.so (deleted)
/usr/lib/php/20220829/readline.so (deleted)
/usr/lib/php/20220829/shmop.so (deleted)
/usr/lib/php/20220829/sysvmsg.so (deleted)
/usr/lib/php/20220829/sysvsem.so (deleted)
/usr/lib/php/20220829/sysvshm.so (deleted)
/usr/lib/php/20220829/tokenizer.so (deleted)

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

kill $PHP_PID
php -S 127.0.0.1:8080 -t /tmp >/dev/null 2>&1 &
PHP_PID=$!
ls -l /proc/$PHP_PID/exe | awk '{print $NF}'
grep '(deleted)' /proc/$PHP_PID/maps | awk '{print $6, $7}' | sort -u

/usr/bin/php8.2
/dev/zero (deleted)

في المخرج أعلاه لاحظ التالي:

• اختفت كلمة (deleted) من الملف التنفيذي Executable ومن الإضافات Extensions، فالعملية الجديدة تعمل بالنسخة المصلحة.
• السطر /dev/zero (deleted) بقي في الحالتين، وهو ذاكرة مشتركة Shared Memory يحجزها OPcache بهذه الطريقة وليس ملفاً قديماً، فلا تعتبره دليلاً على أن العملية لم تتحدث.
• على السيرفرات التي تعمل بـ systemd تقوم الأداة needrestart بهذا الفحص نيابة عنك، والأمر needrestart -r l يعرض الخدمات التي تحتاج إعادة تشغيل دون أن يعيد تشغيلها، وهي تربط العمليات بالخدمات عن طريق systemd، لذلك افحص العمليات داخل ال Containers عن طريق /proc كما فعلنا، أو أعد إنشاء ال Container من Image جديدة.

وبعد إعادة التشغيل أعد المطابقة على السيرفر نفسه بالأداة التي تستخدمها، أو بطلب OSV الذي سنراه في التجربة العملية، وسجل ما فعلت: أي سيرفر، وأي نسخة قبل وبعد، ومتى، ومن نفذ، لأن هذا السجل هو ما ستحتاجه في المراجعة القادمة.

تجربة عملية Lab: نسأل OSV وNVD وKEV وEPSS

كل المصادر التي تحدثنا عنها لها واجهات برمجية API مفتوحة دون تسجيل، وهذا يعني أنك تستطيع أن تبني فحصاً بسيطاً لسيرفراتك بأداتي curl وjq فقط، وهي أيضاً الطريقة التي تفهم بها ما تفعله أدوات الفحص الكبيرة من الداخل. وقد شغلنا الأوامر التالية من Container مؤقت فيه curl وjq في 22 أكتوبر 2026 بين الساعة 14:00 و14:45 بتوقيت UTC، وأرقامك سوف تختلف لأن هذه البيانات تتحدث باستمرار.

المطابقة Matching بحسب التوزيعة مع OSV

قاعدة OSV تجمع نشرات التوزيعات ومستودعات اللغات بصيغة واحدة، وتقبل اسم الحزمة والنظام البيئي Ecosystem والنسخة الكاملة. لنسأل عن حزمة PHP في Ubuntu 24.04 قبل الإصلاح وبعده:

for v in 8.3.6-0ubuntu0.24.04.12 8.3.6-0ubuntu0.24.04.13; do
  echo "--- $v"
  curl -s https://api.osv.dev/v1/query \
    -d "{\"package\":{\"name\":\"php8.3\",\"ecosystem\":\"Ubuntu:24.04:LTS\"},\"version\":\"$v\"}" \
    | jq -r '.vulns[]?.id'
done

--- 8.3.6-0ubuntu0.24.04.12
UBUNTU-CVE-2026-109618
UBUNTU-CVE-2026-109619
UBUNTU-CVE-2026-17545
USN-8948-1
--- 8.3.6-0ubuntu0.24.04.13
UBUNTU-CVE-2026-17545

في المخرج أعلاه لاحظ التالي:

• الفرق بين النسختين هو الرقم الأخير فقط (.12 و.13)، والرقم الأصلي 8.3.6 واحد، ومع ذلك اختفت ثغرتا أكتوبر من النسخة الثانية، وهذا هو ال Backport الذي رأيناه في سجل تغييرات الحزمة.
• بقيت UBUNTU-CVE-2026-17545 في النسختين، فهذه ثغرة أخرى لها حالتها الخاصة، ولا يعني ظهورها أن التحديث فشل.
• المعرفات تبدأ بـ UBUNTU وUSN لأن مصدرها نشرات Ubuntu نفسها، لا سجل CVE العام.

مطابقة جرد Inventory سيرفر Debian كامل

والآن نأخذ الجرد الذي استخرجناه من سيرفر Debian 12 في الخطوة الثانية ونسأل OSV عن كل حزمة، مع إظهار ثغرات أكتوبر فقط من النتائج. ولاحظ أننا نسأل عن الحزمة المصدر Source Package، فالحزمة libbrotli1 مصدرها brotli وphp8.2-cli مصدرها php8.2:

for p in php8.2:8.2.34-1~deb12u1 nodejs:18.20.4+dfsg-1~deb12u3 brotli:1.0.9-2 openjdk-17:17.0.20.1+1-1~deb12u1; do
  curl -s https://api.osv.dev/v1/query \
    -d "{\"package\":{\"name\":\"${p%%:*}\",\"ecosystem\":\"Debian:12\"},\"version\":\"${p#*:}\"}" \
    | jq -r --arg p "$p" '"\($p): \(.vulns | length) total, " + ([.vulns[].id | select(test("109618|109619|111497|91403"))] | join(" "))'
done

php8.2:8.2.34-1~deb12u1: 2 total, DEBIAN-CVE-2026-109618 DEBIAN-CVE-2026-109619
nodejs:18.20.4+dfsg-1~deb12u3: 14 total, DEBIAN-CVE-2026-111497
brotli:1.0.9-2: 1 total, DEBIAN-CVE-2026-111497
openjdk-17:17.0.20.1+1-1~deb12u1: 40 total, DEBIAN-CVE-2026-91403

وهنا تجد الحالات الأربع في سيرفر واحد: PHP متأثر وله إصلاح، وJava متأثر مع 39 ثغرة أخرى من تحديث Oracle الفصلي، وBrotli متأثر في حزمتين. ولاحظ أن رقم Brotli الذي سألنا عنه هو 1.0.9-2 وليس 1.0.9-2+b6 المثبت، لأن اللاحقة +b6 تعني إعادة بناء Binary Rebuild للحزمة نفسها دون تغيير المصدر، والمطابقة تتم على نسخة المصدر.

التقييمات Scores من NVD

for c in CVE-2026-91403 CVE-2026-109618 CVE-2026-111497; do
  curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=$c" \
    | jq -r --arg c "$c" 'if .totalResults == 0 then "\($c): not in NVD yet"
        else .vulnerabilities[0].cve | "\(.id) \(.vulnStatus): " + ([.metrics[][]? | select(.cvssData) | "\(.source) v\(.cvssData.version)=\(.cvssData.baseScore)"] | join(", ")) end'
  sleep 6
done

CVE-2026-91403 Received: [email protected] v3.1=9.1
CVE-2026-109618 Modified: [email protected] v4.0=9.2, [email protected] v3.1=9.8
CVE-2026-111497 Received: [email protected] v4.0=9.2

في المخرج أعلاه لاحظ التالي:

• ثغرة PHP هي الوحيدة التي حللها فريق NVD وأضاف لها تقييمه 9.8، أما Java وBrotli فما زالتا بحالة Received، أي أن التقييم الوحيد هو تقييم الجهة المصدرة.
• عندما شغلنا الأمر نفسه في وقت أبكر من اليوم نفسه كان سطر Brotli يقول not in NVD yet، فالسجل وصل NVD الساعة 14:17 بتوقيت UTC، بعد يوم من إصدار إصلاح Node.js.
• الأمر sleep 6 موجود لأن واجهة NVD تحد عدد الطلبات لمن لا يملك مفتاح API، فإذا أرسلت طلبات متتالية بسرعة سوف تحصل على رفض مؤقت.

هل استغلت؟ قائمة KEV

curl -s -o kev.json https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
jq -r '"KEV catalog \(.catalogVersion): \(.count) entries"' kev.json
for c in CVE-2026-91403 CVE-2026-109618 CVE-2026-109619 CVE-2026-111497 CVE-2024-4577; do
  jq -r --arg c "$c" '[.vulnerabilities[] | select(.cveID == $c)][0]
      | if . == null then "\($c): not in KEV" else "\(.cveID): added \(.dateAdded), due \(.dueDate), ransomware: \(.knownRansomwareCampaignUse)" end' kev.json
done

KEV catalog 2026.10.21: 1754 entries
CVE-2026-91403: not in KEV
CVE-2026-109618: not in KEV
CVE-2026-109619: not in KEV
CVE-2026-111497: not in KEV
CVE-2024-4577: added 2024-06-12, due 2024-07-03, ransomware: Known

فالقائمة ملف JSON واحد تستطيع تنزيله كل يوم ومقارنته بجردك، وأي تطابق فيه يعني أن الثغرة تستغل الآن في مكان ما. ولاحظ أن الثغرة القديمة CVE-2024-4577 كان موعدها النهائي بعد ثلاثة أسابيع من إضافتها، فإن كان عندك PHP قديم على Windows فهذه أولويتك قبل ثغرات أكتوبر.

احتمال الاستغلال EPSS

curl -s "https://api.first.org/data/v1/epss?cve=CVE-2026-109618,CVE-2026-91403,CVE-2024-4577" \
  | jq -r '"returned \(.total)", (.data[] | "\(.cve) epss=\(.epss) percentile=\(.percentile) date=\(.date)")'

returned 3
CVE-2026-91403 epss=0.003920000 percentile=0.321490000 date=2026-10-22
CVE-2026-109618 epss=0.053070000 percentile=0.925630000 date=2026-10-22
CVE-2024-4577 epss=0.999870000 percentile=0.999840000 date=2026-10-22

وعندما شغلنا الطلب نفسه في وقت أبكر من اليوم نفسه كانت بيانات اليوم السابق هي المتاحة، فرجع رقم CVE-2024-4577 وحده ولم يظهر أي رقم لثغرتي PHP وJava. والقراءة الصحيحة للأرقام: احتمال 0.053 يعني نحو 5% خلال ثلاثين يوماً، لكن المئين Percentile 0.926 يعني أنها أعلى من 92% من كل الثغرات المسجلة، وهذا مرتفع لثغرة عمرها يوم واحد.

تنبيهات Alerts الهيئة الوطنية للأمن السيبراني وضوابط ECC

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

وأما المطلب فهو المكون 2-10 «إدارة الثغرات» في الضوابط الأساسية للأمن السيبراني ECC-2:2024، حيث يطلب الضابط 2-10-3 أن تشمل متطلبات إدارة الثغرات كحد أدنى ما يلي، وهي ترجمتنا لنص النسخة الإنجليزية، والنسخة العربية هي المرجع الملزم:

• 2.10.3.1: تقييم الثغرات واكتشافها بشكل دوري.
• 2.10.3.2: تصنيف الثغرات بحسب خطورتها.
• 2.10.3.3: معالجة الثغرات بحسب تصنيفها والمخاطر السيبرانية المرتبطة بها.
• 2.10.3.4: إدارة حزم التحديثات والإصلاحات Patch Management، والتحقق من سلامتها وفعاليتها في بيئة غير بيئة الإنتاج قبل تطبيقها.
• 2.10.3.5: التواصل والاشتراك مع مصادر موثوقة للثغرات الجديدة والمحدثة.

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

أخطاء شائعة Common Mistakes

• مقارنة php -v أو java -version بالنشرة الأصلية على سيرفرات التوزيعات: والسبب أن التوزيعة تنقل الإصلاح دون تغيير الرقم، فتطارد ثغرات مصلحة وتغفل عن غيرها.
• تحديث السيرفر ونسيان ال Containers: كل Image تحمل نسختها من PHP أو Java أو Node، ولا يصلحها إلا إعادة البناء وإعادة الإنشاء.
• التحديث دون إعادة التشغيل: العملية القديمة تبقى تعمل بالكود المتأثر، كما رأينا مع needrestart.
• الاعتماد على NVD وحدها: لأنها تتأخر، ولأن ثغرة Brotli لم تكن فيها طوال يوم بعد الإصلاح.
• ترتيب العمل بتقييم CVSS وحده: فالتقييم الأساسي لا يعرف أن الخدمة داخلية أو أن الإعداد المتأثر غير مستخدم، ولا يعرف أن الثغرة في KEV.
• تخفيف مؤقت بلا تاريخ انتهاء: يبقى سنوات، ويتحول إلى إعداد غريب لا يجرؤ أحد على إزالته.
• الإصدارات المنتهية End-of-Life: نشرة Node.js تقول صراحة إن الخطوط المنتهية متأثرة دائماً، وPHP 8.2 ينتهي دعمه في 31 ديسمبر 2026، فخطط للترقية قبل أن تصبح كل نشرة جديدة مشكلة بلا حل.

الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

• المعرف CVE يوحد الاسم فقط، وتفاصيل الإصلاح الذي يناسب سيرفرك في نشرة من بنى الحزمة: توزيعتك أو صاحب ال Docker Image أو المورد.
• رقم الإصدار يخدعك على التوزيعات: PHP 8.3.6 في Ubuntu 24.04 كان مصلحاً، وNode.js في Debian 12 يأخذ Brotli من مكتبة النظام، وNode.js 24.22.1 المصلح ما زال يعرض Brotli 1.2.0.
• التقييم الأساسي CVSS يصف أسوأ حالة، والثغرة الواحدة لها 9.2 و9.8 و8.1 بحسب من قيمها، وبيئتك هي التي تحسم.
• KEV تقول هل استغلت فعلاً، وEPSS يقول هل ستستغل قريباً، وكلاهما قد يتأخر في اليوم الأول، فلا تنتظرهما لثغرة حرجة مكشوفة للإنترنت.
• الدورة خمس خطوات: الجرد ثم المطابقة ثم الترتيب ثم الإصلاح أو التخفيف ثم التحقق، وأضعف خطوة عند أغلب الفرق هي الجرد.
• الإصلاح لا يكتمل قبل إعادة تشغيل العملية التي تستخدم الكود القديم، وقبل إعادة المطابقة.

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

دليلأدوات إدارة الثغرات Vulnerability Management مفتوحة المصدرأي أداة مفتوحة المصدر تجرد سيرفراتك وتطابقها مع الثغرات وتنبهك بالجديد، وماذا رأى Trivy وGrype فعلاً في ثغرات أكتوبر.دليلSCA: كيف تجد الثغرات المعروفة في مكتبات مشروعككيف تجد أداة فحص الاعتماديات SCA المكتبات المصابة في مشروعك، ولماذا تختلف نتائج الأدوات، وكيف تبقي مكتباتك محدثة.دليلفحص ال Docker Images وملفات البنية ككود IaCماذا يرى فاحص الثغرات داخل ال Docker Image وما الذي يفوته، وكيف تختار Base Image أصغر وتجعل الفحص بوابة في خط CI.دليلأمن سلسلة التوريد البرمجية Software Supply Chain للمبتدئينكل ما بين كود غيرك وسيرفرك قد يحمل كود المهاجم، وهنا تعرف التهديدات الحقيقية بحوادث موثقة والدفاع المناسب لكل حلقة.دليلتأمين سيرفر VPS على Ubuntu من أول دخولقبل أن تثبت أي تطبيق على سيرفرك الجديد، هذه الخطوات تغلق أبرز الثغرات وأولها الدخول بمفتاح SSH بدل كلمة المرور.

سجل التحديثات

• أكتوبر 2026: كتابة المقال بعد نشرات 21 أكتوبر 2026 من Oracle وPHP وNode.js، والتحقق من كل ثغرة في صفحة المورد وسجل CVE.org وNVD ومتتبعات Debian وUbuntu وRed Hat وقائمة CISA KEV وEPSS، وتنفيذ الأمثلة على Docker Images رسمية لـ Ubuntu 24.04 وDebian 12 وNode.js وPHP وEclipse Temurin.