Summary
MCP Atlassian does not consistently enforce configured tool restrictions when processing tool-call requests. A client that knows the name of an excluded tool may invoke read, write, or delete operations despite the operator's intended least-privilege configuration.
Affected context
The issue occurs in MCP Atlassian deployments that use ENABLED_TOOLS or TOOLSETS to restrict available tools. Those controls are applied while generating the tools/list response but may not be rechecked when a tools/call request is dispatched, allowing direct requests for tools omitted from the advertised set.
Exploit preconditions
- Attack surface: MCP tools/call request handling
- Required access: A client connection capable of submitting MCP tool-call requests
- Trigger point: Dispatch of a tools/call request for a restricted or hidden tool
- Why exploitation is possible: Tool visibility controls are enforced during listing but are not consistently enforced at invocation time, so knowledge of a tool name can bypass the configured restriction
Why this happens
The underlying flaw is an authorization enforcement gap. The server treats tool enumeration and tool execution as separate trust decisions, applying ENABLED_TOOLS and TOOLSETS to tools/list without repeating the same authorization check before execution through the tool-dispatch path. This behavior maps to CWE-862: Missing Authorization, because a request can reach protected functionality without a corresponding permission check.
Potential impact
- An attacker may read data through tools excluded by the operator
- An attacker may create or modify Atlassian content through unauthorized write tools
- An attacker may delete Jira or Confluence resources when delete tools are restricted
- Unauthorized actions could result in data exposure, integrity loss, or service disruption
General mitigation guidance
Mitigation generally focuses on enforcing authorization at every tool execution boundary rather than relying on tool enumeration.
Common defensive patterns include:
- Rechecking ENABLED_TOOLS and TOOLSETS before dispatching every tools/call request
- Applying deny-by-default authorization for tools and operations
- Treating tool names supplied by clients as untrusted input
- Separating permissions for read, write, and delete operations
- Running MCP integrations with only the Atlassian scopes and identities required for their intended tasks
- Logging and reviewing denied and successful tool invocations
How teams detect issues like this
Organizations can identify this class of issue through:
- Static analysis and code review checks confirming authorization at both listing and dispatch boundaries
- Tests that invoke tools omitted from tools/list and verify that authorization still rejects them
- Review of code paths connecting ENABLED_TOOLS, TOOLSETS, tools/call, and tool-dispatch handlers
- Runtime monitoring for calls to restricted, undocumented, or otherwise hidden tool names
- Policy enforcement requiring deny-by-default controls and operation-level permission checks
Automated security review tools may help identify mismatches between capability discovery and execution-time authorization.
