Summary
MCP Atlassian may allow unauthenticated HTTP MCP requests to reach Jira and Confluence tool handlers, which can then use globally configured operator credentials. A network caller could perform actions with the operator account's permissions when the deployment lacks an independent authentication boundary.
Affected context
The issue can occur in MCP Atlassian deployments that expose the streamable HTTP MCP endpoint without enforcing per-user identity before requests reach tool handlers. The risk is higher when global Jira or Confluence credentials are configured and no separate network, gateway, or application authentication layer protects the endpoint.
Exploit preconditions
- Attack surface: The streamable HTTP MCP endpoint
- Required access: Network reachability to the endpoint; a per-user authenticated session may not be required
- Trigger point: An HTTP MCP request reaching tool handlers through the request-processing middleware
- Why exploitation is possible: Requests without established user identity can be processed using globally configured Jira or Confluence credentials
Why this happens
The underlying flaw is an authentication enforcement gap mapped to CWE-306: Missing Authentication for Critical Function. The HTTP request path permits unauthenticated input to continue through components such as UserTokenMiddleware and _get_fetcher until tool execution, where globally configured credentials may be selected. This creates a mismatch between endpoint access and the identity required to authorize downstream Jira or Confluence operations.
Potential impact
- An attacker may read Jira or Confluence data available to the operator account
- An attacker could create, modify, or delete content depending on configured permissions
- Unauthorized actions can cause data integrity or workflow disruption
- Exposed credentials or privileged integrations may increase the scope of compromise
- The MCP service could become a pathway for lateral activity within connected systems
General mitigation guidance
Mitigation generally focuses on enforcing authentication and authorization before any MCP request can reach privileged tool handlers.
Common defensive patterns include:
- Require a strongly authenticated user or service identity at the MCP endpoint
- Place the service behind an independently enforced authentication gateway where appropriate
- Reject requests that lack verified identity rather than falling back to global credentials
- Bind downstream Jira and Confluence actions to the authenticated caller's authorized scope
- Use narrowly scoped service credentials and least-privilege permissions
- Treat global credentials as a controlled service-account mechanism rather than an implicit identity for unauthenticated callers
- Apply network restrictions, logging, and approval controls to sensitive tools
How teams detect issues like this
Organizations can look for this issue through:
- Static analysis and code review checks confirming authentication occurs before tool dispatch
- Tests that send requests without identity and verify that privileged handlers are not reached
- Review of middleware branches that permit anonymous or missing-token requests
- Policy checks requiring authentication at the application, gateway, or network boundary
- Runtime monitoring for Jira or Confluence actions initiated by anonymous, unexpected, or shared service identities
- Audit correlation between MCP requests and downstream Atlassian API activity
