Summary
MCP Atlassian may allow unauthenticated network callers to read files accessible to the MCP process when the streamable HTTP transport falls back to operator credentials and upload paths are not restricted. An attacker could upload those files to an attacker-selected Jira issue or Confluence page and retrieve their contents.
Affected context
The issue can arise in MCP Atlassian deployments using the streamable HTTP transport before the security fixes introduced in version 0.22.0. Risk is increased when requests lack an authenticated user identity, middleware falls back to operator credentials, and the upload_attachment operation accepts a broadly controlled file_path that can reach files available to the MCP process.
Exploit preconditions
- Attack surface: Streamable HTTP MCP endpoint exposed to a network caller
- Required access: No authenticated user identity may be required when the transport falls back to operator credentials
- Trigger point: Invocation of the attachment-upload operation with a caller-controlled file path
- Required file access: The targeted file must be readable by the MCP process
- Why exploitation is possible: Authentication and authorization controls do not sufficiently bind the request to a user, while file-path handling permits access beyond an intended upload directory
- Exfiltration path: The process can upload the readable content to an attacker-selected Jira issue or Confluence page, where it may be retrieved
Why this happens
The vulnerability combines missing authentication with insufficient restriction of filesystem paths. The streamable HTTP transport and UserTokenMiddleware can process requests without a user identity and use operator credentials, while upload_attachment passes an unrestricted file_path through its file-fetching path. This behavior maps primarily to CWE-22: Improper Limitation of a Pathname to a Restricted Directory, with CWE-306: Missing Authentication for Critical Function also applying because sensitive functionality may be reachable without an authenticated caller.
Potential impact
- Sensitive local files may be disclosed
- Credentials, configuration data, source code, or tokens may be exfiltrated
- Files may be uploaded to unauthorized Jira issues or Confluence pages
- Confidentiality of connected Atlassian content may be reduced
- The MCP process's operator privileges may be misused
General mitigation guidance
Mitigation typically focuses on enforcing user identity before sensitive MCP operations and reducing filesystem trust.
Common defensive patterns include:
- Require explicit authentication and authorization for every streamable HTTP request
- Do not substitute operator credentials for an absent user identity
- Restrict attachment reads to a dedicated, tightly controlled directory
- Canonicalize paths and enforce containment within an approved base directory
- Prefer server-selected file handles or controlled upload objects over arbitrary path strings
- Apply least-privilege filesystem permissions to the MCP process
- Limit which Jira issues and Confluence pages may receive uploaded content
- Avoid exposing sensitive files to the process runtime
These controls reduce the likelihood and impact of unauthorized file access even if an endpoint is exposed.
How teams detect issues like this
Organizations can look for this class of issue through:
- Static analysis rules identifying file operations that consume request-controlled path values
- Code review checks for missing canonicalization, directory-boundary validation, or allowlists
- Review of middleware that accepts requests without a user identity or falls back to service credentials
- API policy tests confirming that unauthenticated requests cannot invoke attachment or content-management operations
- Runtime monitoring for unexpected attachment uploads, unusual destination pages, and access to sensitive filesystem locations
- Automated security review tools that flag missing authentication and unrestricted file-path handling
