PT-2026-105840 — Pypi Mcp-Attlasian

PT-2026-105840 · Pypi · Mcp-Attlasian

Publicado

2026-10-01

Atualizado

2026-10-01

CVSS v3.1

7.1

Alta

Vetor

AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N

Summary

make ssrf safe hook() blocks HTTP redirects to private/internal IPs by validating the Location header before the client follows a 3xx response. The problem is that this hook is only attached in one of three authentication branches — the header-PAT path. Basic auth and OAuth branches skip it entirely, so if the connected Atlassian server returns a redirect to something like http://169.254.169.254/, the requests session follows it without complaint.

This is an incomplete fix for GHSA-7r34-79r5-rcc9. The hook works fine when it's there — it just isn't there for most production auth configurations.

Details

In src/mcp atlassian/servers/dependencies.py, three branches construct a fetcher and call create and validate(). Only Branch 1 passes attach ssrf hook=True:

python

# Branch 1 (header PAT) — hook attached
return create and validate(request, spec, header config, "header pat",
               attach ssrf hook=True)

# Branch 2 (basic auth) — hook missing
return create and validate(request, spec, user config, "basic",
               user email=user email)

# Branch 3 (OAuth/PAT) — hook missing
return create and validate(request, spec, user config, "oauth pat",
               user email=user email)

attach ssrf hook defaults to False, so branches 2 and 3 silently skip the protection. The hook itself ( make ssrf safe hook) is straightforward — it checks response.is redirect, grabs the Location header, and calls validate url for ssrf() to reject private IPs. It works correctly when present.

Typical attack flow:

Attacker controls or compromises an Atlassian instance (Cloud or Server)
MCP server connects using basic auth or OAuth credentials (most production setups)
Atlassian returns 302 Location: http://169.254.169.254/latest/meta-data/iam/security-credentials/
The unprotected session follows the redirect
AWS IAM credentials (or other internal service data) are returned to the attacker

PoC

Tested on commit d8bc786 (v0.21.1). No real credentials needed.

python

from unittest.mock import MagicMock
import requests

from mcp atlassian.servers.dependencies import make ssrf safe hook
from mcp atlassian.utils.urls import validate url for ssrf
from mcp atlassian.jira import JiraFetcher
from mcp atlassian.jira.config import JiraConfig

config = JiraConfig(
  url="https://attacker.atlassian.net",
  auth type="basic",
  username="victim@example.com",
  api token="victim-token",
)
fetcher = JiraFetcher(config=config)
session = fetcher.jira. session

hooks = session.hooks.get("response", [])
print("hooks on basic-auth session:", [h. name  for h in hooks] or "none")

fake redirect = MagicMock(spec=requests.Response)
fake redirect.is redirect = True
fake redirect.headers = {"Location": "http://169.254.169.254/latest/meta-data/"}

blocked = False
for h in hooks:
  try:
    h(fake redirect)
  except ValueError as e:
    blocked = True
    print("blocked:", e)

if not blocked:
  print("redirect to 169.254.169.254 not blocked on basic-auth session")

# show header-PAT branch does block it
hook = make ssrf safe hook(validate url for ssrf)
try:
  hook(fake redirect)
except ValueError as e:
  print("header-PAT branch blocks:", e)

Output:

$ uv run python3 /tmp/test.py
hooks on basic-auth session: none
redirect to 169.254.169.254 not blocked on basic-auth session
header-PAT branch blocks: Redirect blocked (SSRF): Blocked IP address: 169.254.169.254 (non-global)

Impact

Basic auth and OAuth cover most production Atlassian Cloud deployments, so this affects the majority of HTTP-mode multi-user setups. An attacker with control over the Atlassian server can redirect MCP server requests to internal infrastructure — cloud metadata endpoints, internal Kubernetes API, databases, or any service reachable from the MCP server's network.

The fix is one line per affected branch: pass attach ssrf hook=True to create and validate() in branches 2 and 3, the same way branch 1 already does.

Correção

Encontrou algum problema na descrição? Tem algo a acrescentar? Fique à vontade para nos escrever 👾

dbugs@ptsecurity.com

Identificadores relacionados

PYSEC-2026-4085

Produtos afetados

Mcp-Attlasian