Description

MaxKB is an open-source AI assistant for enterprise. From version 2.0.0 through 2.10.2-lts, document and paragraph operate routes authorize only knowledge_id in the request path, then query the target Document by document_id or Paragraph by paragraph_id without confirming that the object belongs to that knowledge base. A normal workspace user with a known victim document or paragraph UUID can use an attacker-owned knowledge-base path to read or modify content in another user's knowledge base. No fixed version is available as of this review.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.4",
  "pubDate": "2026-09-21T21:17:10.317Z",
  "pubdate": "2026-09-21T21:17:10.317Z",
  "executiveSummary": "The vulnerability is a Broken Object Level Authorization (BOLA) flaw within MaxKB, affecting versions 2.0.0 through 2.10.2-lts.\nThis security defect permits an authenticated user to perform unauthorized read or modification operations on documents and paragraphs stored in knowledge bases they do not own or possess access rights to.\nThe risk implication is significant as it allows for unauthorized data access and manipulation, compromising the confidentiality and integrity of sensitive enterprise knowledge stored within the platform.\nAn attacker requires valid workspace user credentials and the knowledge of specific document_id or paragraph_id UUIDs to execute the attack.\nNo fixed version currently exists, leaving installations exposed to exploitation by any authenticated entity within the workspace.",
  "technicalDetails": "The root cause of this vulnerability lies in improper server-side authorization checks within the document and paragraph handling routes.\nWhile the application enforces a check based on the knowledge_id provided in the request path, it fails to perform an ownership validation or cross-reference check between the requested document_id (or paragraph_id) and the verified knowledge_id.\nConsequently, the system implicitly trusts the object identifier provided by the client without verifying that the target object resides within the context of the associated knowledge base.\nThe attack flow follows a predictable pattern: An attacker initiates a request to the server by supplying a legitimate knowledge_id for which they have authorization, but crafts the target object identifiers (document_id or paragraph_id) to point to sensitive content owned by another user or belonging to a restricted knowledge base.\nBecause the backend logic directly queries the database for the object identified by the UUID without validating the relationship between the object and the knowledge_id provided in the URI, the application processes the request as legitimate.\nThis mechanism allows an attacker to perform CRUD (Create, Read, Update, Delete) operations on arbitrary documents. By manipulating these parameters, a standard user can bypass intended access control boundaries.\nThe vulnerability is prevalent in API endpoints responsible for document and paragraph management across versions 2.0.0 to 2.10.2-lts.\nExploitation requires authenticated access, meaning the attacker must be a legitimate user of the platform. However, once authenticated, no additional privileges are necessary to perform these unauthorized actions.\nThe network exposure is restricted to the web application's API surface, which is typically accessible to all authenticated users. The impact post-exploitation includes unauthorized disclosure of proprietary information, potential data corruption, or the deletion of critical enterprise documentation, leading to a breakdown in platform security and information governance."
}