MEDIUM 5.0

CVE-2026-59100: LobeChat Broken Authorization Allows Cross-User Agent Manipulation

LobeChat versions up to 2.2.9 suffer from a broken authorization flaw that allows authenticated users to view, modify, and delete chat agent data belonging to other users. By guessing or knowing other users' group identifiers, an attacker with valid login credentials can manipulate agent configurations in groups they don't own, effectively hijacking or disabling shared chat automation workflows without detection or consent.

Source data · NVD / CISA · public domain

CVSS
3.1 · 5.0 MEDIUM · CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L
Weaknesses (CWE)
CWE-639
Affected products
0 configuration(s)
Published / Modified
2026-07-02 / 2026-07-14

NVD description (verbatim)

LobeChat through 2.2.9 contains a broken object level authorization vulnerability that allows authenticated attackers to access and modify other users' chat-group agent data by supplying arbitrary group identifiers. Attackers can invoke the getGroupAgents, updateAgentInGroup, and removeAgentsFromGroup operations without user-scoped predicates to read agent listings, modify agent roles and ordering, and remove agents from chat groups belonging to other users.

4 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

This vulnerability represents a classic broken object-level authorization (BOLA) defect in LobeChat's agent management API. The getGroupAgents, updateAgentInGroup, and removeAgentsFromGroup endpoints fail to enforce user-scoped authorization checks, permitting any authenticated principal to operate on chat-group agent resources across tenancy boundaries. The absence of ownership validation on the group identifier parameter enables horizontal privilege escalation, allowing attackers to enumerate and manipulate agents in arbitrary groups. The attack surface is limited to authenticated sessions, but the impact spans confidentiality, integrity, and availability of multi-tenant agent configurations.

Business impact

Organizations relying on LobeChat for team-based chat automation face data contamination and workflow sabotage risks. An insider or compromised account can silently modify or remove agents from shared groups, disrupting customer-facing or internal automation pipelines. In multi-tenant SaaS deployments, one customer's operator could access or corrupt another customer's agent setups, violating data isolation expectations and compliance obligations. Remediation requires immediate re-authorization of all group-level operations and potential rollback or audit of agent configuration changes.

Affected systems

LobeChat through version 2.2.9 is affected. The vulnerability applies to all deployments (self-hosted and cloud) where the application exposes the getGroupAgents, updateAgentInGroup, and removeAgentsFromGroup API operations to authenticated users. Verify your current version against vendor release notes and security advisories to confirm impact scope in your environment.

Exploitability

Exploitation requires valid authentication credentials but no user interaction or privileged role. The attack complexity is moderate—attackers must identify or enumerate valid group identifiers—but once a target group is known, operations can be executed immediately. Automated enumeration of group IDs is feasible if they follow predictable patterns (e.g., sequential integers or weak UUIDs). The CVSS score of 5.0 (Medium) reflects the authenticated-only requirement balanced against the ease of execution once access is gained.

Remediation

Update LobeChat to a patched version that enforces user-scoped authorization checks on all agent group operations. Verify against the vendor advisory that the new version includes explicit ownership validation before allowing read, update, or deletion of agent data. Until patching is complete, restrict API access to group management operations through network-level controls or temporarily disable group-sharing features if operationally feasible.

Patch guidance

Consult the LobeChat project releases or security advisories to identify the fixed version that addresses CVE-2026-59100. Apply the patch during a maintenance window and validate that authorization checks are now enforced by testing inter-group access restrictions. Regression testing should confirm that legitimate group managers retain full permissions while non-members cannot access foreign groups. Monitor logs for anomalous group access patterns during and after the rollout.

Detection guidance

Monitor API audit logs for calls to getGroupAgents, updateAgentInGroup, and removeAgentsFromGroup that reference group IDs not associated with the calling user. Flag sequences of different group IDs accessed by a single authenticated user in short timeframes, which may indicate enumeration. Review agent configuration change logs for unexplained modifications to shared groups, especially removals or role changes by users without documented group membership. Alert on failed authorization responses (HTTP 403) that correlate with subsequent successful operations on different group identifiers.

Why prioritize this

Although the CVSS score is moderate, the vulnerability poses a direct threat to multi-tenant data isolation and team workflow integrity. Authenticated insider threats or lateral movement following an initial compromise can weaponize this flaw to disrupt operations or steal agent configurations. In regulated environments, unchecked cross-user data access may trigger compliance violations. Priority should reflect your deployment model: critical in SaaS multi-tenant, high in single-tenant with multiple team groups, medium in isolated single-group instances.

Risk score, explained

The CVSS 3.1 score of 5.0 is driven by the low attack vector (network-accessible, no special network positioning required), the requirement for authentication (PR:L), and the moderate complexity of discovering valid group identifiers. Confidentiality, integrity, and availability all suffer partial impact (C:L, I:L, A:L) because attackers can read agent lists, modify agent roles/ordering, and remove agents, but cannot directly exfiltrate passwords or crash the application. The user interaction requirement is none (UI:N), keeping the score from dropping further. In zero-trust or high-sensitivity environments, consider risk elevation due to insider threat vectors.

Frequently asked questions

Can an attacker without a LobeChat account exploit this?

No. The vulnerability requires valid authentication credentials. An attacker must first obtain or compromise a legitimate user account. However, once authenticated, the attacker does not need administrative privileges or special group membership to access other users' data.

How do I know if my LobeChat instance has been exploited?

Search audit logs for API calls to getGroupAgents, updateAgentInGroup, or removeAgentsFromGroup from user accounts accessing group IDs outside their documented scope. Look for agent configuration changes (role, ordering, removal) by users who should not have group access. Compare your logs against the list of groups each user should legitimately access, and flag outliers for investigation.

Does this affect deployments using single-group configurations?

No. The vulnerability requires attackers to know or guess other group identifiers. In deployments where each user or team operates only one group and group IDs are random and long, the practical attack surface is reduced, though the underlying flaw remains.

What should I do if I'm on version 2.2.9 and cannot immediately patch?

Restrict API access to group management endpoints using network firewalls or reverse proxies, limiting exposure to trusted internal networks. Temporarily disable group-sharing or multi-group features if feasible. Increase logging and monitoring of group-related API calls to detect anomalous activity. Plan an urgent patch deployment within 48–72 hours.

This analysis is for informational purposes and does not constitute legal or compliance advice. The vulnerability details are derived from published CVE records and vendor advisories; verify all patch versions and compatibility against official LobeChat documentation before deployment. No proof-of-concept exploit code or weaponized attack steps are provided. Organizations are responsible for assessing their own risk exposure and implementing appropriate controls. Source: NVD (public-domain), retrieved 2026-08-11. Analysis generated by SEC.co (claude-haiku-4-5).