GHSA-3r68-hf9h-887v: High severity pip/mcp-atlassian vulnerability

Summary

ENABLEDTOOLS 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.

READONLYMODE is not affected: it has dual enforcement at list time (listtoolsmcp) and call time @checkwriteaccess decorator. The developers applied the correct pattern to READONLYMODE but not to ENABLEDTOOLS or toolsets - confirming this is an implementation oversight.

Impact

Any user with access to the MCP server's HTTP endpoint can invoke any of the 73 registered tools regardless of ENABLEDTOOLS or TOOLSETS configuration - including write and delete operations on Jira issues, Confluence pages, etc. Operators deploying mcp-atlassian via Streamable HTTP rely on ENABLEDTOOLS 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.

Details In src/mcpatlassian/servers/main.py, AtlassianMCP overrides listtoolsmcp and applies the TOOLSETS and ENABLEDTOOLS filters before returning the tool list to clients. The calltoolmcp handler is not overridden. FastMCP's default calltoolmcp resolves the tool from the local tool manager / mounted servers, the full unfiltered inventory, so the filters never apply at call time.

Proof of Concept

All calls are issued against the HTTP transport, with ENABLEDTOOLS=jirasearch configured - only jirasearch should be reachable.

Step 1 - negative control: tools/list correctly filters by ENABLEDTOOLS: req → tools/list ← { "tools": [ { "name": "jirasearch" } ] } # only 1 tool; jiragetissue / jiracreateissue absent

Step 2 - confidentiality bypass: tools/call dispatches jiragetissue despite its exclusion from the list: req → tools/call jiragetissue { "issuekey": "SEC-1" } ← { ... issue fields (summary, status, ...) ... } # executed; not blocked

Step 3 - integrity bypass: tools/call dispatches the write tool jiracreateissue: req → tools/call jiracreateissue { "projectkey": "SEC", "summary": "[PoC] ENABLEDTOOLS bypass", "issuetype": "Task" } ← { ... "key": "SEC-<n>" ... } # issue created despite ENABLEDTOOLS=jirasearch

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=jiraread configured: write tools are absent from tools/list yet execute via tools/call.

Local reproduction

Extract enabledtoolsbypasstoolauthorization.zip: Fill Atlassian credentials in docker-compose.yml (ENABLEDTOOLS=jirasearch 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, ENABLEDTOOLS=jirasearch ./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 jirasearch, then dispatches the excluded jiragetissue (read) and jiracreateissue (write) via tools/call. The test issue it creates is deleted automatically on exit.

Credit Discovered by Francisco Rosales of Manifold Security