CVE-2026-77244

**Description** mcp-atlassian deploys in two common patterns: Pattern A (single-user, server-side credentials): operator sets JIRA_USERNAME + JIRA_API_TOKEN (or CONFLUENCE_USERNAME + CONFLUENCE_API_TOKEN) in environment variables. Server uses these to call Jira/Confluence. This is the documented quickstart pattern. Pattern B (multi-user, OAuth or per-request PAT): operator sets up OAuth proxy or accepts per-user tokens via Authorization or service headers. The authentication mechanism in HTTP transport has two issues that combine to permit unauthenticated access to Pattern A deployments: 1. AtlassianOpaqueTokenVerifier.verify_token() at `src/mcp_atlassian/utils/token_verifier.py` accepts any non-empty string as a valid token: async def verify_token(self, token: str) -> AccessToken | None: if not token: return None scopes = self.required_scopes or [] return AccessToken( token=token, client_id="atlassian", scopes=scopes, expires_at=int(time.time()) + 86400 * 30, ) The docstring documents this: "we accept non-empty tokens and attach the required scopes." 2. The default deployment does NOT enable the OAuth proxy auth provider (OAUTH_PROXY_ENABLE_ENV defaults to false; main.py:726). When `_build_auth_provider()` returns None, FastMCP HTTP transport accepts requests with no authentication challenge. 3. `UserTokenMiddleware._parse_auth_header` (main.py:601-664) extracts tokens from Authorization headers and stores them in scope state. If NO Authorization header is present (main.py:584-595), the middleware does not reject the request — it simply does not populate `user_atlassian_token`. 4. JiraFetcher / ConfluenceFetcher fall back to `JiraConfig.from_env()` when no user-supplied token is in scope state. `from_env()` reads `JIRA_API_TOKEN` and `JIRA_USERNAME` from environment and use