A critical security vulnerability in parisneo/lollms versions up to 2.2.0 allows any authenticated user to accept or reject friend requests belonging to other users. The `respond_request()` function in `backend/routers/friends.py` does not implement proper authorization checks, enabling Insecure Direct Object Reference (IDOR) attacks. Specifically, the `/api/friends/requests/{friendship_id}` endpoint fails to verify whether the authenticated user is part of the friendship or the intended recipient of the request. This vulnerability can lead to unauthorized access, privacy violations, and potential social engineering attacks. The issue has been addressed in version 2.2.0.
CVE-2026-0562 is a critical Insecure Direct Object Reference (IDOR) vulnerability in LOLLMS versions up to 2.2.0 that allows authenticated users to manipulate friend requests belonging to other users. The `/api/friends/requests/{friendship_id}` endpoint lacks proper authorization checks, enabling attackers to accept or reject friend requests they should not have access to. This vulnerability poses significant risks to user privacy, account security, and potential social engineering attack vectors. Immediate patching to version 2.2.0 or later is strongly recommended.
IMMEDIATE ACTIONS:
1. Identify all LOLLMS instances in your environment running versions prior to 2.2.0
2. Disable or restrict access to the `/api/friends/requests/` endpoint until patching is complete
3. Review access logs for suspicious friend request manipulation activities
4. Notify users of potential unauthorized friend request modifications
PATCHING GUIDANCE:
1. Upgrade LOLLMS to version 2.2.0 or later immediately
2. Test the patch in a staging environment before production deployment
3. Verify that authorization checks are properly implemented in the `respond_request()` function
4. Confirm that users can only modify friend requests where they are the intended recipient
COMPENSATING CONTROLS (if immediate patching is not possible):
1. Implement API gateway-level authorization checks to verify user identity matches friendship_id recipient
2. Add request logging and alerting for friend request modifications
3. Implement rate limiting on the `/api/friends/requests/` endpoint
4. Restrict API access to trusted internal networks only
DETECTION RULES:
1. Monitor for multiple friend request modifications from single user in short timeframe
2. Alert on friend request responses where user_id does not match friendship recipient_id
3. Track failed authorization attempts on friendship endpoints
4. Implement WAF rules to detect IDOR patterns in friendship_id parameters
الإجراءات الفورية:
1. حدد جميع مثيلات LOLLMS في بيئتك التي تعمل بإصدارات سابقة للإصدار 2.2.0
2. عطّل أو قيّد الوصول إلى نقطة النهاية `/api/friends/requests/` حتى اكتمال التصحيح
3. راجع سجلات الوصول للأنشطة المريبة في التلاعب بطلبات الصداقة
4. أخطر المستخدمين بالتعديلات المحتملة غير المصرح بها على طلبات الصداقة
إرشادات التصحيح:
1. قم بترقية LOLLMS إلى الإصدار 2.2.0 أو أحدث على الفور
2. اختبر التصحيح في بيئة التدريج قبل نشر الإنتاج
3. تحقق من تطبيق فحوصات التفويض بشكل صحيح في دالة `respond_request()`
4. تأكد من أن المستخدمين يمكنهم فقط تعديل طلبات الصداقة حيث يكونون المستقبل المقصود
الضوابط البديلة (إذا لم يكن التصحيح الفوري ممكناً):
1. تطبيق فحوصات التفويض على مستوى بوابة API للتحقق من هوية المستخدم مع معرّف الصداقة
2. إضافة تسجيل التنبيهات لتعديلات طلبات الصداقة
3. تطبيق تحديد معدل على نقطة النهاية `/api/friends/requests/`
4. تقييد وصول API إلى الشبكات الداخلية الموثوقة فقط
قواعد الكشف:
1. مراقبة تعديلات طلبات الصداقة المتعددة من مستخدم واحد في إطار زمني قصير
2. تنبيه استجابات طلبات الصداقة حيث لا يتطابق معرّف المستخدم مع معرّف المستقبل
3. تتبع محاولات التفويض الفاشلة على نقاط نهاية الصداقة
4. تطبيق قواعد WAF للكشف عن أنماط IDOR في معاملات friendship_id