Summary
A broken object-level authorization vulnerability in obsidian-tc allows a valid token holder to select a different configured Obsidian vault than the one associated with their access context. Depending on the exposed tool, this may allow unauthorized reading, writing, or deletion of vault contents.
A broken object-level authorization vulnerability in obsidian-tc allows a valid token holder to select a different configured Obsidian vault than the one associated with their access context. Depending on the exposed tool, this may allow unauthorized reading, writing, or deletion of vault contents.
Affected context
The vulnerability affects obsidian-tc deployments prior to 1.3.1 where:
- Tool dispatch accepts a caller-controlled
input.vaultvalue. - The caller's JWT does not bind the token to a specific vault.
- Folder access-control lists are shared across configured vaults.
In these conditions, authorization checks may be evaluated without reliably
establishing that the requested vault belongs to the caller's authorized
context.
The vulnerability affects obsidian-tc deployments prior to 1.3.1 where:
- Tool dispatch accepts a caller-controlled
input.vaultvalue. - The caller's JWT does not bind the token to a specific vault.
- Folder access-control lists are shared across configured vaults.
In these conditions, authorization checks may be evaluated without reliably
establishing that the requested vault belongs to the caller's authorized
context.
Exploit preconditions
- Attack surface: Obsidian-tc MCP tool endpoints that accept a vault selector.
- Required access: A valid token recognized by the server.
- Trigger point: A tool request containing a vault selection that differs from
the vault associated with the caller's intended context.
- Why exploitation is possible: The server does not consistently bind the
request, token, and authorization scope to the same vault before allowing
the operation.
- Attack surface: Obsidian-tc MCP tool endpoints that accept a vault selector.
- Required access: A valid token recognized by the server.
- Trigger point: A tool request containing a vault selection that differs from
the vault associated with the caller's intended context.
- Why exploitation is possible: The server does not consistently bind the
request, token, and authorization scope to the same vault before allowing
the operation.
Why this happens
The underlying bug is an authorization failure caused by trusting a
caller-controlled object identifier without enforcing ownership or tenancy
boundaries. Tool dispatch uses the requested vault value without comparing it
with a vault identity bound to the caller, while the JWT lacks a vault claim
and folder access-control data is shared globally. This maps primarily to
CWE-639, Authorization Bypass Through User-Controlled Key, and is also
consistent with CWE-863, Incorrect Authorization.
The underlying bug is an authorization failure caused by trusting a
caller-controlled object identifier without enforcing ownership or tenancy
boundaries. Tool dispatch uses the requested vault value without comparing it
with a vault identity bound to the caller, while the JWT lacks a vault claim
and folder access-control data is shared globally. This maps primarily to
CWE-639, Authorization Bypass Through User-Controlled Key, and is also
consistent with CWE-863, Incorrect Authorization.
Potential impact
- An authenticated user may read data from another configured vault.
- An attacker could modify or delete files outside their authorized vault.
- Confidential notes, credentials, or operational information may be exposed.
- Cross-tenant data integrity could be compromised.
- The incident could enable follow-on abuse through trusted vault content.
- An authenticated user may read data from another configured vault.
- An attacker could modify or delete files outside their authorized vault.
- Confidential notes, credentials, or operational information may be exposed.
- Cross-tenant data integrity could be compromised.
- The incident could enable follow-on abuse through trusted vault content.
General mitigation guidance
Mitigation generally focuses on making vault identity server-controlled and
enforcing authorization before any tool operation or scope evaluation.
Common defensive patterns include:
- Bind tokens and request context to an explicit vault identity.
- Reject mismatched or caller-supplied vault identifiers before scope checks.
- Keep authorization policies and folder ACLs isolated per vault or tenant.
- Derive the target vault from trusted session context rather than request
parameters where possible.
- Apply least privilege to tokens and tool capabilities.
- Use deny-by-default authorization for cross-vault access.
- Record and review access attempts involving vault-selection mismatches.
Mitigation generally focuses on making vault identity server-controlled and
enforcing authorization before any tool operation or scope evaluation.
Common defensive patterns include:
- Bind tokens and request context to an explicit vault identity.
- Reject mismatched or caller-supplied vault identifiers before scope checks.
- Keep authorization policies and folder ACLs isolated per vault or tenant.
- Derive the target vault from trusted session context rather than request
parameters where possible.
- Apply least privilege to tokens and tool capabilities.
- Use deny-by-default authorization for cross-vault access.
- Record and review access attempts involving vault-selection mismatches.
How teams detect issues like this
Detection approaches may include:
- Static analysis and code review for authorization decisions based directly
on request-supplied object or tenant identifiers.
- Checks confirming that JWT claims, session context, and requested resources
are compared before access-control evaluation.
- Tests that attempt access to each configured vault using tokens bound to a
different vault.
- Policy enforcement requiring tenant-scoped ACL storage and deny-by-default
behavior.
- Audit monitoring for cross-vault reads, writes, deletes, and rejected vault
mismatches.
Automated security review tools can help identify missing object-ownership
checks, but authorization tests should validate deployment-specific behavior.
Detection approaches may include:
- Static analysis and code review for authorization decisions based directly
on request-supplied object or tenant identifiers.
- Checks confirming that JWT claims, session context, and requested resources
are compared before access-control evaluation.
- Tests that attempt access to each configured vault using tokens bound to a
different vault.
- Policy enforcement requiring tenant-scoped ACL storage and deny-by-default
behavior.
- Audit monitoring for cross-vault reads, writes, deletes, and rejected vault
mismatches.
Automated security review tools can help identify missing object-ownership
checks, but authorization tests should validate deployment-specific behavior.
