CVE-2026-77523 in MaxKB
Summary
by MITRE • 09/21/2026
MaxKB is an open-source AI assistant for enterprise. In version 2.10.3-lts and earlier, the model parameter form route authorizes the path workspace but ModelSerializer.ModelParams loads and saves a Model by id alone without including workspace_id in the query. An authenticated user with model read permission in an attacker-controlled workspace can supply a known victim model_id to read or overwrite the victim's model_params_form in another workspace, potentially altering workflows that use those defaults. No fixed version is available as of this review.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/21/2026
The vulnerability identified in MaxKB versions 2.10.3-lts and earlier represents a critical Insecure Direct Object Reference (IDOR) flaw within the application's model parameter management system. This security defect stems from an insufficient authorization check during the handling of model parameters, specifically within the ModelSerializer.ModelParams component. The core technical issue lies in the fact that while the route authorizes access to the workspace context, the actual data retrieval and persistence operations rely exclusively on a unique identifier for the model without validating whether this model belongs to the authenticated user's authorized workspace. This architectural oversight creates a significant gap between logical authorization boundaries and physical data access controls, allowing an attacker to bypass intended isolation mechanisms by manipulating object identifiers directly.
From a technical perspective, the flaw exploits the lack of cross-referencing between the session context or request parameters indicating the current workspace and the database query used to fetch model details. When an authenticated user with read permissions for models within their own controlled workspace initiates a request to view or modify model parameters, the backend processes this request by querying the database using only the provided model_id. Because the system does not verify that the specified model_id is associated with the workspace_id of the requesting user's session, it returns data belonging to any other workspace where the attacker has at least read access to a model. This behavior violates the principle of least privilege and fails to enforce proper object-level authorization checks, which are fundamental requirements for secure multi-tenant or role-based applications as defined by industry standards such as CWE-639: Authorization Bypass Through User-Controlled Key.
The operational impact of this vulnerability is severe due to its potential for data manipulation and workflow disruption. An attacker can supply a known victim model_id from another workspace to read sensitive configuration details stored in the model_params_form, potentially exposing proprietary algorithms or integration credentials. More critically, the ability to overwrite these parameters allows an attacker to alter default behaviors associated with those models. Since many enterprise workflows rely on specific parameter defaults for automation and processing, modifying them can lead to incorrect data handling, service degradation, or even remote code execution if certain parameters control script injection points or external API calls. This effectively compromises the integrity of AI assistant operations across different organizational units within the same deployment instance.
This vulnerability aligns with several entries in the MITRE ATT&CK framework, particularly T1078: Valid Accounts and T1528: Steal Application Access Token if credentials are compromised to gain initial access, followed by T1496: Host Configuration Hijacking or similar lateral movement techniques depending on how the altered parameters affect downstream systems. The lack of workspace_id validation in the query logic is a classic example of horizontal privilege escalation where an actor moves laterally between isolated contexts without proper verification. As no fixed version was available at the time of review, immediate mitigation strategies must be implemented by administrators to reduce exposure.
To mitigate this risk, developers should enforce strict authorization checks that validate both the model_id and its associated workspace_id against the authenticated user's permissions before processing any read or write operations on model parameters. Implementing a middleware layer that intercepts requests and verifies ownership of the target resource is essential. Additionally, adopting parameterized queries with explicit joins to ensure data isolation can prevent such bypasses. Organizations using affected versions should restrict network access to the MaxKB interface until an official patch is released by the vendor, ensuring that only trusted internal networks or authenticated users with verified multi-factor authentication can interact with model configuration endpoints. Regular security audits focusing on IDOR vulnerabilities are recommended to detect similar patterns in other parts of the application logic.