| Package | Affected versions | Patched versions |
|---|---|---|
| mcp-atlassian | < 0.22.0 | 0.22.0 |
| mcp atlassian | < 0.22.0 | 0.22.0 |
ENABLED_TOOLS and TOOLSETS filters are enforced at tools/list time only. tools/call dispatches from the full unfiltered tool registry (73 tools). Any user with access to the server endpoint that knows a tool name can invoke it directly. Tool names are not secret since mcp-atlassian is open source. Any direct JSON-RPC call bypasses the restriction entirely.
READ_ONLY_MODE is not affected: it has dual enforcement at list time (_list_tools_mcp) and call time @check_write_access decorator. The developers applied the correct pattern to READ_ONLY_MODE but not to ENABLED_TOOLS or toolsets - confirming this is an implementation oversight.
Any user with access to the MCP server's HTTP endpoint can invoke any of the 73 registered tools regardless of ENABLED_TOOLS or TOOLSETS configuration - including write and delete operations on Jira issues, Confluence pages, etc. Operators deploying mcp-atlassian via Streamable HTTP rely on ENABLED_TOOLS to enforce least-privilege access; the bypass invalidates that model entirely.
The security impact concentrates in multi-user / HTTP-transport deployments, where the tool filter is a trust boundary between clients. In a single-user stdio deployment there is no second principal to defend against.
In src/mcp_atlassian/servers/main.py, AtlassianMCP overrides _list_tools_mcp and applies the TOOLSETS and ENABLED_TOOLS filters before returning the tool list to clients. The _call_tool_mcp handler is not overridden. FastMCP's default _call_tool_mcp resolves the tool from the local tool manager / mounted servers, the full unfiltered inventory, so the filters never apply at call time.
All calls are issued against the HTTP transport, with ENABLED_TOOLS=jira_search configured - only jira_search should be reachable.
Step 1 - negative control: tools/list correctly filters by ENABLED_TOOLS:
req → tools/list
← { "tools": [ { "name": "jira_search" } ] } # only 1 tool; jira_get_issue / jira_create_issue absent
Step 2 - confidentiality bypass: tools/call dispatches jira_get_issue despite its exclusion from the list:
req → tools/call jira_get_issue { "issue_key": "SEC-1" }
← { ... issue fields (summary, status, ...) ... } # executed; not blocked
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site freeStep 3 - integrity bypass: tools/call dispatches the write tool jira_create_issue:
req → tools/call jira_create_issue
{ "project_key": "SEC", "summary": "[PoC] ENABLED_TOOLS bypass", "issue_type": "Task" }
← { ... "key": "SEC-<n>" ... } # issue created despite ENABLED_TOOLS=jira_search
Step 1 proves the filter exists and is enforced at list time, so Steps 2–3 are a genuine authorization bypass, not an open/unconfigured endpoint. The same result holds with TOOLSETS=jira_read configured: write tools are absent from tools/list yet execute via tools/call.
Local reproduction
Extract enabled_tools_bypass_tool_authorization.zip:
# Fill Atlassian credentials in docker-compose.yml (ENABLED_TOOLS=jira_search is preset);
# ensure issue SEC-1 exists, or update the project/issue key in poc.sh
docker compose up -d # mcp-atlassian, streamable-http, 0.0.0.0, ENABLED_TOOLS=jira_search
./poc.sh # exits 0 on success
docker compose down -v
Requires Docker, curl, jq, and an Atlassian Cloud site with a Jira project (free tier works). The script runs the three steps above: it confirms tools/list returns only jira_search, then dispatches the excluded jira_get_issue (read) and jira_create_issue (write) via tools/call. The test issue it creates is deleted automatically on exit.
Discovered by Francisco Rosales of Manifold Security