Summary
MCP Atlassian sessions used by Jira and Confluence fetchers may follow redirects to internal addresses without rechecking the destination. If a configured Atlassian instance is attacker-controlled or compromised, this behavior could expose internal services and networks to server-side request forgery.
Affected context
The issue can occur in MCP Atlassian deployments that create JiraFetcher or ConfluenceFetcher sessions through the basic-auth or OAuth personal access token authentication paths. In affected configurations, the SSRF protection hook is not attached to those sessions, allowing redirects returned by the configured Atlassian instance to bypass destination validation.
Exploit preconditions
- Attack surface: Outbound HTTP requests made by MCP Atlassian fetcher sessions
- Required access: Control of, or influence over, a configured Atlassian instance or its responses
- Trigger point: A fetch operation that receives an HTTP redirect
- Why exploitation is possible: The affected authentication branches can create sessions without the SSRF-safe redirect validation hook, so a redirect destination may not be revalidated before the request continues
Why this happens
The underlying bug is an incomplete security-control integration: SSRF protection is applied inconsistently across session-construction branches. When redirect handling does not validate the final destination against an approved network policy, a server-side HTTP client may be induced to access internal or otherwise restricted addresses. This behavior maps to CWE-918: Server-Side Request Forgery.
Potential impact
- An attacker could cause requests to internal services
- Cloud or container metadata endpoints may be exposed
- Internal APIs could receive unauthorized requests
- Network topology or service information may be disclosed
- Requests may be issued using the server's network position or credentials
General mitigation guidance
Mitigation generally focuses on applying SSRF protections consistently to every HTTP session and authentication path.
Common defensive patterns include:
- Validate both initial URLs and every redirect destination against an explicit allowlist
- Disable automatic redirects where following them is not required
- Reject loopback, link-local, private, reserved, and metadata-service address ranges
- Resolve hostnames and recheck the resulting addresses at connection time
- Use tightly scoped egress controls and network segmentation
- Avoid placing sensitive credentials in requests to untrusted destinations
- Run fetcher processes with least privilege and minimal network access
How teams detect issues like this
Organizations can look for SSRF risks through:
- Static analysis of HTTP client construction and redirect configuration
- Code review checks ensuring security hooks are attached on every authentication and session path
- Tests using redirects to loopback, private, link-local, and metadata-address ranges
- Egress monitoring for unexpected connections from MCP services to internal address spaces
- Policy enforcement requiring destination allowlists and redirect revalidation
- Automated code review tools that flag unrestricted outbound requests or automatic redirects
