CVE-2025-58034 هو ثغرة حقن أوامر نظام التشغيل المصادق عليها (CWE-78) في فورتنيت جدار حماية تطبيقات الويب FortiWeb (WAF). في الإصدارات المتأثرة، يمكن للمهاجم الذي قام بتسجيل الدخول تشغيل تنفيذ أمر غير مصرح به على النظام الأساسي عبر طلبات إدارة HTTP أو أوامر CLI المصممة خصيصًا. أكدت شركة Fortinet الاستغلال النشط في البرية، وقد أضافت CISA هذا CVE إلى الثغرات المعروفة المستغلة (KEV) مما يجعل التصحيح أمرًا ملحًا على الرغم من أن درجة CVSS الأساسية "متوسطة". (FortiGuard)
تقع أجهزة FortiWeb عند الحدود الأمنية؛ فبمجرد أن يصبح تنفيذ الأوامر ممكناً على WAF، يمكن للمهاجم تعطيل الحماية والتلاعب بالنُهج والتوغل بشكل أعمق في شبكات التطبيقات. هذا الموضع الحدودي هو السبب في أن RCE ما بعد المصادقة على FortiWeb هو السبب في أن RCE ما بعد المصادقة على FortiWeb هو عالي التأثير من الناحية التشغيلية على الرغم من PR:H في متجه CVSS. (NVD)
الإصدارات المتأثرة والثابتة
تتفق إرشادات Fortinet لـ PSIRT و NVD على النطاقات المعرضة للخطر. (FortiGuard)
| فرع فورتي ويب | الإصدارات المتأثرة | الإصدارات الثابتة |
|---|---|---|
| 8.0.x | 8.0.0 - 8.0.1 | 8.0.2+ |
| 7.6.x | 7.6.0 - 7.6.5 | 7.6.6+ |
| 7.4.x | 7.4.0 - 7.4.10 | 7.4.11+ |
| 7.2.x | 7.2.0 - 7.2.11 | 7.2.12+ |
| 7.0.x | 7.0.0 - 7.0.11 | 7.0.12+ |
يوجد لا توجد حلول بديلة موثوقة موصى بها علنًا ما بعد إزالة تعرض الإدارة والترقيع، لذا فإن الترقية هي التخفيف الأساسي. (FortiGuard)

السبب الجذري وسطح الهجوم
تنبع نقطة الضعف من التحييد غير السليم للعناصر الخاصة في سياق أوامر نظام التشغيل، مما يعني أن FortiWeb يقبل المدخلات التي يتحكم فيها المهاجمون والتي يتم تضمينها لاحقًا في تنفيذ الأوامر على مستوى النظام دون الهروب الكافي. يشير البائع إلى أن المشكلة تحدث في مكوِّنات واجهة برمجة التطبيقات (API) وواجهة برمجة التطبيقات (CLI)، مما يشير بقوة إلى أن عملية إدارية واحدة أو أكثر تبني أوامر الصدفة من خلال ربط المعلمات. (FortiGuard)
نظرًا لأن الاستغلال يتطلب مصادقة، فإن المسار الأكثر واقعية هو: اختراق أو إعادة استخدام بيانات اعتماد المسؤول (كلمات مرور ضعيفة، أو حسابات مشتركة، أو واجهة مستخدم الإدارة المكشوفة، أو جلسات العمل المسروقة)، متبوعة بحقن الأوامر للحصول على تحكم كامل في الجهاز. في الحوادث الحقيقية، فإن "خطوة ما بعد المصادقة" هذه هي بالضبط ما يجعل خروقات FortiWeb مدمرة للغاية. (رابيد7)
الخطورة ولماذا لا تزال كلمة "متوسط" تعني "التصحيح الآن"
يسرد NVD قائمة CVSS v3.1 على النحو التالي: أف: ن/ك: ن/ك: ل/ر: ح/ي: ن/س: ش/ج: ح/ي: ح/ح/ح/ح بنتيجة 6.7. (NVD)
على الورق، تسحب PR:H النتيجة إلى الأسفل. في الممارسة العملية، هناك حقيقتان تتجاوزان علامة "متوسط":
- تنص شركة Fortinet على أن CVE هو المستغلة بنشاط في البرية. (FortiGuard)
- يشير تضمين CISA KEV إلى قيمة حقيقية للمهاجمين ويفرض معالجة سريعة للأنظمة الفيدرالية الأمريكية، عادةً في غضون أيام. (CISA)
لذلك تعامل مع CVE-2025-58034 على أنه أولوية قصوى بغض النظر عن النتيجة الأساسية.
الكشف الدفاعي
تساعدك الأمثلة أدناه في تحديد التعرض دون توفير مسار استغلال.
1) تأكيد إصدار FortiWeb (CLI)
# طباعة حالة النظام على FortiWeb CLI
الحصول على حالة النظام
# ابحث عن: "الإصدار: FortiWeb vX.Y.Z"
2) مسبار الإصدار السلبي عبر راية SSH
"""
مسبار إصدار FortiWeb السلبي بواسطة شعار SSH.
لا توجد حمولات هجومية؛ آمن لفحص المخزون المصرح به.
"""
استيراد المقبس، إعادة
def probe_ssh_banner(المضيف، المنفذ=22، المهلة=3):
s = socket.socket()
s.s.setimeout(المهلة)
s.connect((المضيف، المنفذ)))
بانر = s.recv(4096).decode(أخطاء="تجاهل")
s.close()
إرجاع البانر
تعريف استخراج_إصدار(نص):
m = re.search(r"FortiWeb [-\\\s]?v?(\\\d+\\\\.\\d+\\\\\\d+)"، نص، re.I)
إرجاع m.group(1) إذا كان m وإلا فلا شيء
المضيف = "YOUR_FORTIWEWEB_IP"
بانر = probe_ssh_banner(المضيف)
ver = استخراج_الإصدار(بانر)
طباعة("الشعار:", banner.strip())
طباعة("إصدار FortiWeb:", ver أو "غير معروف")
3) التطابق مع النطاقات المتأثرة
"""
قارن إصدار FortiWeb المكتشف بالنطاقات المتأثرة.
"""
من تغليف استيراد الإصدار
المتأثر = [
("8.0.0", "8.0.1"),
("7.6.0", "7.6.5"),
("7.4.0", "7.4.10"),
("7.0.0", "7.0.11"),
]
def in_affected_ranges(v: str) -> bool:
v = الإصدار.parse(v)
بالنسبة إلى lo, hi في AFFECTED:
إذا كان الإصدار.parse(lo) <= v <= الإصدار.parse(hi):
الإرجاع صحيح
إرجاع خطأ
test_ver = "7.4.8"
طباعة(test_ver, "متأثر؟", in_affected_ranges(test_ver))
اصطياد التهديدات: ما الذي تبحث عنه
بالنظر إلى الاستغلال المؤكد في البرية، يجب البحث عن أدلة على إساءة استخدام بيانات الاعتماد متبوعة بتنفيذ الأوامر. يؤكد Rapid7 وإرشادات البائعين على مراجعة سجل ما بعد التصحيح والتحقق من سلامة التكوين. (رابيد7)
تشمل الإشارات العملية ما يلي:
- عمليات تسجيل دخول المسؤول الجديدة أو غير المعتادة (خاصةً من عناوين IP غير مألوفة أو في ساعات غريبة),
- نشاط غير متوقع لإدارة واجهة برمجة التطبيقات (API),
- العمليات الفرعية المشبوهة الناتجة عن خدمات FortiWeb,
- تغييرات السياسة/التكوين لا تتطابق مع نافذة التغيير (رابيد7)
مثال على فرز السجل الخفيف الوزن:
# بحث عن حالات شاذة لتسجيل دخول المسؤول
grep -Ei "admin ||login|cli" /var/log/* 2> /dev/null | tail -n 200
# ابحث عن آثار نمط تنفيذ الأوامر
grep -Ei "exec |shell|System\\(|popen|cmd" /var/log/* 2>/dev/null | tail -n 200
إذا وجدت مؤشرات ذات مصداقية، تعامل مع الجهاز على أنه مخترق: التقط الأدلة الجنائية، وقم بتدوير بيانات الاعتماد، وفكر في إعادة البناء من صور معروفة جيدة.

إرشادات التخفيف من المخاطر
موقف Fortinet الرسمي واضح ومباشر: الترقية إلى الإصدارات الثابتة على الفور، ثم التحقق من السلامة. (FortiGuard)
في موازاة ذلك، قلل من نصف قطر الانفجار عن طريق تشديد مستوى الإدارة: الحد من وصول واجهة مستخدم الويب/واجهة برمجة التطبيقات/واجهة برمجة التطبيقات/واجهة SSH إلى نطاقات IP الموثوقة أو الشبكات الداخلية، وفرض المصادقة متعددة اللاعبين بالإضافة إلى نظافة بيانات الاعتماد القوية. يتماشى هذا مع تحذير البائع من أفضل الممارسات بأن واجهات الإدارة المكشوفة تزيد من مخاطر العالم الحقيقي. (تيك رادار)
سبب أهمية CVE-2025-58034
من المفترض أن يكون FortiWeb نقطة اختناق دفاعية. عندما يمكن توجيه WAF نفسه إلى تنفيذ الأوامر من قبل مهاجم قام بتسجيل الدخول، تكون قد فقدت الحدود فعلياً ومنحت المهاجم موطئ قدم متميزاً على الشبكة. مع ملاحظة الاستغلال بالفعل وتعيين حالة KEV, التأخير هو العدو هنا. (رابيد7)
إذا كنت تدير العديد من بيئات العملاء وتحتاج إلى التحقق من صحة الإصدارات بالإضافة إلى أولوية التصحيح على نطاق واسع، يمكن أن يساعد سير عمل الأتمتة البشرية في الحلقة (على سبيل المثال، Penligent) في جرد عقارات FortiWeb، وربط السجلات، وإنتاج تقارير الإصلاح بسرعة - دون تحويل الاكتشاف إلى محاولات استغلال محفوفة بالمخاطر.
