CVE-2026-45806

استيراد الصور عن بُعد في Penpot سمح لمحرر ملفات مصادق بتحويل ميزة وسائط عادية إلى SSRF من أصل الخادم الخلفي لأن عناوين URL التي يتحكم بها المهاجم عبرت إلى مسار جلب خادم يتبع إعادة التوجيه دون تصفية الوجهة.

مقدمة

اكتشفت هذه المشكلة أثناء مراجعة Penpot، منصة التعاون في التصميم والكود مفتوحة المصدر، مع سؤال محدد للغاية في ذهني:

ماذا يحدث عندما تسمح أداة تعاون في التصميم لأحد المستخدمين بتمرير عنوان URL لصورة عن بُعد إلى الخادم الخلفي لجلبها؟

في هذه الحالة، أدى ذلك السؤال إلى خطأ حقيقي.

قبل تدفق استيراد الصور عن بُعد في Penpot عنوان URL يتحكم به المستخدم وتسبب في جلب الخادم الخلفي له من سياق شبكة الخادم دون فرض قيود على الوجهات المستهدفة للحلقة المحلية أو الشبكة الخاصة. كما اتبع عميل HTTP المشترك إعادة التوجيه تلقائيًا.

حول ذلك ميزة وسائط عادية إلى بدائية SSRF مصادق من أصل الخادم الخلفي، وأصبحت في النهاية CVE-2026-45806.

Penpot: Penpot على GitHub
CVE: CVE-2026-45806
CVSS: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N

أثر هذا على Penpot. على موقعها الرسمي وحزمة الوسائط، تقدم Penpot نفسها على أنها ذات قاعدة مستخدمين متزايدة تزيد عن مليون مستخدم وتقول أن عشرات الآلاف من المؤسسات تستخدمها، بما في ذلك Blender و Mozilla و Fedora و NTT Data و MIT و Société Générale و Cisco و Fujitsu و Indra و ByteDance.

سلسلة الهجوم

محرر ملفات مصادق -> عنوان URL لصورة عن بُعد يتحكم به المهاجم -> إنشاء كائن وسائط ملف من عنوان URL -> جلب صورة تنزيل من الخادم الخلفي مع تمكين إعادة التوجيه -> الطلب النهائي يصل إلى نقطة نهاية صورة داخلية فقط -> SSRF من أصل الخادم الخلفي / قابلية الوصول الداخلي

ما يفعله Penpot

Penpot هي منصة تعاون في التصميم والكود مفتوحة المصدر.

تتعامل مع أشياء مثل:

• تحرير الملفات التعاوني
• سير عمل الفرق والمشاريع
• الوسائط والأصول المرفوعة
• مسارات العرض والمعاينة
• عمليات التصميم القائمة على المتصفح مدعومة بمعالجة الخادم الخلفي

هذا يعني أن مسار استيراد الوسائط الخاص بها يقع على حدود ثقة حقيقية.

السؤال المهم هنا لم يكن ما إذا كان Penpot يدعم استيراد الصور عن بُعد.

السؤال الحقيقي كان:

هل يقيد Penpot أين يُسمح للخادم الخلفي بالاتصال عندما يستورد المستخدم صورة عن بُعد؟

في هذه الحالة، لم يفعل.

لماذا كان هذا الخطأ يستحق النظر

كثير من الناس يقللون من شأن ميزات الاستيراد عن بُعد.

هذا خطأ.

في اللحظة التي يقبل فيها تطبيق:

• عنوان URL يتحكم به المهاجم،
• ويجعل الطلب من الخادم الخلفي،
• ويحول ذلك الطلب إلى سير عمل منتج عادي،

فإنه يخلق حدود ثقة صادرة حقيقية.

هذا هو المشكلة هنا.

لم يكن هذا الخطأ في عرض الصور. لم يكن في تخزين الملفات. لم يكن في فحوصات الأذونات العادية لتحرير ملف.

كان فشلًا كلاسيكيًا في ثقة الخادم الخلفي:

• عنوان URL يتحكم به المهاجم دخل النظام،
• جلب الخادم الخلفي مباشرة،
• سمح بإعادة التوجيه،
• ولم تكن هناك ضوابط وجهة مرئية في المسار الذي تمت مراجعته.

هذا كافٍ لخلق ثغرة حقيقية.

الحدود التي ركزت عليها

لم أقترب من Penpot باختبار عشوائي لطرق RPC أو البحث عن الأعطال أولاً.

النهج الأقوى كان تحديد الحدود الأمنية الأكثر وعدًا.

بالنسبة لـ Penpot، كانت هذه استيراد الوسائط عن بُعد.

لماذا؟

لأن هذه الميزة تجمع بين:

• إدخال عنوان URL يتحكم به المهاجم
• طلبات صادرة من أصل الخادم الخلفي
• التحقق من المحتوى الذي يحدث فقط بعد إجراء الطلب
• سير عمل تصميم حيث يتم التعامل مع عمليات الجلب الناجحة كعمليات وسائط عادية

تلك كانت الحدود الصحيحة للتفتيش.

وكانت بالضبط مكان وجود الخطأ.

السبب الجذري

يتلخص الخطأ في سلسلة ثقة صغيرة.

في الواجهة الأمامية:

(defn upload-media-url
  [name file-id url]
  (rp/cmd!
   :create-file-media-object-from-url
   {:name name
    :file-id file-id
    :url url
    :is-local true}))

يتم إرسال url التي يتحكم بها المستخدم مباشرة في استدعاء RPC.

ثم في الخادم الخلفي:

(sv/defmethod ::create-file-media-object-from-url
  ...
  [{:keys [::db/pool] :as cfg} {:keys [::rpc/profile-id file-id] :as params}]
  (files/check-edition-permissions! pool profile-id file-id)
  ...
  (let [_    (files/get-minimal-file cfg file-id)
        mobj (create-file-media-object-from-url cfg (assoc params :profile-id profile-id))])

و:

(defn- create-file-media-object-from-url
  [cfg {:keys [url name] :as params}]
  (let [content (media/download-image cfg url)

يتحقق الخادم الخلفي من أن المتصل يمكنه تحرير الملف الهدف، ثم يمرر عنوان URL الذي يتحكم به المهاجم إلى media/download-image.

تنفيذ الجلب موجود هنا:

(defn download-image
  "قم بتنزيل صورة من URI المقدم وإرجاع كائن الإدخال الوسائطي"
  [{:keys [::http/client]} uri]
  ...
  (http/req! client
             {:method :get :uri uri}
             {:response-type :input-stream})

ويتم تكوين عميل HTTP المشترك كالتالي:

(http/build-client {:connect-timeout 30000
                    :follow-redirects :always}))

هذا هو الثغرة بأكملها:

• المهاجم يتحكم في عنوان URL
• الخادم الخلفي يقوم بالطلب
• يتم اتباع إعادة التوجيه تلقائيًا
• لا يتم تطبيق أي تصفية وجهة قبل إجراء الطلب

لماذا هذا قابل للاستغلال

لأن المهاجم يحتاج فقط إلى:

• حساب Penpot صالح
• إذن تحرير في ملف واحد
• هدف يعيد محتوى صورة مقبول

سلسلة الهجوم واضحة:

• يقوم المهاجم بتوفير عنوان URL
• يقوم Penpot بجلبه من الخادم الخلفي
• يمكن أن تكون القفزة الأولى عامة أو تبدو غير ضارة
• يمكن أن يكون هدف إعادة التوجيه داخليًا
• إذا كان الرد النهائي يشبه صورة مسموح بها، يكتمل الاستيراد

هذا هو الخطأ بأكمله.

ما الذي يجعل هذه مشكلة أمنية، وليس مجرد سلوك استيراد عن بُعد عادي

الفرق المهم هو مكان حدوث الطلب.

السؤال ليس:

"هل يمكن لـ Penpot استيراد الصور من عناوين URL؟"

السؤال الحقيقي هو:

"هل يمكن لمستخدم مصادق أن يجعل خادم Penpot الخلفي يتصل بوجهات داخلية لا ينبغي للمستخدم أن يتمكن من الوصول إليها من خلال التطبيق؟"

في هذه الحالة، كانت الإجابة نعم.

هذا مهم لأنه يوجد فرق حقيقي بين:

• متصفح يجلب عنوان URL يوفره المستخدم، و
• الخادم الخلفي يجلب ذلك العنوان URL من موقع شبكة الخادم

التحقق من الصورة لا يزيل هذا الفرق.

إنه يضيق بعض حالات سرقة البيانات المباشرة، لكنه لا يزيل حالة SSRF أو كسر حدود الشبكة.

الإثبات العملي (PoC)

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

الهدف لم يكن ضرب بنى تحتية لجهات خارجية. الهدف كان إثبات الخاصية الأمنية بالضبط:

• تنفيذ طلب من نمط الخادم الخلفي
• اتباع إعادة التوجيه
• تحول ناجح إلى نقطة نهاية داخلية فقط
• إكمال تحت نفس قيود الصور التي يفرضها Penpot

قمت ببناء مدقق Java مستقل يعكس السلوك ذي الصلة:

• GET من جانب الخادم الخلفي إلى URI يتحكم به المتصل
• اتباع إعادة التوجيه تلقائيًا
• فحوصات قبول الصورة بناءً على content-type و content-length

قمت بالتحقق من حالتين.

الحالة 1: جلب داخلي مباشر

طلب المدقق:

http://127.0.0.1:7790/internal.png

النتيجة الملاحظة:

• URI المطلوب: http://127.0.0.1:7790/internal.png
• URI النهائي: http://127.0.0.1:7790/internal.png
• الحالة: 200
• نوع المحتوى: image/png
• تم كتابة الأثر بنجاح

أثبت ذلك أن منطق الجلب بنمط الاستيراد قبل نقطة نهاية صورة داخلية فقط مباشرة.

الحالة 2: جلب داخلي بمساعدة إعادة التوجيه

ثم طلب المدقق:

http://localhost:7791/redirect-to-internal

أعادت تلك النقطة إعادة توجيه HTTP إلى:

http://127.0.0.1:7790/internal.png

النتيجة الملاحظة:

• URI المطلوب: http://localhost:7791/redirect-to-internal
• URI النهائي: http://127.0.0.1:7790/internal.png
• الحالة: 200
• نوع المحتوى: image/png
• تم كتابة الأثر بنجاح

سجل المستمع الداخلي فقط الطلب المعاد توجيهه.

أثبت ذلك الادعاء الأكثر أهمية:

• يمكن أن يختلف عنوان URL الأولي الذي يتحكم به المهاجم عن الوجهة النهائية
• يتم اتباع إعادة التوجيه تلقائيًا
• يمكن أن يصل الجلب النهائي للخادم الخلفي إلى نقطة نهاية داخلية فقط وما زال ينجح

لماذا تم بناء الإثبات بهذه الطريقة

كان الحمولة هنا بسيطة عمدًا:

• رد PNG صغير وصالح
• هدف إعادة توجيه صريح
• مستمع داخلي فقط مربوط بالحلقة المحلية

هذا مهم لأن Penpot لا يجلب فقط بايتات عشوائية ويتوقف. يقوم بالتحقق من الوسائط بعد الطلب.

لذا فإن الإثبات الصحيح لم يكن:

"الخادم الخلفي يمكنه محاولة الاتصال بمكان ما"

الإثبات الأقوى كان:

"الخادم الخلفي يمكن جعله يتصل بمكان داخلي ويكمل الطلب بنجاح تحت نفس قيود الصور التي تتوقعها الميزة"

هذا بالضبط ما أظهره التحقق.

لماذا كان هذا لا يزال يستحق الإبلاغ

رد الفعل الشائع على ثغرات SSRF مثل هذه هو:

"الهدف لا يزال يجب أن يعيد صورة"

هذه الملاحظة صحيحة ولكنها غير مكتملة.

لا تزيل الثغرة.

إنها فقط تخبرك أي الأهداف الداخلية هي الأكثر فائدة مباشرة.

لا تزال هذه المشكلة تمكن من:

• قابلية الوصول الداخلي من أصل الخادم الخلفي
• التحول بمساعدة إعادة التوجيه إلى مساحة الحلقة المحلية أو الشبكة الخاصة
• التفاعل مع نقاط نهاية داخلية تعيد صورًا
• إساءة استخدام ثقة الشبكة من موقع خادم Penpot

لا يزال هذا كسرًا حقيقيًا لحدود الأمان.

خاصة في البيئات المستضافة ذاتيًا، غالبًا ما توجد الخدمات الداخلية خلف تلك الحدود تحديدًا.

الشدة والتصنيف

تم تعيين درجة عالية (High) للثغرة في النهاية على CVSS:

• CWE-918: تزوير طلب الخادم الخلفي (SSRF)
• CVSS:

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N

هذا التصنيف منطقي.

الادعاء ليس أن مهاجمًا غير مصادق يمكنه اختراق كل نشر لـ Penpot فورًا من الصفر.

الادعاء هو أن أي محرر ملفات مصادق عادي يمكنه تحويل Penpot إلى بدائية طلب خادم خلفي ضد وجهات داخلية، بما في ذلك الوصول بمساعدة إعادة التوجيه إلى أهداف الحلقة المحلية والشبكة الخاصة.

كان هناك بعض النقاش حول الشدة أثناء الإفصاح، بشكل رئيسي حول:

• الخدمات الداخلية التي تتطلب المصادقة
• المحتوى المجلوب الذي يحتاج إلى اجتياز التحقق من الصورة
• الاستغلال الذي يعتمد على معرفة البنية التحتية الداخلية

تلك قيود عادلة للمناقشة.

لكنها لا تزيل المشكلة الأساسية:

• عنوان URL يتحكم به المهاجم
• مصدر طلب من جانب الخادم الخلفي
• اتباع إعادة التوجيه
• لا سياسة وجهة صادرة في المسار الذي تمت مراجعته

هذه ثغرة SSRF حقيقية وقابلة للدفاع عنها.

تحليل الإصلاح

الإصلاح المهم هنا ليس التعامل الأكثر صرامة مع MIME.

الإصلاح الحقيقي هو سياسة الوجهة الصادرة.

المعالجة الصحيحة لهذه الفئة من الثغرات تحتاج إلى:

1. السماح فقط بـ http و https
2. حل أسماء النطاقات ورفض نطاقات الحلقة المحلية و RFC1918/الخاصة والرابط المحلي والبث المتعدد وغير المحدد ونطاقات خدمة البيانات الوصفية قبل الاتصال
3. إعادة فحص كل قفزة إعادة توجيه مقابل نفس السياسة
4. النظر في تعطيل إعادة التوجيه لهذه الميزة أو تقييدها بشدة
5. إضافة تغطية اختبار رجعي لـ:
   • localhost
   • الأهداف الخاصة المباشرة
   • حالات إعادة التوجيه إلى الخاص
   • سيناريوهات إعادة ربط DNS

هذا هو اتجاه الإصلاح الصحيح لأن هذه لم تكن ثغرة في تحليل الصور. كانت ثغرة في حدود ثقة الشبكة.

الإفصاح

تم الإبلاغ عن هذه المشكلة بشكل خاص من خلال تدفق الإبلاغ الأمني في GitHub.

تضمن التقرير:

• تحليل السبب الجذري على مستوى الكود المصدري
• نموذج تحقق محلي قوي
• إثبات التحول الداخلي القائم على إعادة التوجيه
• أدلة الأثر والسجلات
• إرشادات المعالجة

أكد المشرفون على المشكلة وبدأوا العمل على حلها.

تم تعيين الثغرة لاحقًا:

CVE-2026-45806

ما تعلمه هذه الثغرة بالفعل

الدرس الرئيسي بسيط:

استيراد الوسائط عن بُعد هو حد ثقة صادر، وليس مجرد ميزة راحة

العديد من المطورين يفكرون من حيث:

• عنوان URL مقبول
• الطلب ينجح
• الصورة تجتاز التحقق
• يتم تخزين الوسائط

تلك تفاصيل تنفيذ.

السؤال الأمني الحقيقي هو:

أين يُسمح للخادم الخلفي بالاتصال نيابة عن المستخدم؟

إذا لم يتم الإجابة على هذا السؤال بشكل صريح، تصبح ميزات مثل الاستيراد عن بُعد أسطح SSRF افتراضيًا.

تعزز هذه الثغرة أيضًا شيئًا مهمًا حول مراجعة SSRF:

• إعادة التوجيه مهمة
• التحقق من المحتوى ليس بديلاً عن سياسة الشبكة
• SSRF المصادق لا يزال خطيرًا عندما يتجاوز حدود الثقة الداخلية

هذا هو الاستنتاج الحقيقي.

نقاط رئيسية

• استيراد الصور عن بُعد هو حد ثقة خادم خلفي حقيقي
• الميزات المصادقة يمكن أن تعرض لـ SSRF خطير
• اتباع إعادة التوجيه يجعل مسارات الجلب الصادرة أكثر خطورة بكثير
• التحقق من الصورة فقط يضيق بعض مسارات الإساءة لكنه لا يزيل SSRF
• إثبات مسار إعادة توجيه داخلي ناجح أقوى من مجرد إظهار محاولة اتصال فاشلة
• الإصلاح الصحيح هو سياسة الوجهة الصادرة، وليس التحقق التجميلي من الردود

كلمات أخيرة

لم تكن هذه الثغرة حول حمولة مبهرجة.

كانت حول طرح سؤال حدود الثقة الصحيح.

Penpot سمح لمحرر ملفات مصادق بتوفير عنوان URL لصورة عن بُعد، ووثق الخادم الخلفي في ذلك العنوان URL أكثر مما ينبغي. معالجة إعادة التوجيه فعلت الباقي.

لهذا أصبحت CVE-2026-45806.