Loading vulnerability…
IDOR in parisneo/lollms friend request response endpoint
CVE-2026-0562 is an authorization flaw in parisneo/lollms affecting versions up to 2.2.0. The vulnerability exists in the respond_request() function in backend/routers/friends.py, exposed via the /api/friends/requests/{friendship_id} endpoint. The endpoint fails to verify that the authenticated user is either a participant in the referenced friendship or the intended recipient of the friend request before allowing the request to be accepted or rejected. As a result, any authenticated user who can supply or enumerate a valid friendship_id can perform state-changing actions on other users’ friend requests, constituting an insecure direct object reference (IDOR) caused by incorrect authorization.
What it means and what to do now: patch path, interim mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
Successful exploitation allows an authenticated attacker to manipulate the social relationship workflow of other users by accepting or rejecting their pending friend requests without authorization. This can cause unauthorized modification of application state, privacy violations, and loss of trust in relationship data. Depending on application behavior, attackers may infer relationship activity, interfere with user communications or visibility controls tied to friendship status, and facilitate social engineering by forcing or denying connections between users. The provided CVSS context indicates high confidentiality and integrity impact, with limited availability impact.
If you can’t patch tonight, do this now.
If immediate upgrade is not possible, restrict access to the affected friend-request response endpoint to trusted users only where feasible, and add server-side authorization checks that validate the authenticated user against the friendship record before processing any state change. Monitor for anomalous use of /api/friends/requests/{friendship_id}, especially repeated access to sequential or unrelated friendship IDs, and consider logging and alerting on failed or cross-user authorization attempts. Reducing identifier predictability may raise exploitation difficulty, but it is not a substitute for proper authorization enforcement.
Patch, then assume compromise.
Upgrade parisneo/lollms to version 2.2.0 or later, where the issue is reported as addressed. The vulnerable logic in respond_request() should enforce object-level authorization by verifying that the authenticated user is authorized to act on the specified friendship_id, specifically that they are the intended recipient or otherwise a legitimate participant in the friendship record before permitting accept/reject operations. Review similar endpoints for missing ownership or participant validation to prevent related IDOR issues.
No public exploits tracked yet. Mallory keeps watching.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
9 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.