Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as normal workspace user
-
DeliveryDiscover victim application's chat_id/chat_record_id
-
ExploitReference victim chat under attacker-owned application path
-
ExecutionRoute authorizes attacker app but loads global chat record
-
ImpactRead victim chat records; add_knowledge copies answers and mutates improve_paragraph_id_list
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization checks on every request
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires an authenticated normal user account within the SAME MaxKB workspace as the victim (PR:L). The attacker must own at least one application path plus a knowledge base and document (for the add_knowledge integrity vector), and must know a valid global chat_id and chat_record_id of a persisted, non-debug chat record belonging to a victim's published application - these IDs are not surfaced to the attacker's own views and must be discovered or enumerated, which is the primary practical limiter (AC:H). The flaw is that management chat-record routes authorize only the path application_id but load records by global chat_id/chat_record_id without verifying the chat belongs to the authorized application. Not remotely exploitable by an unauthenticated attacker and not exploitable across separate workspaces; no fixed version exists as of review. |
| Impact | This is a genuine but low-priority authorization flaw (IDOR / broken object-level authorization, CWE-862), not the 'Authentication Bypass' its tag implies. The CVSS 3.1 vector (AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N, base 4.2) is internally consistent and I broadly agree with it: exploitation is network-reachable but gated behind three real conditions - the attacker must be an authenticated normal user in the SAME MaxKB workspace, must already own an application/knowledge-base path to graft records onto, and must know a valid global chat_id/chat_record_id of a victim's persisted non-debug record (the source of AC:H, since these IDs are not exposed to the attacker's own views and must be discovered/enumerated). Impact is limited to partial confidentiality (reading victim chat records) and partial integrity (add_knowledge copies victim answers and mutates the victim record's improve_paragraph_id_list) - hence C:L/I:L, no availability impact. There is NO EPSS score, NO CISA KEV listing, and NO public POC in the provided intelligence, so all real-world-exploitation signals are absent. SSVC-wise this reads as low automatability (needs known victim chat_id and same-workspace foothold) with partial technical impact. Net: a real, verifiable authz defect worth patching when a fix ships, but not an urgent or widely-exploitable priority. Note the tag mislabeling and that no fixed version exists yet as of this review - this is a live, unpatched issue. |
| Exploit ScenarioDerived | An authenticated low-privileged user in a shared MaxKB workspace learns the chat_id of a persisted non-debug conversation belonging to a colleague's published application, then re-references that chat_id/chat_record_id under an application path they themselves own, causing the management chat-record route to return the victim's chat contents. Using their own knowledge base and document, they invoke add_knowledge to copy the victim's answers and simultaneously overwrite the victim record's improve_paragraph_id_list. No public exploit code is identified at time of analysis. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 21, 2026
Chat-record management routes in 1Panel-dev MaxKB 2.10.2-lts and earlier authorize only the application_id supplied in the request path, then load chat data using globally scoped chat_id and chat_record_id values without confirming that the chat actually belongs to that application, so a low-privileged authenticated user in the same workspace can read a victim's persisted chat records by re-homing a known chat_id under an application they own. Impact is limited (CVSS 4.2, C:L/I:L), the attack is network-reachable but requires an authenticated normal account in the victim's workspace and prior knowledge or enumeration of valid global chat identifiers, which is the dominant practical hurdle. A second variant uses the add_knowledge flow, available to any user with an owned knowledge base and document, to copy victim answers while overwriting the victim record's improve_paragraph_id_list. No public exploit code has been identified at time of analysis and no fixed version was available as of review; despite the supplied 'Authentication Bypass' tag, this is an object-level authorization/IDOR defect rather than a true auth bypass.
RemediationAI
No vendor-released patch was identified at time of analysis: the GHSA advisory (https://github.com/1Panel-dev/MaxKB/security/advisories/GHSA-7fmh-98f2-2cfg) states no fixed version is available as of review, so track that advisory and upgrade to the first patched MaxKB release as soon as it is published. Until then, the most effective compensating control is to restrict the management chat-record API routes so they are reachable only by trusted administrative networks or users rather than by all workspace members - for example, place MaxKB behind a reverse proxy or API gateway that blocks or allowlists the chat-record and knowledge-improvement endpoints for non-admin sessions; the trade-off is that legitimate administrators browsing chat history through those same paths will also be blocked unless allowlisted. Because the attack depends on possessing valid global chat_id/chat_record_id values, reducing exposure of those identifiers (avoiding their inclusion in shared links, logs, exports or client-side payloads) and treating them as sensitive lowers the practical exploitation rate, though it does not fix the underlying authorization gap. Tightening workspace membership by removing untrusted or unneeded user accounts limits the PR:L foothold the exploit requires, at the cost of reduced collaboration, and disabling self-service registration into existing workspaces is a reasonable additional step. Monitoring for add_knowledge calls that target chat records the caller does not own, or for abnormal improve_paragraph_id_list mutations on existing records, provides detection coverage while waiting for the upstream fix.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The flaw is CWE-862 (Missing Authorization) in the sense of broken object-level authorization: MaxKB's management chat-record endpoints enforce access control against the application_id in the URL path, but the record lookup itself keys off the global chat_id and chat_record_id, and no check verifies that the referenced chat belongs to the authorized application. Because chat_id and chat_record_id are global rather than tenant- or application-scoped, an attacker who owns any application path can route a victim's identifiers through it and have the record returned. The affected component is the chat-record/knowledge-improvement subsystem of MaxKB, an open-source enterprise AI assistant that manages applications, knowledge bases, documents and persisted (non-debug) chat history; the add_knowledge path additionally associates an improve_paragraph_id_list with the victim's record, allowing answer copying with a write side effect on victim data. The CPE cpe:2.3:a:1panel-dev:maxkb:*:*:*:*:*:*:*:* confirms the vendor/product identity (1Panel-dev MaxKB) with an open version range; the advisory states 2.10.2-lts and earlier are affected. The CVSS vector AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N and the independent assessment agree that this is not reachable by an unauthenticated attacker and is not cross-workspace, and the 'Authentication Bypass' tag in the feed overstates the defect.
Know when Maxkb gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N
Authenticated same-workspace user (PR:L) who must know a valid victim chat_id (AC:H); partial read of victim records and partial write via add_knowledge (C:L/I:L), no availability or scope change.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
DescriptionCVE.org
MaxKB is an open-source AI assistant for enterprise. In 2.10.2-lts and earlier, management chat-record routes authorize the path application_id but load records using global chat_id and chat_record_id values without confirming that the chat belongs to the authorized application. A normal user in the same workspace who knows the chat_id of a persisted non-debug record for a victim's published application can place it under a separate attacker-owned application path to read victim chat records. An attacker with an owned knowledge base and document can also use add_knowledge to copy victim answers while updating the victim record's improve_paragraph_id_list. No fixed version is available as of this review.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
MaxKB prior to version 1.10.8-lts contains an incomplete sandbox implementation that only blacklists binary execution in
Command injection in MaxKB before 2.10.5-lts allows unauthenticated remote attackers to execute arbitrary shell commands
Sandbox escape and privilege escalation in MaxKB 2.3.1 and earlier allow an attacker who can submit or trigger custom Py
Server-side request forgery in MaxKB before 2.10.0 allows any authenticated user holding the default workspace USER role
Authenticated workspace members on MaxKB deployments prior to 2.10.5-lts can escalate to root-level command execution by
Server-side request forgery in MaxKB (open-source AI assistant from 1Panel-dev) allows an authenticated user with permis
OS command injection in MaxKB (1Panel-dev's open-source enterprise AI assistant) before 2.10.0-lts lets an authenticated
Privilege escalation in MaxKB 2.3.1 and earlier allows an authenticated, low-privileged user to overwrite the built-in d
Authentication bypass in MaxKB (1Panel-dev) versions prior to 2.9.0 allows remote unauthenticated attackers to invoke we
Cross-workspace read and modification of model parameter defaults in MaxKB 2.10.3-lts and earlier is possible for an aut
Stored Cross-Site Scripting (XSS) via Eval Injection in MaxKB's Markdown rendering engine allows authenticated users to
Stored Cross-Site Scripting (XSS) in MaxKB 2.7.1 and below allows authenticated users to inject malicious JavaScript thr
EUVD-2026-84155
NVD
CVE.org
EPSS
GitHub
Exploit-DB