دراسة لمحرر Cursor تكشف أربع ثغرات في حماية محرر الأكواد، لكنها لم تتمكن من كسر التفويض

أظهر تدقيق أمني لمحرر Cursor نتيجة نادرة في أدوات الذكاء الاصطناعي: لم يتمكن الباحث من تجاوز التفويض على الخادم والوصول إلى النماذج المتقدمة عبر ثغرة في العميل، لكنه رصد في أثناء ذلك أربع مشكلات لافتة في منظومة الحماية. وتكمن أهمية هذا التحليل في أنه ليس قصة عن «انهيار كل شيء»، بل فحص مفصّل لكيفية بناء محرر يعتمد على الذكاء الاصطناعي ويمرّر عبر خوادمه كميات كبيرة من أكواد المطورين وطلباتهم.

بدأت الدراسة بفك تجميع عميل Cursor المبني على Electron، وهو قائم على VS Code. وفي ملف JavaScript واحد مصغّر (minified) يتجاوز حجمه 1.1 مليون سطر، أعاد المؤلف بناء أوصاف protobuf، وخريطة الـ API، ومنطق OAuth، وقائمة feature gates. كما بيّن أن رمز JWT الخاص بالمستخدم لا يحتوي على claims تتعلق بالاشتراك أو الباقة: فصلاحيات الوصول إلى النماذج لا يتم التحقق منها في جهة العميل ولا عبر محتوى الرمز، بل على الخادم استناداً إلى بيانات قاعدة البيانات. وبالنسبة إلى منتج SaaS يعتمد على LLM مكلفة، يُعد هذا خياراً معمارياً محورياً، إذ يمنع هذا التصميم المستخدم «المجاني» من تبديل المعلمات المحلية ببساطة لفتح Claude 4 Opus أو أي نموذج متقدم آخر.

بعد الهندسة العكسية، انتقل الباحث إلى مهاجمة الـ API. أول ما وجده هو prototype pollution في نقاط نهاية JSON المرتبطة بالاشتراك والعروض الترويجية. فإذا أُضيفت إلى جسم الطلب حقول مثل __proto__ أو constructor.prototype، يعيد الخادم الخطأ 500 Internal Server Error بدلاً من الرفض المتوقع. ولا يؤدي ذلك إلى رفع الباقة تلقائياً، لكنه يدل على أن تلويث سلسلة prototype يحدث قبل فحوصات منطق الأعمال، وقد يغيّر مسار التحقق.

المشكلة الثانية هي الحقل المخفي devRawModelSlug في AgentRunRequest. فهو غير موجود في مخطط العميل، لكن خوادم الإنتاج تقبله وتتعرف على اسمه وتردّ بخطأ مخصص، يتبيّن منه وجود آلية تطوير تتيح تحديد النموذج الخلفي مباشرة متجاوزةً التوجيه (routing) القياسي. هذا المسار معطّل حالياً، لكن وجوده في بيئة الإنتاج يرفع خطر أخطاء الإعداد.

أما الثغرتان الأخريان فلا ترتبطان بتجاوز الاشتراك، بل بالكشف الزائد عن البنية الداخلية والتحقق غير المكتمل. فإحدى الطرق الداخلية ترد برسالة Invalid internal service header، ويمكن أن يُستنتج منها أن نقطة النهاية موجودة، وأنها محمية بتفويض خاص بين الخدمات (service-to-service)، وأنها تتوقع ترويسة خاصة. وهذا المستوى من التفصيل غير ضروري للعميل الخارجي: فالأكثر أماناً هو الرد بـ 404 أو 401 عامين دون تلميحات داخلية.

إضافة إلى ذلك، أظهر التدقيق أن بعض حقول protobuf الخاصة بسيناريوهات subagent تقبل إشارات إلى النماذج المتقدمة دون فحص مستقل للباقة (plan check). عملياً، لا يغيّر ذلك النموذج الفعلي الذي يجيب ولا يفتح bypass، لأن الـ routing يتجاهل هذه الحقول على أي حال، لكن هذا المنطق يوسّع سطح الهجوم (attack surface) وقد يصبح مشكلة بعد تغييرات مستقبلية في المنتج.

ومن الأجزاء المهمة في التحليل قائمة المحاور التي لم تنجح. فقد اختبر المؤلف bruteforce لأسماء النماذج، وتزوير claims في JWT، وحقن الشيفرة في OAuth callback، وإعادة تشغيل (replay) لـ Stripe webhook، والخلط بين requested_model وmodel_details، وتعارض wire types في protobuf، وسباقات التنفيذ (race conditions) المتعلقة بالاشتراك. ولم ينجح أي منها في تحقيق تجاوز جوهري. فالخادم يرفض وسوم protobuf غير الصحيحة، ولا يثق بالبيانات الواردة من JWT، ويتحقق من توقيعات Stripe، ويُبقي فحص الباقة مركزياً. وهذا يعزز الاستنتاج: المشكلات موجودة فعلاً، لكن نموذج الحماية الأساسي في Cursor يبدو ناضجاً ومدروساً مقارنة بكثير من خدمات الذكاء الاصطناعي التي تمنح العميل ثقة مفرطة.

والمغزى العملي لهذه القصة يتجاوز Cursor نفسه. فبالنسبة إلى مطوري AI-SaaS، تمثل قائمة تحقق جيدة: عدم تخزين الصلاحيات في الرمز، والتحقق من الباقة على الخادم مع كل طلب، والتحقق الصارم من protobuf، وعدم ترك حقول التطوير في مخططات الإنتاج. وبالنسبة إلى المستخدمين، هي إشارة إلى أن حتى بيئات التطوير المتقدمة المعتمدة على الذكاء الاصطناعي (AI-IDE) تبقى لها سطح ضعيف حول الفوترة والخدمات الداخلية وآليات توجيه النماذج الخاصة. والأهم أن أمن منتج الذكاء الاصطناعي اليوم لا يُقاس بعدد النماذج التي يدعمها، بل بمدى انضباطه في فصل العميل عن صلاحيات الوصول الفعلية على الخادم.