Summary
ArcadeDB's MCP HTTP transport fails to correctly bind the authenticated principal to engine-level permission checks, causing authorization logic to be skipped.
Under these conditions, any MCP-allowed but non-root user can perform unrestricted database writes, schema changes, and execute arbitrary JavaScript via the query interface.
Affected context
The vulnerability occurs in ArcadeDB deployments using the MCP HTTP transport where authorization checks depend on a bound authenticated principal.
When the principal is not propagated into the engine's permission layer, the checks effectively become no-ops.
This primarily affects environments that:
- Expose the MCP HTTP endpoint to multiple authenticated users
- Rely on role-based restrictions for database writes or DDL
- Use the query tool for executing JavaScript or dynamic queries
Exploit preconditions
- Attack surface: MCP HTTP transport and its associated query endpoints.
- Required access: Valid credentials for any MCP-allowed non-root user.
- Trigger point: Issuing write, DDL, schema mutation, or JavaScript execution requests through MCP.
- Why exploitation is possible: The authenticated principal is not bound into the engine's permission evaluation, so authorization checks default to allowing operations regardless of the caller's actual role.
Why this happens
This issue stems from incomplete enforcement of authentication and authorization in the request handling path.
The MCP HTTP transport authenticates users but fails to bind the resulting principal into the underlying engine's permission context.
As a result, authorization checks operate without a meaningful subject, mapping directly to CWE-306: Missing Authentication for Critical Function, in the sense that critical operations (writes, DDL, code execution) are effectively executed without proper identity-based verification.
Conceptually, the bug is an authorization bypass caused by missing principal propagation rather than explicit permission logic.
Potential impact
- Non-root users may perform arbitrary database writes that could corrupt or overwrite critical data.
- Users could alter or drop schemas, indexes, and constraints, impacting application stability and integrity.
- Arbitrary JavaScript code may be executed via the query tool, potentially enabling server-side logic manipulation.
- Separation-of-duties and least-privilege models can be undermined, allowing broad misuse of administrative capabilities.
- Data integrity, confidentiality, and availability can be significantly compromised, especially in multi-tenant deployments.
General mitigation guidance
Effective mitigation focuses on ensuring that authentication information is consistently bound into authorization checks and that critical operations never run without a validated principal.
Common defensive patterns include:
- Enforcing strict principal propagation from the transport layer into the engine's permission system.
- Implementing centralized authorization middleware that validates the caller's identity before any write, DDL, or code-execution operation.
- Applying least-privilege roles and restricting access to high-risk endpoints (such as query tools capable of running JavaScript).
- Introducing defense-in-depth checks at multiple layers (transport, service, engine) so a single binding failure does not silently grant broad privileges.
- Logging and auditing all critical operations with associated identity metadata to detect anomalies and misconfigurations early.
How teams detect issues like this
Detection efforts can focus on both configuration and behavior:
- Reviewing code paths for MCP HTTP request handling to verify that an authenticated principal is passed into all permission checks.
- Using static analysis or linters to flag authorization routines that operate without an explicit principal or role context.
- Conducting targeted code reviews for critical database operations (DDL, schema mutations, JavaScript evaluation) to ensure they depend on verified identity and role data.
- Monitoring runtime logs for non-root users performing administrative actions, which may indicate missing or faulty authorization enforcement.
- Leveraging automated security testing tools that simulate requests from low-privilege accounts and verify that access controls behave as expected.
