What happened
Researchers sent MCP tools/call requests that executed hidden or unauthenticated tools, read a server-local path for upload, and returned Jira content from a project excluded by the operator's filter.
2026-05-18
HighPrimarymcp-atlassian Flaws Could Bypass Authentication and Tool Restrictions to Read Local Files and Restricted Atlassian Data
Four September 2026 advisories show mcp-atlassian authentication, tool filtering, path validation, and project filters failing during demonstrated MCP tool calls.
mcp-atlassianTool execution / MCPControlled vulnerability demonstrations of MCP authentication and tool-authorization bypassmcp-atlassian versions before 0.22.0 using HTTP transport or relying on tool, Jira-project, or Confluence-space filters
Why it matters
In affected deployments, a reachable client could act with the operator's Jira or Confluence privileges, read local files including environment secrets, perform write or delete operations, and access data outside configured project or space boundaries.
Missing authorization check
A call-time decision binding the authenticated caller, exact MCP tool, local-file path or Atlassian resource scope, and operator-granted authority.
Would PP block it?
The enforcement point must sit before each Atlassian API call or attachment upload and validate a receipt scoped to the caller, tool, target project or space, and file path. That can stop an attacker from converting a reachable MCP endpoint into operator-authorized execution. It cannot protect deployments that bypass the gate or prevent the initial network access.
Incident analysis
Timeline and technical read
Timeline
2026-05-18
A researcher reproduced the Jira project-filter bypass against a real Atlassian Cloud test workspace with allowed and forbidden projects.
2026-09-22
GitHub published coordinated advisories for authentication bypass, disabled-tool invocation, local-file exfiltration, and Jira or Confluence filter bypass.
2026-09-22
The advisories identified mcp-atlassian 0.22.0 as the first patched release.
Technical breakdown
- HTTP requests without valid client authentication could reach tool handlers, which then fell back to the operator's environment-provided Atlassian credentials.
- ENABLED_TOOLS and TOOLSETS filtered tools/list but not tools/call, so a client that knew a tool name could invoke it from the full registry.
- Attachment-upload tools passed caller-supplied file_path values to local file reads without an allowlist or safe-path validation.
- Jira and Confluence query paths used incomplete substring checks or omitted project-filter enforcement, allowing demonstrated access to excluded resources.
Authorization boundary
Where the authorization boundary should have been
This incident is categorized as Tool execution / MCP. The relevant Permission Protocol gate is Tool-Call Gate. The read is conditional: the block only applies where the real action boundary is routed through a gate.
- If enforced at
- External MCP tool proxy and the Atlassian API or attachment-upload boundary
- Still needs
- mcp-atlassian must still authenticate HTTP clients, validate local paths, enforce ENABLED_TOOLS and TOOLSETS during tools/call, and apply Jira and Confluence filters to every query path.
- Receipt required for
- Each Jira or Confluence read, write, delete, attachment upload, and request targeting a project or space outside the caller's approved scope
A Tool-Call Gate integrated outside the affected server could reject consequential reads, uploads, and mutations that lack a separately authenticated receipt, but Permission Protocol does not patch the server's authentication, path-validation, or filter defects.
Related incidents and controls
Start small
Put the relevant gate at this action boundary.
This incident maps to Tool-Call Gate. Start with the boundary that controls the actual action, then require a signed receipt before execution.