Authentication Bypass in mcp-atlassian HTTP Transport

The mcp-atlassian Python package is vulnerable to a critical authentication bypass (CVE-2026-77244) due to improper validation in the AtlassianOpaqueTokenVerifier utility. The implementation of verify_token() explicitly accepts any non-empty string as a valid credential. Furthermore, the mcp-atlassian HTTP transport defaults to disabled OAuth proxy authentication and fails to reject requests lacking an Authorization header.

When deployed in the standard pattern (storing JIRA_API_TOKEN or CONFLUENCE_API_TOKEN in environment variables), the MCP server fails to challenge unauthenticated requests. Instead, it proceeds to invoke Jira/Confluence tool handlers using the server-side environment variables. An attacker with network reach to the MCP server can send arbitrary requests - or no credentials at all - to perform unauthorized operations on the operator's Atlassian instance. This vulnerability is significant because it grants attackers the full API privileges of the server operator, including read and write access to all accessible Jira issues and Confluence pages.

Attack Chain

1. Attacker performs network discovery to identify an mcp-atlassian HTTP transport instance reachable on the network (e.g., via default Docker port mappings or misconfigured cloud load balancers).
2. Attacker crafts a JSON-RPC request targeting the /mcp endpoint with the desired tool execution parameters (e.g., jira_get_issue or jira_add_comment).
3. The request is transmitted to the server without an Authorization header, or with a dummy "Bearer" token.
4. UserTokenMiddleware._parse_auth_header processes the request; seeing no valid client token, it passes the request context to the internal handlers without rejection.
5. The AtlassianOpaqueTokenVerifier receives the request; if a dummy token is provided, it is accepted by the logic that validates only that the string is non-empty.
6. The JiraFetcher or ConfluenceFetcher detects the absence of a user-supplied token in the scope state and initiates JiraConfig.from_env().
7. The server retrieves the operator's JIRA_API_TOKEN or CONFLUENCE_API_TOKEN from the process environment variables.
8. The tool execution is performed against the Atlassian cloud backend using the operator's identity, resulting in data exfiltration, unauthorized modification, or persistent access creation.

Impact

Successful exploitation grants an attacker full read and write access to the operator's Jira and Confluence instances. Because all API calls are made using the operator's legitimate credentials, the attacker's actions appear as authenticated operator activity in Atlassian audit logs, facilitating anti-forensics and shifting blame to the victim. Furthermore, attackers can leverage the MCP server to pivot, exfiltrate sensitive data stored in attachments or documentation, and create persistent backdoors via Jira webhooks or automation rules.

Recommendation

1. Upgrade the mcp-atlassian package to version 0.22.0 or later immediately to patch CVE-2026-77244.
2. For deployments not using OAuth proxy, implement strict network-level access control (e.g., firewall rules or mTLS) to restrict access to the MCP server to authorized users only.
3. If version 0.22.0 is not immediately available, disable public exposure of the HTTP transport by binding the service to 127.0.0.1 and utilizing a secure reverse proxy (e.g., Nginx or Traefik) that enforces authentication before forwarding traffic to the MCP server.
4. Audit Jira and Confluence audit logs for anomalous tool execution patterns or unauthorized modification of issues and automation rules originating from the host IP of the MCP server.