CVE-2026-58580
Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.
NVD · uneditedLobeChat through 2.2.9 server-database deployments are vulnerable to broken object-level authorization in MessageModel. The updateMessagePlugin, updatePluginState, updatePluginError, updateTTS and updateTranslate methods filter target rows by message id alone, omitting the userId scope that sibling methods apply, and findMessagePlugin reads back by id alone. Reachable via the corresponding tRPC message procedures, an authenticated user who knows another user's message identifier can overwrite that victim's plugin tool-call metadata, plugin state/error, text-to-speech and translation records on the same instance, and the tampered content is served back to the victim. Exploitation requires knowledge of the victim's non-enumerable message identifier.
Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.
dbcve analysis · high confidenceLobeChat through 2.2.9 contains a Broken Object-Level Authorization (BOLA) vulnerability in MessageModel where five methods (updateMessagePlugin, updatePluginState, updatePluginError, updateTTS, updateTranslate) and findMessagePlugin filter target rows only by message ID without verifying user ownership, allowing any authenticated user to modify another user's message metadata by knowing the victim's message identifier.
Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.
CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.
From the vector- Attack vector
- Network
- Complexity
- High
- Privileges
- Low
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- Low
- Integrity
- High
- Availability
- None
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:H/A:N
Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.
dbcve checksWork through these to decide whether this CVE applies to you.
-
Identify LobeChat installation and versionCheck your installed LobeChat version (e.g., via package.json, container labels, or running `npm list lobe-chat` or checking the /api/health endpoint response). Compare against the affected range: versions through 2.2.9 are vulnerable.Affected if Version is 2.2.9 or lower (any version up to and including 2.2.9).
-
Locate MessageModel source codeFind the MessageModel file in the codebase, typically in src/database/models/MessageModel.ts or similar path under the LobeChat source directory.Affected if MessageModel file exists in the codebase.
-
Inspect vulnerable methods for user ownership validationOpen MessageModel and locate the five methods: updateMessagePlugin, updatePluginState, updatePluginError, updateTTS, and updateTranslate. Examine each method body to see if it validates that the message belongs to the requesting user (e.g., by checking userId or equivalent ownership field) before performing the update operation.Affected if Any of these five methods filter only by messageId without also verifying user ownership.
-
Check findMessagePlugin for missing authorizationLocate the findMessagePlugin method in MessageModel and verify whether it filters results by both messageId and userId, or only by messageId.Affected if findMessagePlugin filters only by messageId without user ownership verification.
-
Review API layer for endpoint authorizationExamine the API routes or service layer that calls these MessageModel methods. Check if the API layer passes the userId context to ensure users can only act on their own messages.Affected if API routes call these methods without passing or validating user context.
You are affected if you are running LobeChat version 2.2.9 or lower and the MessageModel methods (updateMessagePlugin, updatePluginState, updatePluginError, updateTTS, updateTranslate, findMessagePlugin) lack user ownership checks, allowing any authenticated user to modify another user's message metadata by message ID alone.
Generated from the published advisory. Verify against your own configuration.
Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.
dbcve · scopedAdd userId scope validation to all affected methods to ensure users can only access and modify their own message records, similar to how sibling methods in the codebase properly enforce ownership.
Latest stable release above 2.2.9 (e.g., 2.3.0 or later)
- 1. Identify the current LobeChat version by checking package.json or running `lobe-chat --version`
- 2. Upgrade to the latest stable release above version 2.2.9, as versions after 2.2.9 contain the fix for this IDOR vulnerability
- 3. After upgrade, verify the MessageModel methods (updateMessagePlugin, updatePluginState, updatePluginError, updateTTS, updateTranslate) now include userId scope validation
- 4. Test that users can only modify their own messages and cannot access or modify other users' message records
Generated from the published advisory — verify against the referenced sources before acting.
- Consultation2.0 h
- Implementation4.0 h
- Testing2.0 h
- Review / QA1.0 h
An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $2,560.
Scan for this in your stack
Free · runs locallyCheck whether your project pulls in CVE-2026-58580 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Primary sourcesPractitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2026-58580 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
No notes yet
Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.
A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.
- Verified mitigations, workarounds, and config changes
- Version or environment caveats, and links to real fixes
- No weaponised exploit code, or anything meant to cause harm
- No spam, self-promotion, credentials, or personal data