Summary
MCP Atlassian contains a time-of-check-to-time-of-use flaw in its SSRF protection, allowing DNS results to change between validation and connection. An unauthenticated caller may exploit this behavior to reach internal services or cloud metadata endpoints when the server fetches attacker-influenced URLs.
Affected context
The issue occurs in MCP Atlassian deployments that validate user-influenced URLs by resolving their hostnames before making outbound HTTP requests. It becomes risky when the validation resolver and the Requests or urllib3 connection process perform separate DNS resolutions, allowing a short-lived public DNS response to be replaced with a private address before connection.
Exploit preconditions
- Attack surface: URL-fetching functionality exposed through the MCP server
- Required access: The described issue may be reachable without authentication when an attacker can provide or influence a destination URL
- Trigger point: SSRF validation followed by an outbound Requests or urllib3 connection
- Why exploitation is possible: DNS resolution is performed during validation and again during connection, creating a race window in which the destination address can change
Why this happens
The underlying bug is a time-of-check-to-time-of-use condition mapped to CWE-367. The application checks that a hostname resolves to a permitted public address, but later relies on a separate DNS resolution when opening the connection. Because the checked value is not guaranteed to be the value used, an attacker-controlled DNS response can redirect the request to a private or otherwise restricted address, producing an SSRF condition associated with CWE-918.
Potential impact
- An attacker may access internal HTTP services that are not externally exposed
- Cloud or platform metadata credentials could be disclosed
- Internal network information could be enumerated
- Requests could reach administrative interfaces or sensitive application endpoints
- Downstream systems could be affected if the server sends state-changing requests
General mitigation guidance
Mitigation typically focuses on making destination validation and connection
establishment use the same trusted address and policy decision.
Common defensive patterns include:
- Resolve the destination once and connect using the validated address rather than resolving it again
- Apply private, loopback, link-local, and metadata-network restrictions to the final connected address
- Revalidate connection targets after redirects and across address-family changes
- Prefer outbound egress allowlists and narrowly scoped network permissions
- Reduce input trust by constraining URL schemes, ports, hosts, and redirect behavior
- Run the MCP server with least-privilege network access and minimal credentials
- Avoid exposing URL-fetching capabilities to unauthenticated callers unless required
How teams detect issues like this
Organizations can look for this weakness through:
- Static analysis that identifies hostname validation followed by a separate HTTP client request
- Code review checks for calls such as
socket.getaddrinfobefore Requests or urllib3 connections - Tests that use controlled DNS responses which change between validation and connection
- Monitoring for outbound requests to loopback, link-local, private, and metadata address ranges
- Egress policy alerts for unexpected internal destinations, redirects, or unusual DNS behavior
- Automated security review tools that flag SSRF protections with inconsistent DNS resolution
