Insights

MCP HTTP Fallback Auth Keeps Shipping as Critical

Anomity Research Anomity Research · Sep 28, 2026 · 3 min read

TL;DR

A repeating Critical MCP failure mode: HTTP / streamable-http servers accept requests with missing or unverified auth, then run tools using globally configured env credentials.
Fresh examples: mcp-atlassian CVE-2026-77254 (CVSS 9.1) and sibling CVE-2026-77244 (CVSS 10.0) - unauthenticated or garbage-token HTTP MCP falling through to Jira/Confluence service accounts; fixed in 0.22.0.
The class needs three ingredients: a network-reachable MCP HTTP endpoint, middleware that does not reject missing auth, and a shared credential the tool layer will use anyway.
Related shapes on this blog include unauthenticated MCP takeovers and gateway OAuth passthrough bugs - different CVEs, same broker trust failure.
Defenders should inventory HTTP MCP listeners, forbid "fallback means shared token," and enforce allow/deny/log at the agent hook while patches roll out.

Critical MCP advisories keep rhyming. The rhyme is not exotic crypto - it is HTTP MCP + global env credentials + middleware that does not reject missing auth. When those three line up, an unauthenticated network client inherits a service account. mcp-atlassian CVE-2026-77254 and sibling CVE-2026-77244 are the cleanest recent specimens.

The three ingredients

Reachable HTTP MCP - streamable-http or SSE bound beyond a true localhost-only posture (often default 0.0.0.0, Docker port publish, or a reverse proxy that trusts the app to authenticate).
Non-rejecting auth middleware - missing Authorization logs a warning and continues; or a verifier accepts any non-empty token; or OAuth proxy auth is off by default.
Global credential fallback - tool handlers construct Jira/Confluence/Git/cloud clients from env or lifespan config when no per-user token exists.

Each ingredient alone can be defended ("we only use STDIO," "we terminate auth at the gateway," "we never set a shared token"). Together they become a Critical. mcp-atlassian's own HTTP docs have described fallback authentication when requests lack user-specific credentials - which is convenient for single-user demos and catastrophic for multi-tenant or network-exposed brokers.

What 77254 / 77244 add to the timeline

On mcp-atlassian below 0.22.0, CVE-2026-77254 (CVSS 9.1) lets HTTP MCP POSTs with no Authorization header reach tools that then use globally configured Atlassian credentials. CVE-2026-77244 (CVSS 10.0) accepts any non-empty token in AtlassianOpaqueTokenVerifier, then hits the same fallback. CVE records published 22 September 2026; fix in 0.22.0. Full patch and fleet checklist: mcp-atlassian HTTP auth bypass advisory.

These are not MCPwnfluence CVE-2026-27825 (SSRF-to-RCE, fixed 0.17.0). That earlier chain abused download tools and path writes. Fallback auth abuses the identity broker role: the server already holds the API token and forgets to demand a caller. Same package, different root cause - and a reminder that "we patched Atlassian MCP once" is not a strategy.

Adjacent failures on this blog

Unauthenticated or weakly authenticated MCP HTTP keepers include Nginx UI MCP takeover CVE-2026-33032, WeKnora unauthenticated MCP RCE CVE-2026-30861, Windows MCP PowerShell RCE, MCP Inspector proxy RCE CVE-2025-49596, and MCP-connect bridge unauthenticated RCE. Gateway-side cousins include LiteLLM MCP OAuth passthrough CVE-2026-59822 and the broader AI gateway OAuth passthrough pattern. Grafana MCP session spoofing shows the broker theme when a session ID is treated as auth.

DNS-rebinding and local HTTP exposure are a neighboring class - bind address and browser-origin tricks rather than env-credential fallback. Prefer inventorying both: who listens on HTTP MCP, and what identity that listener will assume if auth is empty. For credential sprawl on MCP hosts, see MCP server secrets exposure and OAuth for MCP servers explained.

Controls that survive the next CVE

Inventory HTTP MCP - package, version, bind address, auth mode, and which agent launches it.
Make fallback opt-in and loud - single-user mode should be an explicit flag, not silent env reuse on a public bind.
Verify tokens for real - opaque accept-anything verifiers are not authentication; call the IdP or Atlassian whoami equivalent.
Default bind to localhost for any deployment that intentionally uses shared env credentials.
Govern tools at the hook - allow/deny/log before Jira/Confluence/cloud mutating calls execute, especially while CVEs are still publishing against popular MCP packages.
Assume Atlassian/cloud audit names the token owner - correlate with MCP/agent audit or you will blame the wrong principal.

How Anomity covers the class

Anomity's Endpoint Sensor inventories MCP servers among the eight AI artifact types on managed endpoints. Browser Sensor and cloud discovery (Google Workspace / GitHub OAuth grants) catch adjacent AI grant sprawl. On agents with hooks, runtime governance returns allow, deny, or log before tool calls run - so a fallback-auth bug is not your only control while 0.22.0 (or the next package's fix) rolls out.

Decisions and inventory changes land in a 90-day audit trail and can route to SIEM, Slack, email, or Jira. Secrets stay redacted on-endpoint. Anomity is SOC 2 Type II and complements Network, EDR, DLP, and GRC.

Fallback authentication will keep shipping as Critical until MCP HTTP stops treating "no user token" as "use the shared one." Patch mcp-atlassian, hunt the class across your fleet, and enforce unsafe tool calls before they run. Book a 30-minute demo.

Frequently asked questions

What is the MCP HTTP fallback-auth class?

It is the pattern where an MCP server exposes HTTP or streamable-http, fails to require a verified caller identity, and then executes tools with operator-configured global credentials from environment variables or lifespan config. Missing Authorization becomes "use the shared service account" instead of 401.

Which fresh CVEs illustrate it?

CVE-2026-77254 (CVSS 9.1, GHSA-vc8m-84rp-53hx) and CVE-2026-77244 (CVSS 10.0, GHSA-wrhw-j3f9-8vc6) in mcp-atlassian below 0.22.0. The first allows no Authorization header through to global Jira/Confluence credentials; the second accepts any non-empty token via AtlassianOpaqueTokenVerifier and hits the same fallback. See the dedicated advisory on this site for patch and fleet checks.

How is this different from SSRF-to-RCE in the same product?

MCPwnfluence CVE-2026-27825 was an unauthenticated SSRF plus path-traversal write chain fixed in 0.17.0. Fallback auth is an authentication-boundary bug: the server already has powerful Atlassian credentials and hands them to callers who never proved an identity. Same install base, different root cause.

Where else does the class show up?

Anywhere MCP HTTP is treated as a convenience transport: default-open bridges, inspector proxies, gateway OAuth passthrough that yields empty identities, and servers that bind 0.0.0.0 with docs that mention fallback authentication as a feature. The exact CVE changes; the three ingredients (reachability, non-rejecting middleware, shared credential) repeat.

What should teams do beyond patching one CVE?

Inventory every MCP HTTP listener and its auth mode; require explicit single-user acknowledgment or real OAuth/PAT verification before env credentials are usable; bind locally by default; and evaluate tool calls at the agent hook so a missed auth bug is not the only line of defense.

How does Anomity address this class?

Anomity inventories MCP servers on managed endpoints, including transport and configuration metadata, via the Endpoint Sensor. Runtime governance can deny sensitive tool calls at the agent hook while vulnerable builds remain. Audit decisions go to a 90-day trail and onward to SIEM, Slack, email, or Jira, with secrets redacted on-endpoint.