mcp-atlassian HTTP Auth Bypass Falls Back to Global Credentials - CVE-2026-77254
CVE-2026-77254 (CVSS 9.1, GHSA-vc8m-84rp-53hx) is a critical authentication failure in mcp-atlassian below 0.22.0: unauthenticated HTTP MCP requests are not rejected - they fall through to globally configured Jira and Confluence credentials. Sibling CVE-2026-77244 (CVSS 10.0, GHSA-wrhw-j3f9-8vc6) makes the same fallback reachable with any non-empty Bearer token. CVE records published 22 September 2026; fix in 0.22.0. This is not a rewrite of MCPwnfluence CVE-2026-27825.
What happened
mcp-atlassian is commonly deployed in two patterns: single-user with JIRA_* / CONFLUENCE_* env credentials, and multi-user with OAuth proxy or per-request tokens. On vulnerable builds, the HTTP middleware only rejected malformed or empty supplied credentials. If no Authorization header was present, the request continued. Downstream, _get_fetcher() treated that as a global fallback and built Jira/Confluence clients from lifespan/env config - so a caller with no identity still acted as the service account.
CVE-2026-77244 tightens the same story from the verifier side. AtlassianOpaqueTokenVerifier accepted any non-empty string, attached required scopes, and did not call Atlassian to validate the token. Combined with OAuth proxy auth being off by default, FastMCP HTTP accepted the request; tools then used env credentials. GitHub advisories describe both issues as fixed in 0.22.0, which also bundles a broader hardening pass across attachment paths, SSRF validation, filtering, and OAuth.
Default host binding for HTTP transports has historically been 0.0.0.0, and docs have shown remote streamable-http examples. That turns a credential-fallback bug into a network-reachable Atlassian broker - the same exposure class as other unauthenticated MCP HTTP takeovers such as Nginx UI MCP CVE-2026-33032 and Windows MCP unauthenticated PowerShell RCE.
Why this is an agentic-endpoint risk
An MCP server that holds a Jira/Confluence API token is an identity broker. Agents call it to read boards and wiki spaces; the broker signs Atlassian API calls. When HTTP MCP skips real auth and reuses a global token, every reachable client inherits that identity - including write tools when READ_ONLY_MODE is off. Atlassian audit logs still attribute actions to the operator token, which is exactly the confused-deputy shape security teams hate.
Developers install mcp-atlassian bottom-up to wire coding agents into project work. Copies land on laptops, containers, and lab tunnels that never entered a central registry - the AI agents as shadow IT dynamic. EDR sees a legitimate Python process; the network sees ordinary HTTPS to Atlassian; DLP sees nothing at rest. The control question is which endpoints run which version over which transport - and whether missing auth is treated as deny or as "use the shared token."
How Anomity surfaces and governs it
Upgrading to 0.22.0 patches the instances you can see. Anomity's job is to find the rest, govern dangerous tool calls at the hook, and keep the record.
First, inventory. The Endpoint Sensor inventories MCP servers among the eight AI artifact types, capturing package/version, transport, and the agent that launches them. Browser Sensor and cloud discovery (Google Workspace / GitHub OAuth grants) cover adjacent AI surfaces. Metadata only: secrets are redacted on-endpoint before anything leaves the machine.
Second, decide at the hook. On agents that expose a hook - for example Claude Code PreToolUse - runtime governance returns allow, deny, or log before the call runs. Jira/Confluence write tools against an unpatched or internet-exposed mcp-atlassian can be denied while the upgrade rolls out.
Third, keep the record. Every decision and every MCP inventory change lands in a queryable 90-day audit trail and can route to SIEM, Slack, email, or Jira. Anomity is SOC 2 Type II and complements Network, EDR, DLP, and GRC - it covers the artifact layer those tools were not built to inventory.
You can't govern what you can't see.The Anomity principle
What to check across your fleet
- Inventory every mcp-atlassian install and flag anything below 0.22.0 - especially HTTP / streamable-http transports.
- Treat any instance bound beyond localhost without a real auth provider (OAuth proxy or equivalent) as highest priority.
- Confirm whether global
JIRA_*/CONFLUENCE_*env credentials are present; that is the privilege an unauthenticated caller inherits on vulnerable builds. - Govern write-capable Atlassian tool calls at the agent hook with allow/deny/log until every instance is patched.
- Review Atlassian audit events attributed to the service account during the exposure window - the MCP caller identity will not appear there.
- For the broader "missing auth + global credentials" pattern across MCP HTTP servers, see MCP HTTP fallback authentication.
CVE-2026-77254 and CVE-2026-77244 are patchable in 0.22.0, but only on the mcp-atlassian instances you can actually find. Inventory the MCP layer, enforce unsafe tool calls before they run, and keep a queryable record. For protocol context see MCP security explained. To see Anomity inventory and govern Atlassian MCP across your fleet, book a 30-minute demo.
Frequently asked questions
What is CVE-2026-77254 in mcp-atlassian?
CVE-2026-77254 is a critical missing-authentication issue rated CVSS 9.1 and tracked as GHSA-vc8m-84rp-53hx. In mcp-atlassian versions below 0.22.0, when the server runs with HTTP transport and global Jira or Confluence credentials, POST requests to the MCP endpoint that omit an Authorization header are allowed through middleware and fall back to the server's globally configured service-account credentials. An unauthenticated network client that can reach the endpoint can invoke Atlassian tools as that account.
How is CVE-2026-77244 related?
CVE-2026-77244 (CVSS 10.0, GHSA-wrhw-j3f9-8vc6) is a sibling authentication bypass on the same HTTP transport. AtlassianOpaqueTokenVerifier accepted any non-empty token string as valid, and when no verified user token was present the fetcher layer still fell back to environment-configured Jira/Confluence credentials. Attackers could send no Authorization header or any garbage Bearer token and still operate as the operator's Atlassian identity. Both CVEs are fixed in 0.22.0.
Is this the same as CVE-2026-27825 (MCPwnfluence)?
No. CVE-2026-27825 was an unauthenticated SSRF-to-RCE chain via download tools and path traversal, fixed in mcp-atlassian 0.17.0. CVE-2026-77254 and CVE-2026-77244 are authentication-boundary failures on the HTTP transport and credential fallback path, fixed in 0.22.0. Same product family, different root causes and different patched versions.
Which versions are affected and what is the fix?
mcp-atlassian versions below 0.22.0 are affected. The coordinated fix ships in 0.22.0 (released 10 July 2026 with a large security hardening pass). CVE records for 77254 and 77244 were published 22 September 2026. Upgrade every HTTP-exposed instance to 0.22.0 or later, require real authentication for remote MCP, and avoid binding publicly without an auth provider.
What is the practical impact?
Impact tracks the globally configured Atlassian account: read and potentially write across Jira and Confluence issues, pages, comments, attachments, and automations the service account can reach. Atlassian-side audit trails name the operator's token identity, which can obscure the real caller. Typical exposure includes Docker port maps, reverse proxies that delegate auth to the app, internal network reach, and leftover tunnels.
How does Anomity help while you patch?
Anomity's Endpoint Sensor inventories MCP servers among the eight AI artifact types on managed endpoints, so mcp-atlassian instances, transports, and versions become a fleet query. On agents that expose a hook such as Claude Code PreToolUse, runtime governance returns allow, deny, or log before a tool call runs, so Atlassian write tools can be denied while upgrades finish. Decisions land in a 90-day audit trail and can route to SIEM, Slack, email, or Jira, with secrets redacted on-endpoint.
