EUVD-2026-84197Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as normal workspace user
-
DeliveryQuery question-ranking endpoint with victim app name
-
ExploitHarvest disclosed application_id
-
ExecutionEmbed ID in attacker workflow node
-
PersistTrigger workflow to invoke victim app
-
ImpactExfiltrate victim output and write chat records under victim app
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 | Exploitation requires an authenticated normal user account WITHIN THE SAME MaxKB workspace as the victim (PR:L, insider/multi-tenant context). Concrete preconditions from the description: (1) the victim application must be PUBLISHED and have ranking activity within the date range the attacker selects on the homepage application question-ranking endpoint; (2) the attacker must know or correctly guess the victim application's NAME; (3) the attacker must be able to create and publish their own workflow application containing an application-node into which the disclosed application_id is placed. The limiting factors are significant: this is not remotely exploitable without a valid workspace account, direct application-detail and debug-open routes still deny access (only the ranking endpoint leaks the ID), and success depends on victim publication state and query-window activity. No fixed version exists, so mitigation is currently operational (restrict workspace membership / monitor cross-application invocation). |
| Impact | This is a moderate, authorization-scoped issue (CWE-862, Missing Authorization) rather than a critical remotely-exploitable flaw. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N, base 5.4) is internally consistent with the description: an already-authenticated (PR:L) normal user within the SAME workspace abuses a broken authorization check to read another user's application_id and then reuse it. There is no EPSS score, no CISA KEV listing, and no public POC referenced - only a GHSA advisory (GHSA-4w4r-h4x8-mg7h) reported by GitHub_M - so exploitation status is 'no public exploit identified at time of analysis.' The realistic priority is tempered by two factors: exploitation requires an insider (a valid, same-workspace account) and several environmental preconditions (victim app published, ranking activity in the queried window, and knowledge/guess of the app name), so this is a lateral-movement/tenant-isolation weakness, not an internet-facing pre-auth bug. Conflicting signal to note: the input tag says 'Authentication Bypass,' but the CWE (862) and description describe a broken OBJECT-level authorization (IDOR-style) flaw - no authentication is actually bypassed. Notably, NO FIXED VERSION exists as of this review, which raises operational urgency for multi-tenant MaxKB deployments despite the modest CVSS. |
| Exploit ScenarioDerived | A low-privileged but legitimate user in a shared MaxKB workspace guesses a colleague's published application name and queries the homepage question-ranking endpoint over a date range with activity, disclosing the victim's application_id even though direct detail/debug routes deny access. The attacker embeds that identifier in an application-node of their own workflow, triggers it, and receives output produced by the victim's application while writing durable application_chat and application_chat_record rows under the victim's app. No public POC is referenced; exploitation requires an authenticated same-workspace account. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 21, 2026
Missing authorization checks in the MaxKB enterprise AI assistant (2.10.2-lts and earlier) let an authenticated normal user in the same workspace harvest another user's application_id from the homepage application question-ranking endpoint, then place that identifier into an application-node of an attacker-owned published workflow application to obtain output generated by the victim application and create durable application_chat and application_chat_record rows under it. Exploitation is constrained: the victim application must be published and show ranking activity in the attacker-selected date range, the attacker must know or guess its name, and direct application-detail and debug-open routes continue to deny access - only the ranking endpoint leaks the identifier - and it requires a valid workspace account (CVSS 3.1 AV:N/PR:L, score 5.4). No public exploit identified at time of analysis and no fixed version is available as of this review.
RemediationAI
No vendor-released patch identified at time of analysis - the advisory itself states no fixed version is available as of this review - so remediation must be operational until an upstream fix is published (track GHSA-4w4r-h4x8-mg7h at https://github.com/1Panel-dev/MaxKB/security/advisories/GHSA-4w4r-h4x8-mg7h and apply the patched release as soon as it appears). Highest-value compensating control: restrict workspace membership so that no user can share a workspace with applications they are not trusted to invoke, and treat any workspace containing sensitive published applications as trusted-only; the trade-off is reduced collaboration and the need to split tenants into separate workspaces (workspace isolation is a strong boundary because exploitation requires same-workspace presence, PR:L). Second, remove or downgrade the ability of non-administrative users to create and publish workflow applications containing application-nodes, since the attack chain cannot complete without an attacker-controlled published workflow; the trade-off is that legitimate workflow authors lose self-service publishing and must go through an approval process. Third, disable or access-restrict the homepage application question-ranking feature where it is not needed, which removes the application_id disclosure primitive; the cost is loss of the ranking dashboard for all users. Fourth, monitor and alert on application_chat and application_chat_record rows written under an application whose owner differs from the invoking user, and on workflow runs where the same account both authors a workflow application and triggers invocations of other applications - this is detective rather than preventive but catches abuse already in progress. Finally, audit workspace accounts for stale, shared, or guest credentials, because a single valid normal user account is the entry prerequisite; rotating or revoking those accounts reduces the attack surface at the cost of administrative overhead.
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
MaxKB is an open-source, multi-tenant enterprise AI/LLM assistant platform maintained by 1Panel-dev, tracked under CPE cpe:2.3:a:1panel-dev:maxkb:*:*:*:*:*:*:*:*, in which users operate inside workspaces that own applications, chat sessions, and workflow definitions. The root cause is CWE-862 (Missing Authorization): the runtime invocation path and the persistence path for chats do not verify that the caller has permission to use the referenced application, so an application identifier accepted from a workflow application-node is trusted rather than re-authorized against the requesting principal. The identifier itself is disclosed through a secondary weakness in the homepage application question-ranking endpoint, which returns ranking data across applications without scoping results to the requesting user, exposing application_id values for published applications that have ranking activity in the queried date range. Once an attacker-owned workflow application containing that application-node is published and triggered, the platform renders the victim application's output and writes application_chat and application_chat_record rows attributed to the victim application, giving the attacker both cross-application data access (C:L) and unauthorized write/durable-state manipulation (I:L) with no integrity or availability impact beyond that. There is no scope change (S:U) because the impact stays within the same MaxKB authorization domain, and the vector requires low privileges (PR:L) rather than being unauthenticated.
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:L/PR:L/UI:N/S:U/C:L/I:L/A:N
Authenticated same-workspace user (PR:L) over the network with low complexity; limited confidentiality (leaked ID and victim output) and limited integrity (durable chat rows written under victim app); no availability impact.
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, a normal user in the same workspace can obtain another user's application_id from the homepage application question-ranking endpoint when the published victim application has ranking activity in the selected date range and the attacker knows or guesses its name, even though direct application detail and debug-open routes deny access. An attacker who can create and publish a workflow application can place the disclosed identifier in an attacker-owned workflow application-node, trigger that workflow, receive output generated by the victim application, and create durable application_chat and application_chat_record rows under the victim application because save and runtime paths do not verify permission to use the referenced application. No fixed version is available as of this review.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
GitHub
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
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
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
OS command injection in MaxKB (1Panel-dev's open-source enterprise AI assistant) before 2.10.0-lts lets an authenticated
Server-side request forgery in MaxKB (open-source AI assistant from 1Panel-dev) allows an authenticated user with permis
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
MaxKB versions 2.7.1 and below allow authenticated users with tool execution privileges to bypass the LD_PRELOAD-based s
MaxKB versions 2.7.1 and below allow authenticated attackers with workspace privileges to execute arbitrary code by expl
Exploit-DB