CVE-2026-77242: MCP Atlassian SSRF Vulnerability

CVE-2026-77242 Overview

CVE-2026-77242 is a Server-Side Request Forgery (SSRF) vulnerability in MCP Atlassian, a Model Context Protocol (MCP) server for Atlassian Confluence and Jira. Versions prior to 0.22.0 contain a time-of-check to time-of-use (TOCTOU) flaw [CWE-367] in the validate_url_for_ssrf control. The validation logic resolves the hostname once, while the underlying Requests and urllib3 libraries resolve it again during connection. An unauthenticated attacker can exploit this window using DNS rebinding to reach internal services or cloud metadata endpoints. The issue is fixed in version 0.22.0.

Critical Impact
The flaw bypasses the previous CVE-2026-27826 remediation and preserves unauthenticated access to internal or metadata endpoints from the MCP server host.

Affected Products

MCP Atlassian versions prior to 0.22.0
Deployments integrating MCP Atlassian with Confluence and Jira backends
Any Model Context Protocol client relying on MCP Atlassian for URL fetching

Discovery Timeline

2026-09-22 - CVE-2026-77242 published to NVD
2026-09-23 - Last updated in NVD database

Technical Details for CVE-2026-77242

Vulnerability Analysis

The vulnerability sits in the validate_url_for_ssrf function, which enforces SSRF protections by resolving the target hostname and rejecting private or metadata address ranges. The check calls _check_dns_resolution, which invokes socket.getaddrinfo to gather addresses at validation time. When the request proceeds through _make_ssrf_safe_hook, the Requests and urllib3 stack performs an independent DNS resolution during connection establishment. This second lookup can return a different address than the one previously validated. An attacker who controls a DNS server can serve a short-lived public record during validation and a private record during connection, defeating the allow-list check.

Root Cause

The root cause is a classic TOCTOU race between the SSRF validator and the HTTP client. The check-then-use pattern trusts that hostname-to-address mapping remains stable between two separate getaddrinfo calls. Low DNS TTLs and multi-record responses invalidate that assumption, so the enforcement boundary can be crossed without triggering the guard.

Attack Vector

An unauthenticated remote attacker submits a URL whose hostname points to a DNS record they control. The authoritative server returns a public IP for the first lookup, satisfying validate_url_for_ssrf. On the second lookup during connection, the server returns an internal address such as 169.254.169.254 or an RFC1918 host. MCP Atlassian then issues the HTTP request to the internal target, returning response data to the attacker. This exposes cloud metadata credentials, internal APIs, and intranet endpoints reachable from the MCP host.

text

// Security patch note from pyproject.toml
"security_regression: SP5 security regression test (xfail-strict until the Phase B root fix lands; see plan)",

Source: GitHub Commit b041733

Detection Methods for CVE-2026-77242

Indicators of Compromise

Outbound HTTP requests from the MCP Atlassian host to link-local addresses such as 169.254.169.254 or RFC1918 ranges.
DNS queries from the MCP host returning multiple A records with abnormally low TTL values.
MCP Atlassian log entries showing successful validate_url_for_ssrf results followed by connections to unexpected internal hosts.

Detection Strategies

Compare the resolved IP logged by _check_dns_resolution against the destination IP of the subsequent socket connection and alert on mismatches.
Instrument the Requests session with hooks that log the final connected address for every outbound HTTP call from MCP Atlassian.
Monitor for user-supplied URLs whose hostnames resolve to authoritative name servers returning frequently rotating IP sets.

Monitoring Recommendations

Alert on any egress from MCP Atlassian workloads to cloud instance metadata endpoints or private CIDR ranges.
Track version banners of deployed MCP Atlassian instances and flag anything below 0.22.0.
Correlate DNS resolver logs with the MCP process to surface DNS pinning anomalies and repeated re-resolution patterns.

How to Mitigate CVE-2026-77242

Immediate Actions Required

Upgrade MCP Atlassian to version 0.22.0 or later, which addresses the SSRF DNS rebinding bypass.
Restrict egress from the MCP Atlassian host with an allow-list of required Atlassian endpoints only.
Block access to cloud instance metadata services from the MCP host using IMDSv2 enforcement or network-level deny rules.

Patch Information

The fix is delivered in the GitHub Release v0.22.0 and merged via Pull Request #1448. Technical details are documented in GHSA-72fm-whvq-jghf and the code change is available in commit b041733. The patch pins the validated IP address to the connection to eliminate the TOCTOU window.

Workarounds

Front MCP Atlassian with an authenticated HTTP egress proxy that enforces destination allow-listing independent of DNS.
Deploy the MCP host in a network segment that has no route to internal services or cloud metadata endpoints.
Disable or restrict user-supplied URL processing features until the upgrade to 0.22.0 is completed.

bash

# Example egress restriction using iptables to block cloud metadata access
iptables -A OUTPUT -d 169.254.169.254 -j DROP
iptables -A OUTPUT -d 10.0.0.0/8 -j DROP
iptables -A OUTPUT -d 172.16.0.0/12 -j DROP
iptables -A OUTPUT -d 192.168.0.0/16 -j DROP