CVE-2026-0562: Lollms Auth Bypass Vulnerability (IDOR)

CVE-2026-0562 Overview

A critical security vulnerability has been identified in parisneo/lollms versions prior to 2.2.0 that 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. This vulnerability affects the /api/friends/requests/{friendship_id} endpoint, which fails to verify whether the authenticated user is part of the friendship or the intended recipient of the request.

Critical Impact

Authenticated attackers can manipulate friend request responses for any user, leading to unauthorized access, privacy violations, and potential social engineering attacks through forced friend connections.

Affected Products

• lollms versions prior to 2.2.0
• parisneo/lollms backend API components
• lollms friend request management functionality

Discovery Timeline

• 2026-03-29 - CVE-2026-0562 published to NVD
• 2026-03-31 - Last updated in NVD database

Technical Details for CVE-2026-0562

Vulnerability Analysis

This vulnerability is classified as CWE-863 (Incorrect Authorization), specifically manifesting as an Insecure Direct Object Reference (IDOR) flaw. The vulnerable endpoint allows any authenticated user to interact with friendship records they do not own by simply manipulating the friendship_id parameter in the API request path.

The attack can be performed over the network without any user interaction. An attacker with low-privilege access (any authenticated user) can exploit this vulnerability to achieve significant confidentiality and integrity impacts by manipulating social connections between arbitrary users. The vulnerability also has a limited availability impact on the affected system's friend management functionality.

Root Cause

The root cause lies in the respond_request() function within backend/routers/friends.py. This function processes friend request responses but fails to verify that the authenticated user making the request is actually the intended recipient of the friend request or a legitimate party to the friendship. The endpoint blindly trusts the friendship_id parameter without validating ownership or authorization.

Attack Vector

The attack vector is network-based, targeting the REST API endpoint /api/friends/requests/{friendship_id}. An attacker can enumerate or guess valid friendship_id values and submit accept or reject responses for friend requests belonging to other users. This allows the attacker to:

1. Force friend connections between arbitrary users by accepting pending requests
2. Block legitimate friend connections by rejecting pending requests
3. Manipulate the social graph of the application for social engineering purposes

The vulnerability exists because the endpoint only checks authentication (is the user logged in?) but not authorization (does this user have permission to act on this specific friendship request?). An attacker simply needs to send authenticated API requests with different friendship_id values to exploit this flaw.

Detection Methods for CVE-2026-0562

Indicators of Compromise

• Unusual patterns of friend request accept/reject actions originating from single user accounts
• API logs showing access to /api/friends/requests/{friendship_id} endpoints with sequential or enumerated friendship IDs
• User complaints about unexpected friend connections or rejected friend requests they didn't initiate
• High volume of friend request API calls from individual authenticated sessions

Detection Strategies

• Monitor API access logs for authenticated users accessing friendship endpoints with IDs that don't belong to their account
• Implement rate limiting detection on the /api/friends/requests/ endpoint to identify enumeration attempts
• Deploy application-layer intrusion detection rules to flag sequential friendship_id access patterns
• Enable detailed audit logging for all friend request state changes including the acting user

Monitoring Recommendations

• Configure alerts for friend request API endpoints receiving requests at abnormal rates
• Implement user behavior analytics to detect accounts manipulating friendships they shouldn't have access to
• Review API gateway logs for patterns consistent with IDOR exploitation attempts
• Establish baseline metrics for normal friend request activity to identify anomalies

How to Mitigate CVE-2026-0562

Immediate Actions Required

• Upgrade lollms to version 2.2.0 or later immediately
• Review friend connection records for unauthorized modifications if running a vulnerable version
• Audit API access logs for potential exploitation attempts prior to patching
• Notify users if unauthorized friend connections may have been established

Patch Information

The vulnerability has been addressed in lollms version 2.2.0. The fix is available in commit c46297799f8e1e23305373f8350746b905e0e83c. Organizations should review the GitHub Commit Details for technical information about the patch implementation.

Additional details about the vulnerability discovery and disclosure process are available in the Huntr Bounty Report.

Workarounds

• If immediate upgrade is not possible, consider temporarily disabling the friend request functionality at the reverse proxy or API gateway level
• Implement additional authorization middleware to validate friendship ownership before processing requests
• Restrict access to the /api/friends/requests/ endpoints to trusted networks while awaiting patch deployment
• Monitor all friend request API activity closely until the patch can be applied

# Temporary mitigation: Block vulnerable endpoint at reverse proxy (nginx example)
location ~ ^/api/friends/requests/ {
    # Temporarily deny access until patch is applied
    deny all;
    return 503;
}