CVE-2026-40179 — تخزين XSS في Prometheus عبر remote_write

إثبات مفهوم بسيط وقليل الاعتماديات لـ CVE-2026-40179 (GHSA-vffh-x6r8-xx99): برمجة نصية مخزّنة عبر المواقع (stored XSS) في واجهة الويب الخاصة بـ Prometheus، يتم إيصالها عبر نقطة remote_write غير موثّقة.

الثغرة

يعرض Prometheus 3.x أسماء المقاييس وقيم التسميات (label values) في واجهة الويب عبر innerHTML دون تهريب (escaping). وبما أن Prometheus v3 خفّف قواعد التحقق من التسميات للسماح بأي UTF-8 — بما في ذلك < و > و " — يمكن لاسم مقياس أن يحمل حمولة HTML تُنفَّذ عندما يتصفح شخص ما الواجهة.

تحتاج ثغرة XSS نفسها إلى وسيلة لإدخال سلسلة زمنية مُصنَّعة إلى TSDB. أيٌّ من هذه الطرق يفي بالغرض:

• نقطة remote_write مفتوحة (وهو ما يستخدمه هذا الـ PoC)،
• هدف تجميع (scrape target) مخترق أو مسيطر عليه من المهاجم،
• مستقبل OTLP.

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

ما الذي يفعله هذا السكربت

يرسل طلب POST /api/v1/write واحدًا يحتوي سلسلة زمنية واحدة يكون اسمها __name__:

pentest_poc_cve_2026_40179

يتم ترميز WriteRequest بنوع protobuf يدويًا في حوالي 40 سطرًا، لذلك ليست هناك حاجة إلى protobuf أو prometheus_pb2 أو promtool — فقط python-snappy لضغط البيانات على الشبكة وrequests لإرسال الطلب. وهذا يجعل من السهل تشغيله على مضيف قفزة (jump host) حيث لا يمكنك بناء stubs بروتوبف مولّدة.

المتطلبات

python3 -m pip install python-snappy requests

يحتاج python-snappy إلى مكتبة Snappy C:

# Debian/Ubuntu
sudo apt install libsnappy-dev
# macOS
brew install snappy

الاستخدام

python3 cve-2026-40179-poc.py <target_ip>

يفترض السكربت HTTPS على المنفذ 9090 مع تعطيل التحقق من الشهادة (وهو أمر معتاد في الحالات الداخلية ذات الشهادة الموقّعة ذاتيًا). إذا كان هدفك عبر HTTP عادي أو على منفذ آخر، عدّل سطر url في main().

الاستغلال الناجح يعيد HTTP 204:

POST https://192.0.2.10:9090/api/v1/write -> 204

التحقق من وصول الكتابة

استعلم عن السلسلة في واجهة Prometheus أو API — يجب أن تظهر فورًا:

{__name__=~"pentest_poc.*"}

عرض الجدول يهربها بشكل صحيح ويعرض الحمولة كنص عادي. هذا أمر متوقع وليس سطح الثغرة.

تشغيل الحمولة

افتح مستكشف المقاييس (متصفح المقاييس بجوار مربع الاستعلام)، وابحث عن pentest_poc، ثم مرّر المؤشر فوق الإدخال المعروض.

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

تستخدم الحمولة الافتراضية console.log() حتى لا تقاطع أي شخص لا يبحث عنها. ولعرض مرئي — لقطة شاشة لتقرير مثلًا — غيّر METRIC_NAME لاستخدام alert():

METRIC_NAME = ('pentest_poc_cve_2026_40179'
               '')

التنظيف — اقرأ هذا قبل التشغيل

السلسلة المحقونة دائمة. بمجرد كتابتها، تبقى في TSDB حتى تنتهي فترة الاحتفاظ (retention). إزالتها تتطلب واجهة الإدارة (admin API) وهي معطّلة افتراضيًا:

# تعمل فقط إذا بدأ تشغيل Prometheus مع --web.enable-admin-api
curl -X POST -g 'https://<target>:9090/api/v1/admin/tsdb/delete_series?match[]={__name__=~"pentest_poc.*"}'
curl -X POST 'https://<target>:9090/api/v1/admin/tsdb/clean_tombstones'

إذا كانت واجهة الإدارة معطّلة، لا يوجد مسار تنظيف عن بُعد. البديل الوحيد هو promtool tsdb بتشغيله محليًا على المضيف، والذي ربما لا تملك صلاحية الوصول إليه.

النتائج العملية:

• تأكد من إمكانية التنظيف قبل الحقن في أي شيء يهمك، أو اقبل أن الأثر سيبقى.
• اسم المقياس طويل عمدًا، ولا يمكن الخطأ في التعرف عليه، ويصنّف نفسه بنفسه (job="pentest_poc") بحيث يسهل العثور عليه ومن الواضح أنه أثر اختبار.
• في مهمة مصرّح بها، أخبر العميل بأي سلسلة متبقية مباشرة، حتى لا يخطئ لاحقًا في اعتبارها اختراقًا حقيقيًا.

الاختبار الآمن

لإعادة إنتاج الثغرة على مثيل مؤقت بدلًا من أي شيء مباشر:

docker run --rm -p 9090:9090 prom/prometheus:v3.2.1 \
  --config.file=/etc/prometheus/prometheus.yml \
  --web.enable-remote-write-receiver \
  --web.enable-admin-api

ثم وجّه السكربت إلى 127.0.0.1 (غيّر مخطط عنوان URL إلى http:// في main()). البدء بـ --web.enable-admin-api يعني أنه يمكنك فعلًا حذف السلسلة لاحقًا.

المعالجة

1. قم بالترقية إلى Prometheus 3.5.2 أو أحدث. هذا هو الإصلاح.
2. ضع مصادقة وTLS أمام واجهة الويب وAPI الخاصة بـ Prometheus — بروكسي عكسي مع مصادقة، أو --web.config.file مع basic_auth_users.
3. لا تفعّل --web.enable-remote-write-receiver إلا إذا كنت بحاجة إليه، ولا تعرّضه أبدًا دون مصادقة.
4. قيّد الوصول إلى المنفذ 9090 على المضيفين الذين يحتاجونه بشكل مشروع.

لاحظ أن (1) وحده يصلح ثغرة XSS، لكن بقاء Prometheus دون مصادقة يظل سطحًا كبيرًا لكشف المعلومات بحد ذاته: قائمة أسماء المقاييس الكاملة، وجرد أهداف التجميع، وأسماء المضيفين الداخلية كلها قابلة للقراءة دون بيانات اعتماد.

للاستخدام المصرّح به فقط

نُشر هذا للمدافعين والباحثين والمختبِرين الذين يعملون بتفويض. الثغرة معلنة علنًا ومصححة في الإصدارات الأحدث.

تشغيل هذا ضد أي نظام يكتب بيانات دائمة فيه. لا توجّهه إلى بنية تحتية لا تملكها أو ليس لديك إذن كتابي صريح لاختبارها.

الترخيص

MIT — انظر LICENSE.