vghost-watch

أداة مساعدة لفحص المحيط والإفصاح المسؤول عن CVE-2026-74580 ("Vghost") — خلل حقيقي في ذاكرة التخزين المؤقت لبيانات vhost الوصفية في نواة لينكس (سجل CVE، مدخل OSV) يمنح تصعيد صلاحيات محلي / هروب من الآلة الافتراضية على مضيفات vhost/hypervisor المكشوفة.

حالة الاستخدام الأساسية: فحص محيطك الخاص. أدخل نطاقات IP الخاصة بك، أو CIDRs، أو النطاقات (import_list.py) — داخلية أو خارجية — و صنّفها للكشف عن التعرّض المرتبط بـ vhost (منافذ إدارة libvirt/Proxmox/QEMU)، ثم احصل على ملاحظات المعالجة لمتتبّعك الخاص (run_pipeline.py --self، انظر "فحص محيطك الخاص" أدناه). لا اكتشاف تلقائي، لا بحث جماعي عن جهات الاتصال — أنت تملك المضيف بالفعل.

القدرة الثانوية: اكتشاف الطرف الثالث عبر بيانات الفحص العامة. هذا المشروع لا يفحص الإنترنت بنفسه — يمكنه اختياريًا الاستعلام عن مجموعات البيانات/واجهات API التي قامت بالفحص بالفعل (Rapid7 Open Data / Sonar، Shodan، Censys) للعثور على مضيفات مكشوفة أخرى، ثم مساعدتك في صياغة إشعارات الإفصاح لأصحابها. يجدر معرفة ذلك قبل أن تستثمر وقتك هنا: لا توجد مكافأة لهذا (فرق الاستجابة للحوادث الأمنية لا تدفع، وتقارير "CVE معروف، نسخة غير مصححة" نادرًا ما تكون مؤهلة للمكافأة — انظر "التأثير" أدناه) — إنه عمل إشعار تطوعي من مواطن صالح، ومعظم الاستخدام الحقيقي لهذا المستودع هو حالة فحص المحيط أعلاه، وليس هذه.

التأثير: متى يكون هذا قابلًا للتطبيق / حرجًا؟

CVE-2026-74580 هو خلل على مستوى النواة، محلي، وليس خللًا مواجهًا للويب/الشبكة -- تترتب على ذلك بعض الأمور المهمة للتصنيف:

قابل للتطبيق فقط إذا تحققت كل هذه الشروط:

• يشغّل المضيف نواة لينكس غير مصححة (أقل من 5.10.265، 5.15.216، 6.1.183، 6.6.152، 6.12.104، 6.18.45، 7.1.9، أو النسخة المدعومة من التوزيعة).
• يستخدم افتراضية مدعومة بـ vhost (vhost-net/vhost-scsi عبر QEMU/KVM، عادةً من خلال libvirt أو Proxmox). مضيف bare-metal بدون أجهزة افتراضية، أو أجهزة افتراضية على virtio عادي بدون تفريغ vhost، غير معرّض لهذا الخلل بغض النظر عن مستوى التصحيح.
• تنفيذ الكود المحلي شرط مسبق. هذا تصعيد صلاحيات/هروب من الآلة الافتراضية، وليس تنفيذ كود عن بُعد -- يحتاج المهاجم إلى تشغيل كود بالفعل في مكان ما يصل إلى الواجهة المعرّضة للخطر: آلة افتراضية ضيف، أو حاوية بنواة مشتركة، أو حساب محلي على المضيف. "تشغيل الكود بالفعل" لا يتطلب وصولًا مباشرًا مثل SSH -- عمليًا يكون في أغلب الأحيان أحد هذه:
  • مستأجر شرعي، على hypervisor متعدد المستأجرين/سحابي -- عميل استأجر آلة افتراضية ببساطة لديه بالفعل تنفيذ كود كامل داخلها، بحكم التصميم، دون الحاجة إلى اختراق.
  • اختراق غير ذي صلة داخل الضيف -- في الغالب تطبيق ويب معرّض للخطر يتعرض لتنفيذ كود عن بُعد (إضافة قديمة، SSRF-to-RCE، خلل إلغاء تسلسل، إلخ)، لكن أي اختراق من جانب الضيف يعمل بالطريقة نفسها. لا يهم خلل vhost كيف دخل المهاجم، فقط أنه يملك الآن تنفيذ كود للانطلاق منه.

المحرك الحقيقي للخطورة هو من يملك بالفعل (أو يمكنه الحصول على) تنفيذ الكود -- وليس ما إذا كان المضيف مواجهًا للإنترنت. التعرّض للإنترنت يؤثر فقط على مدى سهولة عثور مهاجم خارجي على الهدف أو وصوله إلى موطئ القدم الأولي عن بُعد؛ لا يغيّر شيئًا بشأن ما إذا كان الخلل قابلًا للاستغلال بمجرد أن يحصل شخص ما على موطئ القدم هذا. البنية التحتية الداخلية فقط، الخاصة ليست بطبيعتها أقل خطرًا:

الأكثر خطورة، بغض النظر عن التعرّض للإنترنت:

• أي برنامج مراقبة افتراضية متعدد المستأجرين أو متعدد المستخدمين -- مزوّدو الاستضافة، وكذلك السحابة الخاصة الداخلية، أو منصة داخلية مخصّصة لكل فريق، أو بيئة تطوير/اختبار مشتركة تحتوي على حسابات مستخدمين عادية على الأجهزة الافتراضية/التطبيقات. كل واحد من هؤلاء المستخدمين أو المستأجرين يمتلك بالفعل شرط تنفيذ الشيفرة المسبق، بحكم التصميم، دون الحاجة إلى أي اختراق -- سواء كان متاحًا عبر الإنترنت أم لا.
• أي مضيف يمتلك فيه المهاجم موطئ قدم بالفعل (جهاز افتراضي مخترق، أو وصول داخلي عبر shell، أو هروب حاوية مشترك، أو تطبيق داخلي مخترق) مع استخدام تفريغ vhost -- فهذا يحوّل "لديّ shell بصلاحيات منخفضة" إلى "أملك المضيف"، بغض النظر عن كيفية الحصول على ذلك الـ shell.

حيث يكون التعرّض للإنترنت مهمًا فعليًا (عامل ثانوي، وليس العامل الأساسي):

• يجعل الحصول على موطئ القدم الأولي أسهل لمهاجم خارجي عن بُعد (مثل RCE في تطبيق ويب، انظر ملاحظة WAF أدناه) ويجعل المضيف أسهل في الاكتشاف من الأساس -- منافذ الإدارة المكشوفة (libvirt 16509/16514، Proxmox 8006) هي إشارة استطلاع لذلك، وهو ما يبحث عنه التقييم في merge_and_triage.py. المنفذ المكشوف لا يثبت شيئًا بحد ذاته، لكنه لا يهم إلا عندما يستطيع شيء يتحكم فيه المهاجم التنفيذ محليًا، وهو ما لا تستطيع بيانات الفحص السلبي إظهاره (انظر "لماذا السلبي فقط" أدناه لمعرفة سبب عدم محاولة هذا المستودع تأكيد ذلك على مضيفين لا تملكهم).
• المضيف الداخلي فقط الذي يمتلك نفس التعرّض متعدد المستخدمين/المستأجرين لا يقل خطورة -- فهو يحتاج فقط إلى مستخدم داخلي، أو متعاقد، أو تطبيق داخلي مخترق لتوفير موطئ القدم بدلًا من موطئ قدم متاح عبر الإنترنت. لا تفسّر "غير متاح عبر الإنترنت" على أنه "أولوية أقل".

خطورة أقل فعليًا:

• مستأجر واحد، بدون ضيوف أو مستخدمين أو تطبيقات غير موثوقة على الإطلاق -- سيكون "المهاجم" الوحيد هو أنت، لذا فإن المخاطر الفعلية أقل بكثير. لا يزال يستحق الترقيع حتى لا يتسلسل أي اختراق مستقبلي غير ذي صلة إلى هذه الثغرة.
• بدون vIOMMU -- وفقًا للتنبيه الأمني، يحتاج مسار الهروب من الجهاز الافتراضي تحديدًا إلى إعداد مُفعّل فيه vIOMMU؛ وبدونه، من المرجح أن يقتصر التأثير على تصعيد الصلاحيات المحلي داخل النواة بدلًا من عبور حدود الضيف/المضيف.

هل يساعد WAF؟ ليس ضد هذه الثغرة مباشرة -- فـ WAF يفحص حركة HTTP(S)، وهذه الثغرة تكمن في مسار ذاكرة التخزين المؤقت لبيانات vhost الوصفية في النواة، وليس في تحليل الطلبات. ببساطة ليس في مسار التعرّض للثغرة نفسها.

حيث يهم WAF فعلًا هو خطوة أبكر: السلسلة الأكثر شيوعًا في الواقع هي RCE في تطبيق ويب → تنفيذ شيفرة داخل الضيف → استغلال vhost → الهروب من المضيف → حركة جانبية إلى كل مستأجر آخر. يمكن لـ WAF (أو ضوابط أمن الويب الأخرى) حجب RCE في تطبيق الويب الذي يمنح المهاجم موطئ قدمه الأولي، مما يمنعه من الوصول إلى الشرط المسبق لهذه الثغرة من الأساس. لذا: غير ذي صلة بثغرة vhost نفسها، لكنه ذو صلة بأحد أكثر المسارات شيوعًا إلى الشرط المسبق لها.

ما يقلل المخاطر فعليًا، من البداية إلى النهاية: ترقيع النواة، وتعطيل تفريغ vhost حيث لا تكون هناك حاجة إليه، وعدم كشف منافذ إدارة libvirt/Proxmox للإنترنت، وتحصين تطبيقات/خدمات الويب العاملة داخل الضيوف (تقليل احتمالات ذلك الـ RCE الأولي)، وتحصين عزل المستأجرين (seccomp، namespaces) لجعل الحصول على أي موطئ قدم أصعب.

لماذا السلبي فقط، بحكم التصميم

الفحص النشط للمنافذ أو استجواب SSH على أنظمة لا تملكها أو لا تملك تفويضًا مكتوبًا لها يُعدّ وصولًا غير مصرّح به في معظم الولايات القضائية (في الاتحاد الأوروبي، يندرج هذا تحت تطبيقات التوجيه 2013/40/EU؛ ويغطيه القانون التشيكي بموجب § 230 trestního zákoníku) وانتهاكًا لشروط الخدمة لدى معظم المضيفين/السحابات -- بغض النظر عن حسن النية. هذا المستودع لا يقرأ إلا البيانات التي جمعها ماسحات الطرف الثالث بالفعل ونشرتها/باعت الوصول إليها بموجب تفويضها الخاص. انظر SCOPE.md.

إذا كنت تريد التحقق من نتيجة محددة (تأكيد أن مضيفًا ما عرضة للثغرة فعليًا، وليس مجرد "يبدو مكشوفًا")، فإن ذلك يتطلب إذن المالك -- انظر قالب الإفصاح، الذي يطلب ذلك تحديدًا.

خط الأنابيب