mcp-atlassian 0.22.0 修補的 29 個漏洞：HTTP 認證繞過、伺服器檔案外洩、SSRF、權杖檔權限等

影響範圍

29 個 CVE 的記錄都寫 0.22.0 以前受影響；對應的 29 份 GitHub 安全公告（GHSA）都由維護者在 2026-07-10 公開，也就是 0.22.0 釋出的同一天，CVE 則在 2026-09-22 一起公開。發布說明寫這一版處理了一次安全稽核的 37 份公告；本頁涵蓋其中取得 CVE-2026-772xx 編號的 29 個。維護者的公告列表裡另有 3 個同樣在 0.22.0 修補、較早公開的 CVE（CVE-2026-73496、CVE-2026-73497、CVE-2026-73498），以及一份還沒有 CVE 記錄的 GHSA-6rrj-86cw-gg9j，不在本頁範圍。

哪些部署最危險，要看傳輸模式和設定：

OSV 列出 CVE-2026-77244 受影響的已標記版本是 v0.1.4 到 v0.21.1。OSV 的範圍起點是 introduced: "0"，依 OSV 格式定義這是代表「排在所有版本之前」的特殊值，並沒有指出特定的引入 commit；漏洞實際從哪個版本開始存在尚未確認。

29 個 CVE 一覽

CVSS 是 CVE 記錄中 CNA 給的分數；標「（4.0）」的是 CVSS 4.0，其餘是 3.1，兩種版本的分數不能直接比較。「主要前提」整理自各公告，是攻擊需要的條件，不是完整描述。

原理

mcp-atlassian 是一個 MCP 伺服器：它讓 AI 助理透過 MCP 協定呼叫 Jira 與 Confluence 的功能。它可以在本機用 stdio 和一個 AI 用戶端溝通，也可以用 HTTP 在網路上同時服務多個使用者。這 29 個漏洞大致分成七類。

1. HTTP 認證繞過（3 個：CVE-2026-77244、CVE-2026-77254、CVE-2026-77248）

用 HTTP 提供服務時，每個請求照理應該附上使用者自己的身分證明（token，一串用來證明「你是誰」的字串）。舊版的問題有兩層。第一，HTTP 模式會接受沒有確認身分的請求；官方公告標題也指出，token 驗證器只要 token 不是空的就接受。第二，當請求沒有可用的使用者憑證時，程式會退回使用營運者在伺服器上設定的全域 Jira 或 Confluence 帳號。兩者加起來：任何連得到端點的人，不需帳號，就能以營運者的身分讀寫資料，而且稽核紀錄記的是營運者的名字。CVE-2026-77244 的 CVE 記錄將它歸類為 CWE-287（認證不當），另列 CWE-303 與 CWE-862；CVE-2026-77254 描述的是同一個全域憑證退回問題（CWE-306），CVE-2026-77248 則是把它和下面的附件讀檔串在一起的報告。

有問題的思路（概念示意，不是原始程式碼）：

user_creds = get_user_credentials(request)   # 可能是空的
if not user_creds:
    user_creds = GLOBAL_OPERATOR_CREDENTIALS   # 沒身分 → 借用營運者帳號
client = make_jira_client(user_creds)

修好的思路（0.22.0）：

user_creds = get_user_credentials(request)
if not user_creds:
    if not ALLOW_GLOBAL_CRED_FALLBACK:          # 預設關閉
        return http_401()                       # 在傳輸層直接拒絕
    user_creds = GLOBAL_OPERATOR_CREDENTIALS

2. 權限限制失效：工具清單與專案／空間篩選（3 個）

營運者可以用 ENABLED_TOOLS、TOOLSETS 限制能用哪些工具，用 JIRA_PROJECTS_FILTER、CONFLUENCE_SPACES_FILTER 限制能碰哪些專案與空間。CVE-2026-77243 的問題是工具限制只套用在「列出工具」的時候：被藏起來的工具雖然不出現在清單上，直接用名字呼叫仍然會執行，包括寫入與刪除。CVE-2026-77251、CVE-2026-77252 的問題是專案／空間篩選只用字串比對判斷查詢裡有沒有指定專案，呼叫者自己在查詢裡指定別的專案或空間，篩選就不會加上去；呼叫參數也能直接蓋掉營運者的設定，而看板相關工具根本沒有檢查。前提是呼叫者已經能用這些工具（例如正當使用者，或被提示注入的 AI），而伺服器的帳號本身看得到比篩選更大的範圍。0.22.0 改為在呼叫時強制檢查工具權限，篩選條件一律加進查詢，呼叫者只能縮小、不能擴大範圍。

3. 附件上傳工具讀出伺服器檔案（12 個）

Jira 與 Confluence 的附件上傳工具（包括 Jira update_issue 的附件參數）接受一個「伺服器上的檔案路徑」，由伺服器程序讀出檔案，再上傳成附件。舊版沒有限制這個路徑，所以呼叫者可以指定伺服器程序讀得到的任何檔案，例如含 API token 的環境變數、.env、SSH 金鑰或雲端憑證，讓它被上傳到自己看得到的議題或頁面。多份公告指出這是 CVE-2026-27825 修補不完整：0.17.0 已經替「下載附件、寫入檔案」的方向加上路徑檢查，「上傳附件、讀取檔案」的方向卻沒有。12 份公告是不同研究者各自回報同一個根本原因，前提的描述不一：多數要求呼叫者能使用寫入工具並有一個能附加檔案的議題或頁面；有的指出 AI 被提示注入時就會觸發，本機 stdio 模式也受影響；有的則描述不需帳號的情境（見下文「串連」）。

有問題的思路（概念示意）：

path = caller_supplied_path          # 呼叫者指定的路徑
upload_as_attachment(open(path, "rb"))  # 直接讀伺服器上的檔案

修好的思路（0.22.0）：

path = validate_safe_path(caller_supplied_path)  # 必須落在伺服器的工作目錄內，否則拒絕
upload_as_attachment(open(path, "rb"))

4. 路徑限制不完整導致覆寫程式模組（1 個：CVE-2026-77271）

0.17.0 修補 CVE-2026-27825 時，把下載附件能寫入的位置限制在程序的工作目錄內。問題是在常見的容器部署裡，工作目錄就是程式本身所在的目錄，所以程式自己的 Python 模組也在「允許寫入」的範圍內。公告描述，有 Confluence 寫入權限、連得到 HTTP 埠的人可以用附件覆寫程式檔，程序下次重啟時就會執行被換掉的程式碼。0.22.0 發布說明表示已關閉這個「工作目錄內覆寫」的變形。

5. SSRF 防護被繞過（6 個）

SSRF（伺服器端請求偽造）是讓伺服器替攻擊者去連它不該連的位址，例如內部服務或雲端中繼資料服務（可能拿到雲端憑證）。多使用者 HTTP 模式允許用請求標頭指定要連的 Jira／Confluence 網址；0.17.0 為 CVE-2026-27826 加了檢查，拒絕指向內部位址的網址。這 6 個 CVE 都是這道檢查的缺口：檢查時解析的位址和實際連線時不同（DNS 重新綁定，CVE-2026-77242、CVE-2026-77265）；伺服器被轉址到內部位址時，有些程式路徑或認證方式沒有檢查轉址（CVE-2026-77249、CVE-2026-77261）；檢查器和實際發出請求的程式對同一個網址看到不同主機（CVE-2026-77274）；以及標頭網址仍有沒經過檢查的路徑（CVE-2026-77267）。其中 CVE-2026-77261 是 basic auth 與 OAuth 這兩種認證方式沒有檢查轉址，前提是所連的 Atlassian 伺服器本身回傳惡意轉址。0.22.0 讓每個連線都檢查轉址、拒絕會造成解讀不一致的網址，並把連線固定在檢查過的那個位址。

6. OAuth 權杖檔案權限太寬（3 個：CVE-2026-77250、CVE-2026-77256、CVE-2026-77268）

使用 OAuth 時，程式把權杖存進系統的金鑰圈（keyring），但同時一定會在家目錄的 .mcp-atlassian 資料夾另存一份明文備份，內含 access token 與 refresh token。這個檔案用系統預設權限建立，常見設定下同群組或同一台機器的所有使用者都讀得到。共用主機、CI 機器或掛載家目錄的容器裡，其他使用者或程序就能拿走權杖，refresh token 在撤銷或過期前都能持續取得存取權。0.22.0 改為只給擁有者讀寫（檔案 0600、資料夾 0700）。

7. OAuth 設定頁的反射型 XSS（1 個：CVE-2026-77272）

執行 OAuth 設定精靈時，程式會暫時開一個接收授權回呼的網頁伺服器，而且綁在所有網路介面上。回呼頁面會把網址裡的錯誤訊息原樣放進 HTML，所以特製的連結可以在受害者的瀏覽器裡執行 JavaScript。前提是受害者正在執行設定精靈（公告說最多等 5 分鐘），並點開攻擊者給的連結。0.22.0 讓回呼頁面對輸出做 HTML 跳脫。

串連起來會怎樣

有公告明確寫出的： HTTP 認證繞過加上附件讀檔，可以讓不需帳號的人讀取伺服器上的檔案。公告 GHSA-cc5h-2pwp-pvcc（CVE-2026-77248）寫道：「Chained, an unauthenticated network attacker reads arbitrary files on the MCP server host」（串連之後，不需認證的網路攻擊者可以讀取 MCP 伺服器主機上的任意檔案），前提是 streamable-http 模式並設定了全域營運者憑證。GHSA-f4p7-qx46-wc5j（CVE-2026-77260）也描述 HTTP 模式下不帶認證、借用營運者憑證完成上傳的情境；GHSA-wv8v-v4c5-v75j（CVE-2026-77246）則描述不需 Authorization 標頭、改用請求標頭指定的服務網址收下檔案。發布說明把 GHSA-cc5h-2pwp-pvcc 列在 HTTP 認證修補之下，附件路徑限制也在同一版加上，所以兩端都在 0.22.0 關閉。

PlainCVE 的判斷： 讀出的檔案常包含營運者的 Atlassian API token 或其他服務的憑證，攻擊者拿到後可以直接呼叫 Atlassian 或其他服務，不再經過 MCP 伺服器，升級也不會讓這些憑證失效；所以只要懷疑曾經曝險，就要輪替憑證，不能只升級。另外，0.22.0 以後附件路徑只限制在工作目錄內，工作目錄裡如果放了 .env 之類的秘密，在呼叫者能用上傳工具的情況下仍可能被上傳（CVE-2026-77271 的公告就以容器內工作目錄的 .env 為例）；如果又設定了 ALLOW_GLOBAL_CRED_FALLBACK=true 並對外開放，未經驗證的請求也能用上這些工具。

尚未確認的部分（PlainCVE 的判斷）

0.22.0 修補的是「退回全域憑證」這一段。0.22.0 釋出隔天（2026-07-11），維護者在另一個 PR 中承認 OAuth 代理的驗證器仍接受任何非空的 bearer token；負責向上游驗證 token 的 PR(最後更新 2026-09-21)到 2026-09-28 仍未合併。因此在啟用 OAuth 代理的情況下,0.22.0 仍有「任何非空 token 都接受」的行為(維護者確認);修正的 PR 到 2026-09-28 仍未合併,之後的版本是否已修好,沒有來源說明。

時間軸

維護者公告與修補都比 CVE 公開早約兩個半月。

延伸閱讀

• 評分： 最高的是 CVE-2026-77244，CNA 給出 CVSS 3.1 10.0（範圍改變、機密性與完整性高、沒有可用性影響）；其次是 CVE-2026-77254 的 9.1。8 個 CVE 的 CNA 分數是 CVSS 4.0。截至 2026-09-24，NVD 仍在分析 CVE-2026-77244，尚無自己的分數。
• 利用狀況： 截至 2026-09-24，這 29 個 CVE 都不在 CISA KEV。CVE 記錄中 CISA 的 SSVC 評估，CVE-2026-77244 為「none」但評為「可自動化」；2026-09-28 逐筆查詢 29 筆 CVE 記錄:26 筆有 SSVC 評估(7 筆「none」、19 筆「poc」,即有公開概念驗證),沒有一筆是「active」;3 筆(CVE-2026-77262、CVE-2026-77265、CVE-2026-77267)還沒有評估。多份公開公告附有研究者在自己的測試環境中驗證的重現步驟。沒有來源回報實際遭利用，也沒有資料說明修補前是否曾遭利用。FIRST 公布的 CVE-2026-77244 EPSS(未來 30 天被利用的機率估計)為 0.28%(2026-09-27)。
• 程式碼執行： 只有 CVE-2026-77271 的公告描述可以導致執行程式碼（覆寫程式模組、重啟後生效）；其他公告沒有這樣說。CVE-2026-77244 的公告只提到它與另一個較早的 CVE（CVE-2026-27825）屬於同類問題。
• 相關公告： GHSA-vc8m-84rp-53hx（CVE-2026-77254）描述同樣的全域憑證退回問題，由同一個修補關閉。
• 相關弱點類型：CWE-287、CWE-306、CWE-862、CWE-22、CWE-918、CWE-732、CWE-79；設計原則「失敗時預設拒絕」（fail-closed）與「在執行時檢查權限，而不只是在列出時」。