Summary
MaxKB contains an insecure direct object reference in the model parameter form workflow, where model records are accessed by ID without consistently constraining queries to the authorized workspace.
An authenticated user with model read permission in one workspace may be able to read or overwrite parameter defaults belonging to a model in another workspace when its identifier is known, potentially changing workflows that rely on those defaults.
Affected context
The issue occurs in MaxKB deployments using the affected model parameter form route and serializer behavior. The route authorizes a workspace path, but model loading and saving may use only the model identifier, allowing an object from another workspace to be addressed when identifiers are known or discoverable.
Exploit preconditions
- Attack surface: Authenticated model parameter form API
- Required access: Model read permission in an attacker-controlled workspace
- Required knowledge: A valid model identifier associated with another workspace
- Trigger point: Model parameter form read or save operations
- Why exploitation is possible: Object queries are performed by model ID without reliably incorporating the authorized workspace identifier
Why this happens
The vulnerability is caused by an authorization and object-resolution mismatch. Although the request path establishes a workspace context, the serializer retrieves and persists the Model object using only its primary identifier rather than enforcing the workspace as part of the query.
This behavior maps to CWE-639: Authorization Bypass Through User-Controlled Key, because a user-controlled object reference can select a record outside the user's authorized ownership or tenant boundary.
Potential impact
- Model parameter values may be disclosed across workspace boundaries
- Unauthorized users could alter another workspace's model defaults
- Workflows relying on affected parameters could behave unexpectedly
- Model-driven processes could be disrupted or manipulated
- Cross-tenant confidentiality and integrity could be reduced
General mitigation guidance
Mitigation generally focuses on enforcing tenant or workspace authorization at every object access boundary.
Common defensive patterns include:
- Include the authorized workspace or tenant identifier in model lookup and update predicates
- Derive authorization scope from trusted server-side context rather than request-controlled object references
- Apply consistent ownership checks to both read and write operations
- Use repository or service-layer APIs that require an explicit authorization scope
- Return uniform errors for unauthorized and nonexistent objects where appropriate
- Limit model-management permissions according to least privilege
- Add tests covering cross-workspace object access and mutation
How teams detect issues like this
Detection approaches can include:
- Static analysis for queries that retrieve tenant-scoped records by ID alone
- Code review checks comparing route-level authorization with serializer and service-layer queries
- Search for update or save operations that lack workspace, tenant, or ownership predicates
- Automated authorization tests using object identifiers from separate workspaces
- Policy enforcement requiring scoped repository methods for multi-tenant resources
- Audit logging and alerting for cross-workspace access-denied events or unusual model-parameter changes
