What is the CVSS score of CVE-2026-0562?

CVE-2026-0562 has a CVSS 3.1 base score of 8.3 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L. EPSS exploitation probability: 0.0%.

Which versions of Lollms are affected by CVE-2026-0562?

parisneo/lollms versions before 2.2.0 contain an authentication bypass flaw in friend request handling that allows any logged-in user to manipulate other users' social connections, potentially…. A patch is available.

How to fix or mitigate CVE-2026-0562?

Within 24 hours: Inventory all parisneo/lollms installations and document current versions. Within 7 days: Upgrade all instances to version 2.2.0 or later (commit c462977 or newer). Within 30 days: Audit friendship request logs for unauthorized modifications; implement additional authorization controls on social graph endpoints; conduct user awareness training on social engineering risks.

Lollms CVE-2026-0562

EUVD-2026-17039 HIGH

Incorrect Authorization (CWE-863)

2026-03-29 security@huntr.dev

Authentication Bypass Lollms

8.3

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

8.3 HIGH

AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L

Primary rating from NVD · only source for this CVE.

CVSS VectorNVD

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

Low

Lifecycle Timeline

Re-analysis Queued

Apr 22, 2026 - 16:22 vuln.today

cvss_changed

Analysis Updated

Apr 16, 2026 - 06:11 EUVD-patch-fix

executive_summary

Re-analysis Queued

Apr 16, 2026 - 05:29 backfill_euvd_patch

patch_released

Patch available

Apr 16, 2026 - 05:29 EUVD

2.2.0

EUVD ID Assigned

Mar 29, 2026 - 18:22 euvd

EUVD-2026-17039

Analysis Generated

Mar 29, 2026 - 18:22 vuln.today

CVE Published

Mar 29, 2026 - 18:16 nvd

HIGH 8.3

DescriptionCVE.org

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.

AnalysisAI

Authenticated users in parisneo/lollms (versions before 2.2.0) can hijack friend requests intended for other users through an Insecure Direct Object Reference (IDOR) flaw in the /api/friends/requests/{friendship_id} endpoint. The vulnerability enables any logged-in user to accept or reject friendship requests by manipulating the friendship_id parameter without authorization checks, leading to unauthorized social graph manipulation and potential account compromise via social engineering. Fixed in version 2.2.0 with commit c462977; no public exploit identified at time of analysis, though the attack is trivially reproducible with standard HTTP tools given the low complexity (CVSS AC:L) and authenticated network access (CVSS AV:N/PR:L).

Technical ContextAI

The vulnerability stems from CWE-863 (Incorrect Authorization) in the respond_request() function within backend/routers/friends.py of the lollms application framework. The affected endpoint implements a RESTful API pattern where friendship IDs are passed as path parameters (/api/friends/requests/{friendship_id}), but the backend logic fails to validate whether the authenticated session belongs to a participant in that friendship relationship. This represents a classic IDOR pattern where predictable or enumerable object identifiers (friendship IDs) can be manipulated without ownership verification. The vulnerability allows horizontal privilege escalation, as authenticated users can modify resources belonging to peer users at the same privilege level. The fix in commit c462977 likely introduces server-side authorization logic to verify the requesting user's identity matches either the friendship initiator or recipient before allowing state changes to the request object.

RemediationAI

Upgrade to lollms version 2.2.0 or later, which includes the authorization fix implemented in commit c46297799f8e1e23305373f8350746b905e0e83c available at https://github.com/parisneo/lollms/commit/c46297799f8e1e23305373f8350746b905e0e83c. The patch introduces proper authorization checks in the respond_request() function to validate that the authenticated user is either the initiator or recipient of the friendship request before allowing state changes. For organizations unable to immediately upgrade, interim mitigations include disabling the friends/social features if not operationally required, implementing API gateway-level authorization policies to restrict access to the /api/friends/requests/ endpoints based on user context, or deploying Web Application Firewall (WAF) rules to detect sequential friendship ID enumeration attempts. Review application logs for suspicious patterns such as single users accessing large numbers of friendship request IDs in short timeframes, which may indicate active exploitation attempts. Full remediation details are available in the HunTR disclosure at https://huntr.com/bounties/6aab01ca-a138-4a1d-bef9-3bce145359bf.