حذّر باحثون أمنيون من ثغرة في إطار Starlette المفتوح المصدر قد تتيح لمهاجم غير مصرح له تجاوز ضوابط الوصول في تطبيقات مبنية على FastAPI، وهي فئة واسعة من الأدوات والخدمات التي تُستخدم اليوم في تشغيل نماذج اللغة الكبيرة، وبوابات النماذج، وخوادم MCP، وبنى الوكلاء الذكيين.
الثغرة، التي جرى تتبعها تحت الرمز CVE-2026-48710، ترتبط بطريقة تعامل الإطار مع ترويسة Host في طلبات HTTP. ووفقًا للتحليل الأمني، فإن إدخال قيمة مشوهة في هذه الترويسة قد يؤدي إلى اختلاف بين المسار الذي يراه التطبيق والمسار الذي يعالجه الخادم فعليًا، ما يفتح الباب أمام تجاوز آليات التحقق المبنية على عنوان الطلب.
ما يزيد أهمية القضية أن استغلالها لا يتطلب كلمة مرور ولا تفاعلًا من المستخدم المستهدف. وبحسب الباحثين، فإن مجرد إرسال طلب مُعدّ بعناية يكفي لإرباك منطق التحقق لدى بعض التطبيقات التي تعتمد على المسار المُعاد بناؤه بدلًا من المسار الخام القادم من الشبكة.
كيف تعمل الثغرة
تعود المشكلة إلى اختلاف طريقة تحليل الطلب بين مستوى الشبكة ومستوى التطبيق. يقوم Starlette بتركيب عنوان كامل للطلب عبر دمج Host مع المسار المطلوب، ثم يتحقق من صحة أجزاء الطلب وفق قواعد قد لا تتطابق تمامًا مع طريقة تفسير الخادم للمدخلات.
عندما تحتوي ترويسة Host على أحرف مثل الشرطة المائلة أو علامة الاستفهام أو الرمز #، يمكن أن يتغير موضع بداية المسار كما يقرأه الإطار. والنتيجة أن التطبيق قد يظن أنه يتعامل مع عنوان مختلف عن العنوان الذي وصل إليه فعليًا، وهو ما يخلق فجوة أمنية قابلة للاستغلال.
في هذا السيناريو، يستقبل الخادم الطلب الحقيقي ويوجهه إلى المسار الصحيح، بينما تعتمد طبقات الوسط أو نقاط النهاية على النسخة المعدلة من العنوان. وإذا كانت قواعد الحماية تتحقق من المسار المعاد بناؤه، فقد تمرّ الطلبات إلى صفحات أو وظائف حساسة رغم أنها كان يجب أن تُرفض.
الأثر على تطبيقات الذكاء الاصطناعي
لا يقتصر الخطر على Starlette نفسه، بل يمتد إلى عدد كبير من الأدوات التي تبنى فوقه أو تعتمد عليه بصورة غير مباشرة. وتشمل هذه الأدوات منصات تشغيل النماذج، وخوادم الوكلاء، وواجهات OpenAI-compatible، وبوابات API، وخوادم Model Context Protocol.
يرى الباحثون أن بعض البيئات الأكثر عرضة للخطر هي تلك المستخدمة في التجارب، أو التقييم، أو التطوير، حيث يجري تشغيل التطبيق مباشرة على خادم التطبيق من دون وجود reverse proxy ملتزم بالمعايير الأمنية في المقدمة. في هذه الحالات، قد يصل الطلب المشوّه إلى التطبيق بدلًا من أن يتم رفضه عند الحافة.
أما المواقع الإنتاجية التقليدية، فغالبًا ما تقف خلف طبقة مثل nginx أو Apache HTTP Server، وهذه الطبقات عادةً ما تحجب الطلبات غير الصالحة قبل وصولها إلى التطبيق. لذلك فإن درجة التعرض تختلف كثيرًا بحسب البنية المعمارية ونمط النشر، وليس بحسب الاعتماد على Starlette وحده.
الخطورة الفعلية تتجاوز التقييم الأولي
رغم أن التقييم الرسمي في بعض الإشعارات جاء عند مستوى متوسط، فإن خبراء الأمن الذين راجعوا الثغرة يرون أن الأثر العملي قد يكون أعلى من ذلك بكثير. السبب أن التطبيقات المبنية على Starlette لا تستخدمه فقط لتقديم الواجهات، بل قد تعتمد عليه أيضًا في منطق الحماية والتحقق من الصلاحيات.
وفي بعض المشاريع، يمكن أن تتحول الثغرة من مجرد تجاوز للمصادقة إلى سلسلة استغلال أوسع تشمل طلبات SSRF، أو الوصول غير المصرح به إلى وظائف داخلية، أو حتى الوصول إلى تنفيذ أوامر عن بعد في بعض الحالات الشديدة. ويعتمد ذلك على كيفية تعامل التطبيق مع المسار المفترض، وما إذا كان يربط صلاحياته مباشرة بعنوان الطلب المعاد بناؤه.
كما أشار باحثون آخرون إلى أن التقييم الرقمي لا يعكس دائمًا حجم الانعكاس الفعلي على البنية التحتية المحيطة، خصوصًا في المنصات التي ظهرت بسرعة خلال العامين الماضيين لخدمة النماذج والوكلاء وطبقات التكامل بين التطبيقات والذكاء الاصطناعي.
من هم الأكثر عرضة
توجد ثلاث فئات تبدو الأكثر تعرضًا لهذا الخلل. الفئة الأولى هي التطبيقات التي تشغل FastAPI أو Starlette مباشرة على الخادم من دون reverse proxy متوافق أمامها. الفئة الثانية هي خدمات النماذج أو البوابات الوسيطة التي تُعرض للعالم على أنها نقاط وصول مباشرة. أما الفئة الثالثة فهي الأنظمة التي تبني قرارات الحماية على العنوان الذي يعيده الإطار بدلًا من قراءة المسار الخام كما وصل من العميل.
وتكمن المشكلة الإضافية في أن بعض المؤسسات قد لا تدرك أصلًا أنها تستخدم Starlette بشكل غير مباشر، لأن الحزمة قد تصل إليها عبر اعتماديات أخرى ضمن مشروع أكبر. وبحسب الباحثين، فإن قاعدة المشاريع المرتبطة به واسعة جدًا، ما يجعل نطاق التحديثات المطلوبة كبيرًا حتى لدى الفرق التي لم تختر الإطار عمدًا.
التوصية الأمنية والإجراءات العاجلة
الخطوة الأساسية التي أوصى بها الباحثون هي التحديث إلى Starlette 1.0.1 أو أي إصدار أحدث يتضمن معالجة للثغرة. الإصدار المصحح يتحقق من Host header بطريقة تمنع القيم المشوهة من المرور، ما يقلل احتمال انحراف المسار بين طبقات المعالجة.
كما شدد الباحثون على ضرورة مراجعة منطق الوصول في التطبيقات التي تستخدم FastAPI أو Starlette، والتأكد من أن الضوابط الأمنية تعتمد على البيانات الخام القادمة من الطلب، أو على طبقة تحقق موثوقة قبل الوصول إلى المنطق الحساس. وفي البيئات التي تُشغّل النماذج أو الوكلاء مباشرة، فإن إضافة reverse proxy صارم باتت خطوة دفاعية مهمة وليست اختيارًا تحسينيًا فقط.
وتبرز هذه الثغرة مثالًا جديدًا على أن أخطاء صغيرة في طبقة البنية التحتية يمكن أن تتحول إلى مخاطر واسعة عندما تُستخدم في أنظمة الذكاء الاصطناعي الحديثة. فمع توسع الاعتماد على FastAPI وStarlette في تشغيل خدمات النماذج والوكلاء، أصبح أمن طبقة الإطار البرمجي عنصرًا حاسمًا في حماية السلسلة كاملة، من الطلب الأول حتى الاستجابة النهائية.