Authentication Bypass in mcp-atlassian HTTP Transport Lets Unauthenticated Requests Use Operator's Jira/Confluence Credentials

A newly disclosed vulnerability in mcp-atlassian, an open-source Model Context Protocol server for Jira and Confluence, allows unauthenticated attackers with network access to the HTTP transport to silently use the operator's own Atlassian API credentials.

What Happened

According to a GitHub Security Advisory (GHSA-wrhw-j3f9-8vc6), the flaw is a composition of several issues in the current main branch:

• AtlassianOpaqueTokenVerifier.verify_token() accepts any non-empty string as a valid token by design — the code's own docstring states "we accept non-empty tokens."
• The OAuth proxy auth provider is disabled by default (OAUTH_PROXY_ENABLE_ENV defaults to false), so the HTTP transport issues no authentication challenge at all.
• Requests with no Authorization header are not rejected by the middleware — they simply proceed without a user-supplied token.
• When no user token is present, the Jira/Confluence fetchers fall back to the server's own environment-variable credentials (JIRA_API_TOKEN, JIRA_USERNAME, etc.) — the documented single-user quickstart configuration.

The advisory reports a CVSS score of 10.0 and a public proof-of-concept, and notes this is the same vulnerability class as CVE-2026-27825, a prior unauthenticated RCE/SSRF finding in the same Atlassian MCP code surface — this report addresses the auth-verifier and middleware behavior rather than that earlier code path.

Why It Matters

Any deployment following the documented single-credential quickstart pattern — Docker Compose with an exposed port, a load balancer that delegates auth to the app, an internal network reachable by any employee, a misconfigured Kubernetes ingress, or a dev tunnel (ngrok/Cloudflare Tunnel) left open — is affected. An attacker who reaches the endpoint, with no credentials and either no Authorization header or a garbage bearer token, gets the operator's full Jira and Confluence access: read/write on issues, comments, attachments, pages, and restricted spaces, all logged under the operator's identity in Atlassian's audit trail. That access can also be used to plant persistence (webhooks, automation rules, integrations) and to pivot toward credentials or infrastructure detail often stored in attachments or pages.

What Defenders Should Do Now

• Inventory any mcp-atlassian deployments, particularly HTTP-transport instances reachable from more than localhost — check Docker port mappings, load balancer/ingress configs, and any dev tunnels left running.
• Until a patched release is available, do not expose the HTTP transport beyond 127.0.0.1/trusted hosts; front it with your own authenticating reverse proxy if remote access is required.
• Review Atlassian audit logs for API activity attributed to the operator's service account that doesn't correlate with expected automation — unexplained issue edits, comments, webhook/automation-rule creation, or bulk access to Confluence spaces.
• Where feasible, rotate the Atlassian API token used by the server and scope it as narrowly as possible.
• Track upstream for a fix that requires explicit single-user-mode acknowledgment, binds HTTP transport to localhost by default, or replaces the opaque verifier with one that actually validates tokens (e.g., via a token-info/whoami call).

Developing Intel

This is a same-day disclosure with a public proof-of-concept and no confirmed patch status noted in the advisory at time of writing; details may evolve. See the original GitHub Security Advisory for the full technical writeup: GHSA-wrhw-j3f9-8vc6.