Crazydude123

**Name of the Vulnerable Software and Affected Versions** mcp-atlassian versions prior to 0.22.0 **Description** The HTTP transport in mcp-atlassian accepts requests without a verified user identity. When no valid user token is provided, the system falls back to using the operator's globally configured Jira or Confluence credentials stored in environment variables. This allows any network client that can reach the MCP endpoint to perform read and write operations on the Atlassian instance as the operator. The issue stems from a combination of factors: the `AtlassianOpaqueTokenVerifier.verify token()` function accepts any non-empty string as a valid token, and the `UserTokenMiddleware. parse auth header` does not reject requests missing an Authorization header. Consequently, requests sent without a header or with an arbitrary Bearer token are processed using the server's administrative credentials. Technical details include the following affected components: - **API Endpoints:** `/mcp` - **Vulnerable Parameters or Variables:** `JIRA USERNAME`, `JIRA API TOKEN`, `CONFLUENCE USERNAME`, and `CONFLUENCE API TOKEN` - **Function Names:** `verify token()`, ` parse auth header()`, and ` get fetcher()` **Recommendations** Update mcp-atlassian to version 0.22.0. As a temporary mitigation, restrict network access to the MCP HTTP endpoint to trusted sources only or bind the transport to 127.0.0.1 to prevent external access.