:: vBspiders Professional Network :: - 🔥 ثغرة يناير 2026 الأخطر على كثير من بيئات السيرفرات: OpenSSL CVE-2025-15467 (احتمال DoS وقد يصل لـ RCE حسب السيناريو)

CVE-2025-15467 في OpenSSL: تحليل تقني وتشغيلي معمّق لثغرة تجاوز مكدس في CMS AuthEnvelopedData

https://forum.secspiders.com/uploads...8c3d3f19c.jpeg

تاريخ إعداد التقرير: 2 فبراير 2026 (Asia/Amman).
نطاق التقرير: تحليل CVE-2025-15467 حصراً، مع ربطه بالسياق التشغيلي الواقعي على السيرفرات، وتقديم إرشادات تقييم/تخفيف/استجابة للحوادث بصياغة مناسبة للنشر في منتديات أمن سيبراني احترافية.
سياق الثغرة والملخص التنفيذي

أصدرت مؤسسة 1 في 27 يناير 2026 نشرة أمنية تُعرّف CVE-2025-15467 بوصفها ثغرة High ناتجة عن Stack Buffer Overflow عند تحليل بنية CMS AuthEnvelopedData عند استخدام خوارزميات AEAD (مثل AES-GCM)، حيث يتم نسخ IV المرمّز داخل معاملات ASN.1 إلى مخزن ثابت على الـ stack دون تحقق صارم من الطول. 2
على مستوى التقييم الكمي للمخاطر، سجل 3 (ضمن إثراء CISA-ADP) تقييم CVSS v3.1 = 9.8 (Critical) مع متجه هجوم شبكي بدون امتيازات أو تفاعل مستخدم (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). 1
الخلاصة التشغيلية التي تهم مديري الأنظمة: هذه ليست “ثغرة TLS عامة” بالمعنى التقليدي. الخطر الأعلى يظهر عندما تكون لديك خدمة/تطبيق على السيرفر يقبل أو يعالج CMS/PKCS#7 غير موثوق (مثل بوابات S/MIME أو خدمات استيراد شهادات/تشفير/فك تشفير تعتمد CMS)، لأن مسار العطب يحدث قبل التحقق من المصادقة/الوسم (tag)، ما يجعل إحداث التعطل (DoS) قابلاً للتحقق حتى دون مفاتيح صحيحة، بينما تبقى RCE “ممكنة” لكنها حسّاسة جداً لبيئة البناء والتدابير الدفاعية. 1
تشريح تقني لـ CVE-2025-15467

نقطة الانطلاق لفهم الثغرة بدقة هي أن CMS AuthEnvelopedData يجمع بين التشفير + التوثيق، وغالباً ما يظهر في سلاسل معالجة S/MIME/PKCS#7. في حالة اختيار AEAD مثل AES-GCM، يحمل الـ IV ضمن معاملات ASN.1 إلى جانب النص المُشفّر. 2
المشكلة التقنية الجوهرية (كما وثقتها النشرة الأمنية وشرح التحليل الفني) هي:

يتم استخراج طول IV من معامل ASN.1 ثم يُستخدم هذا الطول لاحقاً في عملية نسخ إلى Buffer ثابت الطول على الـ stack. 1
في التحليل الذي قدّمه 1، يظهر أن الخلل مرتبط بكيفية استدعاء دالة مساعدة ASN.1 بحيث يمكن أن تُرجع طولاً أكبر من الحد الأقصى (EVP_MAX_IV_LENGTH)، ثم يُستكمل النسخ باستخدام هذا الطول، ما يؤدي إلى الكتابة خارج حدود المكدس (out-of-bounds write). 4
حيث أن هذا التسلسل يحدث قبل المصادقة (قبل التحقق من الـ tag)، يصبح بالإمكان الحصول على بدائية (primitive) خطرة: المهاجم يتحكم في الطول وفي المحتوى المنسوخ إلى المكدس، وهو السبب الذي يرفع الحساسية النظرية تجاه RCE بالرغم من أن DoS هو الأثر الأكثر واقعية في كثير من البيئات. 4

أما من زاوية “ما الذي تغيّر في الإصلاح؟” فمرجع الإصلاح (commit) يوضح منطقاً دفاعياً مباشراً: جعل النسخ إلى Buffer المكدس يتم بحد أعلى صارم (EVP_MAX_IV_LENGTH) مع رفض أي طول يتجاوزه. 5
نقطة مهمة عادة تُساء قراءتها: النشرة الأمنية تؤكد أن وحدات FIPS في فروع 3.x غير متأثرة لأن تنفيذ CMS خارج حدود وحدة FIPS. هذا التفصيل له أثر مباشر على تقييم المخاطر في البيئات المنظمة (regulated) التي تعتمد FIPS Providers. 1
تحليل الأثر وقابلية الاستغلال على السيرفرات

التقييم الاحترافي هنا يجب أن يفرّق بين “وجود OpenSSL على السيرفر” وبين “وجود سطح هجوم قابل للوصول”.
أولاً، التمييز بين TLS وبين CMS/PKCS#7 Reachability:
النص الرسمي يذكر صراحة أن الأنظمة المتأثرة هي “التطبيقات والخدمات التي تعالج CMS أو PKCS#7 غير موثوق باستخدام AEAD” (مثل S/MIME AuthEnvelopedData). إذا كان دور OpenSSL لديك محصوراً في TLS handshake الاعتيادي ولا توجد وظائف parsing لـ CMS غير موثوق، فغالباً لن تكون الثغرة قابلة للوصول عن بُعد في سيناريوهات ويب تقليدية. 1
ثانياً، DoS مقابل RCE:

DoS: الانهيار (Crash) نتيجة تلف المكدس هو الأثر الأكثر توقعاً ميدانياً، خصوصاً إذا كانت لديك خدمة تعالج inputs غير موثوقة بصورة متكررة (بوابة بريد/فحص مرفقات/خدمة تحقق). النشرة الأمنية نفسها تذكر DoS صراحة. 2
RCE: النشرة الأمنية وNVD تذكران أن RCE “ممكنة” اعتماداً على عوامل المنصة وحماية المترجم/البيئة. 1
من جهة البحث التطبيقي، يشير تقرير 1 إلى أن فريقهم استطاع تحقيق تنفيذ كود في بيئة مختبرية، مع التأكيد أن تجاوز تدابير مثل Stack Canaries وASLR وDEP قد يتطلب شروطاً إضافية (مثل معلومات تسريبية/اختلافات build). 6

ثالثاً، العوامل البيئية التي تغيّر تقييم المخاطر (خبرة تشغيلية “متراكمة عبر العقود” تؤكد أنها غالباً أهم من CVSS نفسه):

مدى تفعيل hardening في حِزم التوزيعة (stack protector، PIE، relro، CET/CFI حيث يتوفر). النشرة الرسمية تُلمّح إلى اعتماد الاستغلال على “toolchain mitigations”. 1
طبيعة المنتج: الأجهزة المدمجة/بوابات البريد/الأجهزة الأمنية قد تبني OpenSSL بإعدادات مختلفة، وأحياناً تشغّل parsing في مسارات شديدة الحساسية. 4

رابعاً، لماذا تُعامل كـ “حرجة” رغم أن OpenSSL صنّفتها High؟
الفجوة بين “High” لدى OpenSSL وبين “Critical 9.8” في تقييم CISA-ADP على NVD هي مثال كلاسيكي على أن التصنيف يمكن أن يتغير بناءً على افتراضات الأثر والانتشار:

NVD يعرض متجه CVSS بآثار C/I/A عالية. 1
بالمقابل، 7 تعرض لهذا CVE تقديراً مختلفاً (CVSS 7.5 وبمتجه ينسب الأثر إلى توفر الخدمة فقط C:N/I:N/A:H) مع إظهار حالة إصلاح مختلفة حسب Amazon Linux. هذا يذكّرنا أن بعض البائعين يقيّمون “الأثر الواقعي لديهم” وليس الأثر النظري العام. 8

النطاق المتأثر والتوزيعات والأنظمة والبرمجيات المضمّنة

على مستوى upstream، تُحدد صفحة الثغرة في سجل ثغرات OpenSSL نطاقات التأثر بشكل واضح حسب الفروع:

3.6.0 إلى ما قبل 3.6.1
3.5.0 إلى ما قبل 3.5.5
3.4.0 إلى ما قبل 3.4.4
3.3.0 إلى ما قبل 3.3.6
3.0.0 إلى ما قبل 3.0.19 7

النشرة الأمنية تؤكد كذلك أن OpenSSL 1.1.1 و1.0.2 غير متأثرين بـ CVE-2025-15467 تحديداً. 2
أما على مستوى downstream (التوزيعات والبائعين)، فالنقطة المهنية هنا هي: رقم إصدار OpenSSL الظاهر على نظامك قد لا يساوي "الإصدار upstream"؛ لأن كثيراً من التوزيعات تقوم بعمل backport للإصلاح ضمن نفس رقم الإصدار أو مع زيادات طفيفة في رقم الحزمة.
جدول مرجعي سريع

البيانات التالية تلخص “المسار” بين upstream وdownstream (أمثلة عملية منتقاة) استناداً إلى نشرات رسمية لكل جهة: 7
الفئةما الذي يهم عملياًأمثلة من مصادر رسميةUpstream OpenSSLمعرفة الحد الأدنى للإصدار المُصلَح لكل فرع3.0.19 / 3.3.6 / 3.4.4 / 3.5.5 / 3.6.1 7Debianمعرفة “نسخة الحزمة” المُصححة لكل إصدار توزيعةbookworm: 3.0.18-1deb12u2، trixie: 3.5.4-1deb13u2، bullseye: 1.1.1w-0+deb11u4 (غير متأثر أساساً بالـ CVE لكنه ضمن جدول الإصلاحات/التتبع) 9Ubuntuالتحديث عبر USN مع حزم backported24.04 LTS: 3.0.13-0ubuntu3.7، 22.04 LTS: 3.0.2-0ubuntu1.21، 25.10: 3.5.3-1ubuntu3 3Red Hat (RHEL)الاعتماد على RHSA/errata وحزمة openssl-libsمثال RHEL 9 عبر RHSA-2026:1473 يتضمن إصلاح CVE-2025-15467 ضمن تحديث openssl (مثل 3.5.1-7.el9_7) 10SUSEتطبيق patch عبر zypper/YaST وتتبّع الحد الأدنى للحزممثال SUSE-SU-2026:0312-1 يذكر CVE-2025-15467 ضمن openssl-3، مع إصدارات حزم محددة (مثل 3.1.4-150600.5.42.1 في Leap/SLES SP6) 11Amazon Linuxاختلاف الحالة حسب خط الإصدارAL2: openssl “Not Affected”؛ AL2023: openssl “Pending Fix” (في وقت نشر الصفحة) 8Google Cloudنشرات خدمات/منتجات تُحيل للـ CVEنشرة GCP-2026-006 تعتبر CVE-2025-15467 “الأهم” ضمن ثغرات OpenSSL، وتربط بإرشادات تخص منتجات Google Cloud 12

البرمجيات المضمّنة/الربط الساكن

خطر overlooked شائع في الحوادث الواقعية: وجود OpenSSL مضمّن داخل runtime أو مرتبط statically داخل تطبيق/حاوية، ما يجعل تحديث حزمة openssl على النظام غير كافٍ.

وثّق 6 صراحة أن CVE-2025-15467 لا يؤثر على Node.js لأن Node.js لا يستخدم CMS APIs أصلاً، وهو مثال مهم على أن “الاعتماد على OpenSSL” لا يعني تلقائياً التعرض لهذه الثغرة بعينها، وأن التقييم يجب أن يكون على مستوى سطح API المستخدم فعلياً. 13
تقرير Datadog يذكّر أيضاً بأن بعض runtimes قد تأتي بنسختها الخاصة من OpenSSL، وأن التحديث في هذه الحالة يجب أن يكون على مستوى الـ runtime/الصورة وليس فقط على مستوى نظام التشغيل. 4

التقييم الميداني والكشف عن التعرض

التقييم الاحترافي للتعرض (Exposure) يجب أن يُدار كتمرين “إثبات قابلية الوصول” وليس “مجرد إثبات وجود إصدار متأثر”. فيما يلي منهجية عملية قابلة للتطبيق خلال ساعة في معظم البيئات.
حصر الإصدارات بصورة موثوقة

أوامر أولية (لينكس):
bash

openssl version -a
لتحديد حزمة النظام (المهم في بيئات backport):
Debian/Ubuntu:
bash

dpkg -l | egrep '^(ii)\s+(openssl|libssl|libcrypto)' apt-cache policy openssl | sed -n '1,20p'
RHEL/CentOS/Alma/Rocky:
bash

rpm -qa | egrep '^openssl|^openssl-libs|^openssl-devel' dnf info openssl openssl-libs | sed -n '1,80p'
SUSE/openSUSE:
bash

rpm -qa | egrep '^openssl|^libopenssl' zypper info -t package openssl-3 libopenssl3 | sed -n '1,80p'
تحديد الخدمات التي “تجلب” مكتبات OpenSSL فعلياً

الخطوة التالية: معرفة من يرتبط بـ libcrypto/libssl (ديناميكياً).
لكل عملية PID محددة:
bash

sudo lsof -p <PID> | egrep 'libcrypto|libssl'
لملف ثنائي (binary) محدد:
bash

ldd /path/to/binary | egrep 'libcrypto|libssl'
ملاحظة تشغيلية: هذه الطريقة لن تكشف الربط الساكن. إذا شككت بالربط الساكن (خصوصاً في appliances/containers):

افحص الـ ELF:

bash

file /path/to/binary readelf -d /path/to/binary | egrep 'NEEDED|RUNPATH|RPATH'
أسئلة تشغيلية تحسم “قابلية الوصول” بسرعة

هذه الأسئلة هي لبّ التحليل، لأنها تحدد هل الثغرة reachable:

هل لديك بوابة بريد/Email Security Gateway تقوم بفك/تحليل رسائل S/MIME أو PKCS#7 inbound من الإنترنت؟ 4
هل لديك تطبيق ويب/خدمة API تستقبل ملفات CMS/PKCS#7 (أو ما يعادلها) وتحللها server-side؟ 1
هل لديك خدمات إدارة شهادات/PKI/CA أو استيراد شهادات من مستخدمين خارجيين تعتمد على مسارات CMS decryption/verification؟ 4

إذا كانت الإجابة “نعم” على أي مما سبق، تعامل مع CVE-2025-15467 كأولوية تصحيح قصوى (P1/P0) بغض النظر عن كونها “High” أو “Critical”.
مؤشر تقني عملي: مسارات API الأكثر ارتباطاً بالثغرة

تقرير JFrog يفيد عملياً في تحديد نطاق التعرّض على مستوى API/الأدوات، حيث أشار إلى أن تطبيقات تستدعي وظائف CMS decryption أو أدوات مثل openssl cms وopenssl smime قد تمر عبر سطح تأثر محتمل. استخدم ذلك كقائمة تدقيق داخلية لتحديد أين تُستخدم هذه المسارات في كودك أو في بايبلانات التشغيل. 14
مخطط قرار مبسط

text

[هل تستخدم OpenSSL 3.x ضمن نطاق 3.0..3.6؟] | (لا) |--> المخاطر من هذا CVE منخفضة/صفر (مع استمرار إدارة بقية CVEs) | (نعم) | [هل توجد معالجة CMS/PKCS#7 غير موثوقة؟ (S/MIME Gateway / API Upload / PKI tooling)] | (لا) |--> مخاطر "قابلية الوصول" منخفضة، لكن يُنصح بالتحديث ضمن نافذة قريبة | (نعم) | --> [P1] طبّق التصحيح فوراً + أعد تشغيل الخدمات + فعّل ضوابط تعويضية حتى اكتمال التحديث
التخفيف، التصحيح، والضوابط التعويضية

ترقية Upstream المعيارية (إن كنت تبني من المصدر أو تستخدم حِزم Upstream)

النشرة الأمنية تحدد مباشرة الإصدارات التصحيحية المطلوبة حسب الفرع: 3.6.1 / 3.5.5 / 3.4.4 / 3.3.6 / 3.0.19. 15
التصحيح عبر التوزيعات: مبادئ لا تتغير

المبدأ الذي أراه “يتكرر في كل الحوادث منذ التسعينات”:
تحديث الحزمة وحده لا يكفي. يجب إعادة تشغيل الخدمات التي حمّلت libcrypto/libssl مسبقاً حتى تُحمّل النسخة المصححة في الذاكرة. NVD يصف الثغرة على أنها قد تُسقط العملية؛ وهذا في الواقع يجعل “restart correctness” جزءاً من العلاج. 1
أمثلة عملية حسب التوزيعات (مع الاستناد إلى نشرات رسمية للحزم المصححة):
Debian: استخدم تحديثات الأمن (راجع النسخ المصححة في tracker). 9
bash

sudo apt update sudo apt -y full-upgrade sudo systemctl restart <service>
Ubuntu: USN-7980-1 يوضح نسخ الحزم المصححة ويذكر أن إعادة التشغيل/إعادة الإقلاع قد تكون مطلوبة لضمان تطبيق كل التغييرات. 3
bash

sudo apt update sudo apt -y upgrade sudo reboot
RHEL 9: RHSA-2026:1473 يحدد حزم RPM المحدثة لـ openssl/openssl-libs. 10
bash

sudo dnf -y update openssl openssl-libs sudo systemctl restart <service>
SUSE: إعلان SUSE-SU-2026:0312-1 يوصي بـ zypper patch ويعرض أوامر patch حسب المنتج. 11
bash

sudo zypper patch sudo systemctl restart <service>
التحقق بعد التصحيح: ما الذي يجب أن تثبتَه

تحقق من إصدار الحزمة (package version) لدى مدير الحزم، وليس فقط openssl version، لأن بعض التوزيعات تُبقي رقم OpenSSL الأساسي وتُسقط “الإصلاح” كـ backport. 3
تحقق أن الخدمات أعادت تحميل المكتبات:

bash

sudo lsof -p <PID> | egrep 'libcrypto|libssl'
ثم قارن المسار/تاريخ الملف على القرص مع الحزمة المصححة.
ضوابط تعويضية متقدمة عند تعذر التصحيح الفوري

عندما تكون نافذة التغيير ضيقة (خاصة في بوابات البريد)، استخدم ضوابط تخفض “احتمال الوصول” و“شدة الأثر” حتى تُنجز التحديث:

تقليل سطح الهجوم (Attack Surface Reduction):
إذا كانت الخدمة التي تعالج CMS/PKCS#7 ليست ضرورة فورية، عطّل مؤقتاً معالجة S/MIME AuthEnvelopedData inbound أو اجعلها محصورة في قنوات موثوقة فقط. هذا يتسق مع توصيف NVD لنطاق الخدمات المتأثرة: من يعالج محتوى CMS غير موثوق يكون ضمن دائرة الخطر. 1
العزل الشبكي (Segmentation):
ضع خدمة تفكيك/تحليل البريد والمرفقات في شبكة معزولة مع أقل صلاحيات واتصالات خروج محدودة. تقرير Datadog يلفت إلى أن الاستغلال العملي يتأثر بطبيعة البيئة—والعزل يقلل من عواقب أي اختراق محتمل. 4
تقسية الصلاحيات (Privilege Hardening):
شغّل الخدمات الحساسة بحسابات غير مميزة، وفعّل سياسات تقييد مثل systemd hardening وseccomp/apparmor/selinux حسب بيئتك. (هذه توصية دفاعية عامة لكنها حاسمة في تقليل أثر RCE إن حدث).
التشغيل داخل Sandboxing/Containers بحذر:
الهدف ليس “إخفاء الثغرة” بل تقليل تأثيرها: drop capabilities، read-only filesystem، no-new-privileges، وتقييد network egress.

الاستجابة للحوادث، الدروس طويلة الأمد، والملاحق العملية

إجراءات الاستجابة عند الاشتباه باستغلال

إذا اشتبهت بمحاولات استغلال (أو بدأت ترى انهيارات غير مفسرة)، تعامل مع السيناريو كالتالي:
مؤشرات أولية قوية (IoCs تشغيلية):

انهيار مفاجئ للخدمة التي تعالج CMS/PKCS#7 أو دخولها في crash loop. 1
رسائل من نمط “stack smashing detected” أو abort بسبب حماية المكدس. تقرير Datadog يعرض مثالاً مباشراً لانهيار مصحوب بهذه البصمة. 4

خطوات احتواء ذات أولوية (Containment):

عزل الخدمة المتأثرة عن مصادر الإدخال غير الموثوق (تعطيل مسار ingestion أو تقييد inbound) لتوقف نزيف DoS ومنع أي تصعيد محتمل. 1
تطبيق التحديثات فوراً بحسب التوزيعة، ثم إعادة تشغيل الخدمة/النظام حسب الحاجة. 2
جمع الأدلة قبل “تنظيف كامل” عندما يكون ذلك ممكنًا: سجلات systemd/journald، core dumps (إذا كانت مفعلة)، وأي دلائل على سلوك post-exploitation (shell spawn، اتصالات خروج غير معتادة).

تحليل السجلات بسرعة (Triaging):

systemd/journald:

bash

sudo journalctl -u <service> --since "2026-01-27" | tail -n 300

مؤشرات crash متكررة:

bash

sudo systemctl status <service> sudo journalctl -u <service> -p warning..***** --since "2026-01-27"
التعافي (Recovery):

إذا كان الأثر DoS فقط، يكفي غالباً patch + restart مع مراقبة معدلات الانهيار. 2
إذا كان هناك احتمال RCE (بيئات أقل hardening/أجهزة مدمجة)، فافترض compromise حتى يثبت العكس: تدوير مفاتيح/شهادات ذات صلة، مراجعة integrity للملفات التنفيذية، فحص persistence، ورفع مستوى الرصد على الشبكة. 6

توصيات طويلة الأمد مستخلصة من أنماط متكررة عبر عقود

هذه الثغرة تكرر نمطاً تاريخياً مشهوراً: Memory corruption في مكتبة واسعة الانتشار، لكن “الضرر الحقيقي” يتحدد عبر قابلية الوصول وجودة دفاعات البناء والتشغيل—وهذا يتماشى مع تأكيد NVD على أن الاستغلال يعتمد على mitigations، ومع تعليق Datadog على أن اختلافات البناء downstream قد تغير الخطر جذرياً. 1
توصيات استراتيجية قابلة للقياس في المؤسسات:

سياسة Patch Management بمدد زمنية محددة: تعريف SLAs حسب فئة التعرض (internet-facing + parses CMS = ساعات/أيام، غير ذلك = أيام/أسابيع).
جرد تبعيات دقيق (Dependency Inventory) مع تمييز الربط الساكن: لأن تحديث OS لا يصلح ثنائيات تحمل OpenSSL داخلها. 4
مقاربة “Reachability-First” في إدارة الثغرات: ليست كل CVSS=9.8 تعني نفس الأولوية في كل أصل (asset). لكن وجود parsing غير موثوق يرفعها فوراً إلى أولوية قصوى، وهذا محدد نصاً في NVD. 1
مراقبة تشغيلية للانهيارات وتدهور الخدمات: استغلال DoS غالباً يظهر كـ crash loops أو تدهور في SLO. (Datadog يقدم هذا المنظور في سياق هذه المجموعة من الثغرات). 4

ملاحق عملية

قائمة تدقيق مختصرة لمسؤولي الأنظمة (Administrator Checklist):

تأكد من وجود OpenSSL ضمن نطاق 3.0–3.6 المتأثر، وحدد فرعك بدقة. 7
اثبت هل توجد معالجة CMS/PKCS#7 غير موثوقة (S/MIME gateways، استيراد شهادات من مستخدمين، PKI tooling). 1
طبّق تحديثات التوزيعة/البائع (Debian/Ubuntu/RHEL/SUSE…) مع الالتزام بنُسخ الحزم المصححة. 9
أعد تشغيل الخدمات المرتبطة بـ libcrypto/libssl (أو نفذ reboot عند توصية البائع). 3
راقب سجلات الانهيار بعد التصحيح 48–72 ساعة، وافصل ingestion غير الموثوق إذا رأيت مؤشرات استهداف. 4

سكريبت “مؤشر أولي” للتحقق من عمليات ما زالت تحمل libcrypto (مثال لينكس):
bash

#!/usr/bin/env bash # قائمة تقريبية بالعمليات التي تمسك libcrypto/libssl حالياً # الهدف: تذكيرك بالخدمات التي قد تحتاج Restart بعد تحديث الحزم set -euo pipefail sudo lsof -nP 2>/dev/null | awk ' /libcrypto\.so|libssl\.so/ { print $1, $2, $9 } ' | sort -u | head -n 200
رسم طبقات الدفاع (استغلال محتمل مقابل تخفيفات):
text

[مهاجم خارجي] | | (CMS/PKCS#7 أو S/MIME AuthEnvelopedData بــ AEAD params خبيثة) v [بوابة/خدمة تستقبل CMS غير موثوق] | | CMS_decrypt / CMS_RecipientInfo_decrypt / openssl smime ... v [OpenSSL: تحليل ASN.1 -> استخراج IV] | | نسخ IV بطول أكبر من EVP_MAX_IV_LENGTH إلى stack buffer v [تلف مكدس] | | | +--> (سيناريو أصعب) RCE محتمل حسب mitigations والبناء | +--> (سيناريو شائع) Crash -> DoS ------------------------------------------ طبقات التخفيف: - Patch/Upgrade (الأهم) - Restart/Reload للخدمات لتحميل مكتبات مصححة - تقليل سطح التعرض (تعطيل/تقييد parsing غير الموثوق) - Sandboxing/Least privilege/Segmentation - Monitoring (crash loops, abnormal proc/network)