The report
An MCP client configured to see one Jira project could still reach another through certain mcp-atlassian tools. A second flaw let crafted JQL or CQL change the meaning of a project filter. Both were addressed in the project's 0.24.1 release on November 8, alongside fixes for other file and network boundaries. The common problem was not a malfunctioning language model: the server applied restrictions on some paths but not on all of the operations available to the agent.
Two different ways a resource filter failed
The first advisory on unfiltered tools describes an allowlist covering selected Jira and Confluence reads while other read or write tools skipped the check. The second query-expression advisory concerns the expression itself: malformed grouping and OR precedence could escape a JQL/CQL restriction even on a route that applied filtering. The fix includes stronger expression handling and validation of returned resources.
These defects have the same consequence only when the service credential can already reach the excluded project or space. They did not demonstrate that an agent obtained rights the underlying Atlassian principal lacked. In a deployment using one broad service credential for several narrowly scoped agents, however, MCP-level allowlists become a meaningful isolation boundary.
A tool name did not describe its full effect
Other advisories in the release describe materially different entry points:
| Disclosed operation | Conditional effect | Boundary at issue |
|---|---|---|
| Confluence attachment upload | Read service-accessible files when the process working directory was too broad | Filesystem read and upload scope |
| Confluence download | Overwrite an importable local module path in a controlled test | Download destination |
| Jira link removal | Path traversal could turn a link deletion into an issue deletion | REST method and resource identity |
| Jira Service Management comment | An internal-only note could instead become customer-visible | Recipient visibility |
| HTTP/SSE request admission | Mounted path or method variants missed an exact-match authentication middleware | Transport admission |
The comment-visibility failure was addressed in 0.24.0; 0.24.1 contains the broader hardening. The disclosures do not establish actual victim notifications, issue deletions or code execution in production.
Outbound request defects also depended on configuration. A caller-supplied service URL, proxy-side hostname re-resolution, NAT64 address translation, Jira Forms alternative HTTP clients and download URLs returned in metadata each crossed a different origin or address check.
What the repair must establish
The upstream advisory and the 0.24.1 release record describe patched code, not an independent assurance of every deployment's configuration. Operators need to verify which service identity the MCP server uses, whether each exposed tool enforces that identity's narrower scope, and whether outbound URLs and file paths are checked where execution occurs. A tool declared safe in an agent interface does not replace a check at the final Jira, Confluence, filesystem or network operation.