FlawOpen

flawopen.com/Teardowns/cve-2026-27826-mcp-atlassian-ssrf

● CVE-2026-27826 · CVSS 8.2[1], [3] · Tinggi
Riset Keamanan · FlawOpen

CVE-2026-27826: SSRF MCP Atlassian

SSRF awal berbasis header pada CVE-2026-27826 diperbaiki di 0.17.0. Celah SSRF lain yang ditemukan kemudian diperbaiki di 0.22.0; periksa setiap advisori sebelum menetapkan versi minimum untuk seluruh armada.[1], [2], [6], [8], [9], [10], [11]

💡 Penjelasan Sederhana (ELI5)

Bayangkan bagian surat perusahaan hanya boleh mengirim paket ke kantor yang telah disetujui. Seorang pengunjung menulis alamat lain pada formulir khusus, lalu petugas mengikutinya tanpa memeriksa. Fetcher server berperan seperti bagian surat itu: header permintaan menentukan alamat dan server mengirim permintaan keluar. Perbaikan 0.17.0 memeriksa URL yang dikirim sebelum server terhubung dan memeriksa tujuan pengalihan; operator juga dapat mengonfigurasi daftar domain yang diizinkan.[1], [2]

Konsep Kunci & Istilah

Server-side request forgery (SSRF)
Celah yang memungkinkan pemanggil memengaruhi permintaan keluar server sehingga mencapai tujuan yang tidak dimaksudkan aplikasi.[1], [4]
Transport MCP
Saluran komunikasi antara klien dan server MCP. Masalah ini memengaruhi transport streamable-HTTP dan SSE, bukan penerapan stdio saja yang dijelaskan dalam advisori.[1]
Autentikasi multi-tenant berbasis header
Mode yang menerima URL dan token Atlassian pada setiap permintaan untuk membuat klien API khusus bagi suatu tenant.[1], [2]
Kebijakan egress jaringan
Kontrol jaringan yang membatasi tujuan yang dapat dihubungi layanan dan mengurangi dampak kegagalan validasi URL di aplikasi.[12], [1]
Injeksi prompt tidak langsung
Konten tidak tepercaya yang dikembalikan alat dapat memuat instruksi yang memengaruhi model. Untuk CVE ini, advisori menyebut respons layanan yang dikendalikan penyerang masuk ke hasil alat; dampak ini berbeda dari SSRF itu sendiri.[1], [7]
Perbaikan SSRF lanjutan
Advisori awal CVE-2026-27826 mencantumkan 0.17.0 sebagai versi perbaikan. Setelah itu, maintainer mendokumentasikan empat jalur perbaikan tidak lengkap yang berbeda sebagai CVE-2026-77242, CVE-2026-77267, CVE-2026-77249, dan CVE-2026-77274; setiap advisori mencantumkan 0.22.0 sebagai versi yang diperbaiki. Ini adalah CVE terpisah, bukan perluasan rentang terdampak CVE-2026-27826. Periksa advisori yang lebih baru sebelum menentukan versi minimum untuk seluruh armada.[8], [9], [10], [11]

Pemetaan kerangka kerja

Analisis Akar Masalah (Root Cause)

Pada jalur HTTP yang terdampak, server membaca X-Atlassian-Jira-Url atau X-Atlassian-Confluence-Url dari permintaan lalu meneruskan nilainya ke JiraConfig atau ConfluenceConfig untuk membuat fetcher. Pada cabang autentikasi berbasis header yang rentan, tujuan tidak dibandingkan dengan URL tenant yang dikonfigurasi server maupun kebijakan tujuan sebelum fetcher membuat permintaan pertamanya. Advisori maintainer menunjuk middleware permintaan dan jalur penyedia dependensi, bukan handler alat MCP tertentu. Celah ini memerlukan transport HTTP dan kondisi autentikasi header yang terdampak; jangan menggeneralisasikannya ke semua penerapan MCP.[1], [2]

Alur Serangan Langkah demi Langkah

Langkah 1

Transport HTTP dapat dijangkau

Penerapan memakai streamable-HTTP atau SSE dan membuka endpoint MCP bagi pemanggil yang dapat menjangkaunya.[1], [2]

Langkah 2

Header memilih URL layanan

Pada jalur autentikasi header yang terdampak, header URL dan token Jira atau Confluence tersedia tanpa header Authorization yang diharapkan jalur alternatif.[1], [2]

Langkah 3

Middleware membuat fetcher

Middleware menyimpan URL yang diterima dan penyedia dependensi memakainya untuk mengonfigurasi fetcher Atlassian tanpa menegakkan batas tujuan yang semestinya.[1], [2]

Langkah 4

Server mengirim permintaan keluar

Inisialisasi fetcher mengirim permintaan ke tujuan pilihan pemanggil. Bergantung pada jaringan dan respons tujuan, layanan internal dapat terekspos atau konten yang dikendalikan pihak luar masuk ke hasil alat.[1], [2]

Kode Sumber: Rentan vs Aman

Cuplikan rentan membiarkan URL dari header permintaan memilih tujuan koneksi keluar server. Patch upstream 0.17.0 tidak mengganti mode tenant berbasis header ini dengan registri tenant di server: middleware ASGI memvalidasi URL Jira atau Confluence yang diberikan sebelum fetcher dibuat, lalu menambahkan response hook untuk memvalidasi tujuan redirect. Cuplikan yang diperkuat menunjukkan dua kontrol upstream tersebut; implementasi validator tidak disertakan. Registri tenant di server adalah arsitektur alternatif yang lebih kuat, bukan yang diterapkan patch ini. Advisory lanjutan untuk 0.22.0 mendokumentasikan jalur residual yang berbeda, jadi jangan jadikan 0.17.0 sebagai versi minimum seluruh fleet tanpa meninjaunya. Validasi DNS juga harus diterapkan saat koneksi untuk menahan rebinding; resolusi hostname satu kali belum menutup batas SSRF sepenuhnya.[1], [2]

Cuplikan sumber: Kutipan patch upstream pada middleware dan fetcher (jalur Jira; Confluence memiliki pemeriksaan setara).

IMPLEMENTASI RENTAN
header_jira_fetcher = JiraFetcher(config=header_config)
current_user_id = header_jira_fetcher.get_current_user_account_id()
PERBAIKAN AMAN & KUAT
ssrf_error = validate_url_for_ssrf(jira_url_str)
if ssrf_error:
    scope["state"]["auth_validation_error"] = (
        f"Forbidden: Invalid Jira URL - {ssrf_error}"
    )
    return

header_jira_fetcher = JiraFetcher(config=header_config)
header_jira_fetcher.jira._session.hooks["response"].append(
    _make_ssrf_safe_hook(validate_url_for_ssrf)
)
current_user_id = header_jira_fetcher.get_current_user_account_id()

Daftar Periksa Penguatan Sistem Rekayasa

Sumber