// 威脅簡報

GitHub CLI 驗證指令洩漏登入權杖:gh attestation 與 gh release verify 會把 token 送到 TUF 和檔案主機

CVSS: 9.1 CRITICAL
CISA KEV: 未列入
弱點類型: CWE-863
主題: 供應鏈

PlainCVE 團隊 · 發布 2026-09-24 · AI 輔助 · 媒體簡報 ↓

人工審稿 2026-09-24指令測試:未提供漏洞重現:未進行驗證紀錄 ↓

GitHub CLI 2.93.0 以前,執行三個驗證指令時可能把你的 GitHub 登入權杖附在送往 TUF 與檔案主機的請求裡。

誰會中	使用 GitHub CLI(gh)2.93.0 以前版本、已設定登入(或設定了企業版權杖環境變數),並曾執行 gh attestation、gh release verify 或 gh release verify-asset 的人,包括在 CI 裡執行這些指令的情況。
後果	權杖被送到不該收到它的主機。拿到權杖的人可以使用該權杖被授予的權限(依權杖類型與範圍而定)。GitHub 表示沒有證據顯示權杖曾被記錄、保存或被未授權者取用。
現在該做什麼	升級 gh 到 2.93.0 以上,撤銷曾搭配 GitHub CLI 使用的權杖與 OAuth 授權,再檢查帳號的安全紀錄與稽核紀錄。查看依據(4) 廠商 / 維護者官方建議的順序:撤銷搭配 GitHub CLI 用過的權杖與 OAuth 授權、升級 gh 到 2.93.0、檢查安全紀錄與稽核紀錄Revoke authentication tokens used with the GitHub CLIgithub.com 廠商 / 維護者GitHub 文件:安全紀錄列出最近 90 天的活動,可用來檢查可疑的權杖使用The security log lists all actions performed within the last 90 days.docs.github.com 本站判斷先升級、再重新登入或換新權杖,是本站的提醒,避免新權杖在舊版上又被送出;官方公告列出的順序是撤銷、升級、檢查紀錄本站判斷只在需要時設定企業版權杖,是本站的建議
受影響版本	2.93.0 以前的版本(github.com/cli/cli/v2 ≤ 2.92.0) 查看依據(4) 廠商 / 維護者GitHub CLI 安全公告:已登入 github.com 並執行過這三個驗證指令的人,權杖會送到 tuf-repo.github.com,所有登入方式都受影響All authentication types are affected.github.com 廠商 / 維護者同一份公告:設定了企業版權杖並執行這些指令的人,權杖會送到 sigstore.dev 與 Azure Blob Storage,這些主機不由 GitHub 營運These hosts are not operated by GitHub.github.com CVE 紀錄CVE 紀錄:2.93.0 以前受影響"version":"< 2.93.0"cveawg.mitre.org 漏洞資料庫Go 漏洞資料庫把舊模組路徑 github.com/cli/cli(沒有 v2)列為所有版本、無修補;這是自動產生、未經人工審閱的項目,實際修補在 v2 的 2.93.0all versions, no known fixedpkg.go.dev
修好的版本	2.93.0 以上查看依據(3) 廠商 / 維護者GitHub CLI 2.93.0 發布說明:問題已修正,建議盡快更新到 v2.93.0Users are advised to update `gh` to version `v2.93.0` as soon as possible.api.github.com CVE 紀錄CVE 紀錄:2.93.0 已修補This vulnerability is fixed in 2.93.0.cveawg.mitre.org 漏洞資料庫NVD 的 CPE 設定:受影響範圍到 2.93.0 以前為止"versionEndExcluding":"2.93.0"services.nvd.nist.gov
CVSS 向量	顯示完整向量 `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N`
時間點	首次公開 2026-05-27
CISA KEV	未列入(未列入 KEV 不代表沒有被利用) 查看依據(3) 本站判斷本站 2026-09-24 的 CISA KEV 快照沒有這個 CVE;未列入不代表沒有被利用 CERT / 政府CISA 在 CVE 紀錄中的 SSVC 評估為「實際利用:無」"Exploitation":"none"cveawg.mitre.org 廠商 / 維護者GitHub 表示沒有證據顯示權杖曾被記錄、保存或被未授權者取用We have no evidence that tokens were logged, retained, or accessed by unauthorized parties.github.com

藍隊應對手冊

確認、修補 / 緩解、應變、強化。版本符合受影響條件不等於已被入侵;檢查沒有結果也不等於安全,每一項都有能證明與不能證明的範圍。標記的步驟對應下方攻擊流程裡可以擋下攻擊的那一步。

DETECT確認我受影響嗎?有沒有入侵跡象?

01確認 gh 版本
版本低於 2.93.0 就在受影響範圍內。CI 映像檔與開發機都要查。
唯讀查詢
```
gh --version
```
步驟 1
02確認是否符合曝險條件
曾在已登入狀態下執行三個驗證指令之一,就可能受影響;若同時設定了企業版權杖環境變數,權杖還可能送到 GitHub 以外的主機。這是 PlainCVE 依官方公告條件整理的判斷方式,不是官方程序。下面的指令只印出變數名稱,不會印出權杖內容。
唯讀查詢
```
env | grep -oE '^(GH|GITHUB)_ENTERPRISE_TOKEN'
```
步驟 1 步驟 2
03檢查安全紀錄
在 GitHub 的 Settings → Archives → Security log 查看最近 90 天的紀錄,包括 OAuth 與個人存取權杖事件,可篩選與匯出。組織或企業另查稽核紀錄。
步驟 5

MITIGATE修補 / 緩解先修補;還不能修補時先擋住

01升級到 2.93.0 以上
用你原本安裝 gh 的方式更新(套件管理工具、官方安裝檔或 Go 模組),再確認版本。官方沒有公布不升級的暫時解法。
唯讀查詢
```
gh --version
```
步驟 1 步驟 2

RESPOND應變發現入侵跡象時

01撤銷搭配 GitHub CLI 使用過的權杖
官方建議撤銷個人存取權杖以及 GitHub CLI 的 OAuth 應用程式授權;設定過企業版權杖的也一併撤銷。這是預防措施,官方表示沒有證據顯示權杖被取用。
步驟 3 步驟 4
02發現可疑活動時擴大調查
若安全紀錄或稽核紀錄出現不認得的權杖使用,依照一般帳號入侵流程處理,檢查該權杖能存取的程式庫與設定。
步驟 5

HARDEN強化長期避免同類問題

01只在需要時設定企業版權杖
這次最嚴重的情況,是企業版權杖被當成不認得主機的預設值送出。避免在不需要的環境(例如只驗證公開成品的 CI 工作)長期設定它。這是 PlainCVE 的建議。
步驟 2 步驟 4
02權杖用最小權限
權杖外流時,對方能做的事等於權杖本身的權限。範圍越小,損害越有限。
步驟 5

完整修復步驟與說明

版本	狀態
≤ 2.92.0(`github.com/cli/cli/v2`)	受影響
2.93.0 以上	已修補

順序很重要。 建議先升級,再重新登入或換上新權杖。如果先換權杖,卻在舊版上又執行這些驗證指令,新權杖可能同樣被送出去。這是 PlainCVE 的提醒,官方公告列出的順序是撤銷、升級、檢查紀錄。
撤銷 OAuth 授權後要重新登入。 撤銷 GitHub CLI 的 OAuth 應用程式授權後,gh 會失去登入狀態,需要再登入一次。
CI 也要換。 若在 CI 裡設定過這些權杖變數,記得同時更新 CI 使用的 gh 版本與密鑰設定。
沒有暫時解法。 官方沒有公布不升級也能避開的做法。

攻擊流程

從左到右是攻擊發生的順序。藍色盾牌代表這一步可以被擋下,越早擋下越好。點圖示可看細節。

圖片可自由用於報導與教學,採 CC BY 4.0,圖上已附出處。

你的系統
使用者或 CI 執行驗證指令
執行 gh attestation、gh release verify 或 gh release verify-asset,而且 gh 已登入,或設定了 GH_ENTERPRISE_TOKEN / GITHUB_ENTERPRISE_TOKEN。
防禦: 升級到 2.93.0 以上再執行這些指令。
你的系統
共用的 HTTP 用戶端依主機名稱挑權杖
舊版把所有 *.github.com 子網域都當成 github.com;遇到不認得的主機時,若有設定企業版權杖就改用它。
防禦: 2.93.0 修正了權杖附加的判斷。
外部
github.com 權杖被送到 tuf-repo.github.com
這是 GitHub Pages 網站,不是 GitHub API 伺服器,本來不需要也不該收到權杖。
防禦: 撤銷曾搭配 gh 使用的個人存取權杖與 OAuth 授權。
外部
企業版權杖被送到 GitHub 以外的主機
設定了企業版權杖的人,權杖會被送到 tuf-repo-cdn.sigstore.dev 與 tmaproduction.blob.core.windows.net(Azure Blob Storage)。
防禦: 撤銷企業版權杖;非必要不要在環境變數裡長期設定它。
攻擊者
假設權杖落入他人手中,就能冒用你的權限
這是風險情境,不是已發生的事:GitHub 表示沒有證據顯示權杖曾被記錄、保存或被未授權者取用。
防禦: 在安全紀錄與稽核紀錄中查看可疑的權杖活動。

影響範圍

GitHub CLI(gh)是 GitHub 官方的命令列工具。受影響的是以下三個「驗證」指令:gh attestation、gh release verify、gh release verify-asset。它們用來確認一個檔案或發行版本從哪裡建置而來、有沒有被改過。

條件	權杖會被送到哪裡	是否受影響
gh 2.93.0 以前 + 已登入 github.com + 執行上述指令	`tuf-repo.github.com`(GitHub Pages 網站,不是 API 伺服器)	受影響
gh 2.93.0 以前 + 設定了 `GH_ENTERPRISE_TOKEN` 或 `GITHUB_ENTERPRISE_TOKEN` + 執行上述指令	`tuf-repo-cdn.sigstore.dev`、`tmaproduction.blob.core.windows.net`(Azure Blob Storage),都在 GitHub 以外	受影響
gh 2.93.0 以前,但從沒執行過這三個指令	無	依官方描述的條件不受影響
gh 2.93.0 以上	無	已修補

「權杖」(token)是一串代表你身分的字串,程式拿著它就能以你的權限存取 GitHub。GH_ENTERPRISE_TOKEN / GITHUB_ENTERPRISE_TOKEN 是給 GitHub Enterprise Server 用的權杖變數;GH_TOKEN / GITHUB_TOKEN 則用於 github.com。

在 CI(持續整合,自動建置與驗證的流程)裡,權杖常放在環境變數中,這類驗證指令也可能在那裡執行。這是 PlainCVE 的推論,來源沒有直接這樣說。

原理

這三個指令驗證時,需要下載 TUF(The Update Framework,gh 用來取得「該信任哪些簽章」的中繼資料)與成品資料。它們透過 gh 共用的 HTTP 用戶端下載,而這個用戶端有一層認證機制,會自動替送出的請求加上權杖。

問題在「要附哪個權杖」的判斷:

程式把主機名稱正規化時,把所有 *.github.com 子網域都當成 github.com,所以 tuf-repo.github.com 也拿到了 github.com 權杖。
遇到不認得的主機時,如果有設定企業版權杖,就改附企業版權杖,於是權杖被送到 sigstore.dev 與 Azure 的主機。

這對應 CWE-863(授權判斷不正確)。這個 CWE 來自 GitHub;NVD 沒有另外指定。

有問題的思路(概念示意,不是原始程式碼):

展開程式碼範例(go)

// 主機名稱「大概像」GitHub 就附 github.com 權杖,否則改附企業版權杖
func tokenFor(host string) string {
    if strings.HasSuffix(host, ".github.com") || host == "github.com" {
        return githubToken
    }
    return enterpriseToken // 不認得的主機也拿到權杖
}

修好的思路:

展開程式碼範例(go)

// 只對明確列出的 API 主機附權杖;第三方下載一律不附
func tokenFor(host string) string {
    if isKnownAPIHost(host) { // 精確比對的清單
        return tokenForHost(host)
    }
    return ""
}

GitHub 表示沒有證據顯示權杖曾被記錄、保存或被未授權者取用。不過官方公告指出,若有人真的拿到這些權杖,就能使用該權杖被授予的權限,依權杖類型與權限範圍而定,可能包括私人儲存庫、組織資源,甚至企業管理權限,所以官方仍建議撤銷。對 github.com 使用者,官方公告說明所有登入方式都受影響。

時間軸

日期	事件
不明	問題被引入、被回報的日期都沒有公開
2026-05-27	釋出 v2.93.0,GitHub 安全公告公開
2026-05-29	CVE 公開,NVD 同日收錄
2026-06-25	Go 漏洞資料庫發布 GO-2026-5271
2026-07-21	NVD 分析最後更新
2026-07-30	GitHub 安全公告最後更新

驗證紀錄已人工審稿、核對來源;尚未在我們的環境重現

人工審稿	2026-09-24

驗證紀錄只寫環境與結果,不公開重現步驟或可攻擊他人系統的程式。詳見政策.

來源

安全公告Incorrect authorization header in API requests to TUF repository mirrors via gh attestation, gh release verify, and gh release verify-asset commands (GHSA-8xvp-7hj6-mcj9) · GitHub (cli/cli), 2026-05-27 · 查閱 2026-09-23
安全公告GitHub Advisory Database: GHSA-8xvp-7hj6-mcj9 · GitHub, 2026-05-27 · 查閱 2026-09-23
安全公告CVE-2026-48501 record (CVE Services API) · CVE Program / MITRE, 2026-05-29 · 查閱 2026-09-23
CVE / NVD / OSVNVD CVE API: CVE-2026-48501 · NIST NVD, 2026-05-29 · 查閱 2026-09-23
安全公告OSV: GHSA-8xvp-7hj6-mcj9 · OSV / Google, 2026-05-29 · 查閱 2026-09-23
安全公告GO-2026-5271 · Go Vulnerability Database, 2026-06-25 · 查閱 2026-09-23
修補 commit / 版本GitHub CLI 2.93.0 release · GitHub (cli/cli), 2026-05-27 · 查閱 2026-09-23
修補 commit / 版本GitHub CLI 2.93.0 (release API metadata) · GitHub, 2026-05-27 · 查閱 2026-09-23
其他CVE-2026-48501: Cli Incorrect Authorization (CVSS 9.1) · Strix · 查閱 2026-09-23
廠商說明gh attestation verify · GitHub CLI manual · 查閱 2026-09-23
廠商說明gh help environment · GitHub CLI manual · 查閱 2026-09-23
廠商說明Reviewing your security log · GitHub Docs · 查閱 2026-09-23
廠商說明Managing your personal access tokens · GitHub Docs · 查閱 2026-09-24

媒體簡報

一句話

GitHub CLI 是 GitHub 官方的命令列工具。2.93.0 以前的版本在執行三個用來驗證軟體來源的指令時,可能把使用者的 GitHub 登入權杖送到不該收到它的主機,其中部分主機不屬於 GitHub。GitHub 已在 2026 年 5 月 27 日釋出修補版 2.93.0,並表示沒有證據顯示權杖曾被記錄或被未授權者取用。這個漏洞沒有被列入美國 CISA 的已知遭利用漏洞清單。

關鍵數字

嚴重度(NVD): CVSS 3.1 9.1 services.nvd.nist.gov
嚴重度(GitHub,CNA): CVSS 3.1 7.4 github.com
修補版本: 2.93.0(2026-05-27 釋出) api.github.com
CVE 公開: 2026-05-29 cveawg.mitre.org
CISA SSVC 評估: 實際利用:無 cveawg.mitre.org

已確認

GitHub CLI 2.93.0 以前,三個驗證指令可能在授權標頭中附上使用者的權杖,送往 TUF 與成品主機。
github.com 權杖會送到 tuf-repo.github.com;企業版權杖會送到 sigstore.dev 與 Azure Blob Storage 的主機。
GitHub 表示沒有證據顯示權杖曾被記錄、保存或被未授權者取用。

尚未確認 / 說法不一

嚴重度評分不一致:NVD 給 9.1,GitHub 給 7.4,差別只在攻擊複雜度。
問題從哪個版本開始存在,官方沒有說明。
修補對應的 commit 或 PR 沒有公開連結。

可引用的一句話

用來確認軟體沒被動過手腳的工具,自己卻把鑰匙交給了不該拿到的人。

圖片

下載分享圖(PNG) · 攻擊流程圖(可下載)

引用時請標示「PlainCVE」並附上本頁連結。完整引用格式見下方「如何引用本頁」。有事實錯誤請回報.

GitHub CLI 驗證指令洩漏登入權杖:gh attestation 與 gh release verify 會把 token 送到 TUF 和檔案主機

GitHub CLI 是 GitHub 官方的命令列工具。2.93.0 以前的版本在執行三個用來驗證軟體來源的指令時,可能把使用者的 GitHub 登入權杖送到不該收到它的主機,其中部分主機不屬於 GitHub。GitHub 已在 2026 年 5 月 27 日釋出修補版 2.93.0,並表示沒有證據顯示權杖曾被記錄或被未授權者取用。這個漏洞沒有被列入美國 CISA 的已知遭利用漏洞清單。

關鍵數字:
- 嚴重度(NVD):CVSS 3.1 9.1(https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-48501)
- 嚴重度(GitHub,CNA):CVSS 3.1 7.4(https://github.com/cli/cli/security/advisories/GHSA-8xvp-7hj6-mcj9)
- 修補版本:2.93.0(2026-05-27 釋出)(https://api.github.com/repos/cli/cli/releases/tags/v2.93.0)
- CVE 公開:2026-05-29(https://cveawg.mitre.org/api/cve/CVE-2026-48501)
- CISA SSVC 評估:實際利用:無(https://cveawg.mitre.org/api/cve/CVE-2026-48501)

已確認:
- GitHub CLI 2.93.0 以前,三個驗證指令可能在授權標頭中附上使用者的權杖,送往 TUF 與成品主機。
- github.com 權杖會送到 tuf-repo.github.com;企業版權杖會送到 sigstore.dev 與 Azure Blob Storage 的主機。
- GitHub 表示沒有證據顯示權杖曾被記錄、保存或被未授權者取用。

尚未確認 / 說法不一:
- 嚴重度評分不一致:NVD 給 9.1,GitHub 給 7.4,差別只在攻擊複雜度。
- 問題從哪個版本開始存在,官方沒有說明。
- 修補對應的 commit 或 PR 沒有公開連結。

「用來確認軟體沒被動過手腳的工具,自己卻把鑰匙交給了不該拿到的人。」— PlainCVE
https://plaincve.date/vulns/cve-2026-48501-github-cli-token-leak

如何引用本頁

本文採 CC BY 4.0,轉載請保留署名與連結。

PlainCVE 團隊(2026)。《GitHub CLI 驗證指令洩漏登入權杖:gh attestation 與 gh release verify 會把 token 送到 TUF 和檔案主機》。PlainCVE。https://plaincve.date/vulns/cve-2026-48501-github-cli-token-leak(查閱日期:YYYY-MM-DD)

BibTeX

@misc{cve202648501githubclitokenleak2026,
  title  = {GitHub CLI 驗證指令洩漏登入權杖:gh attestation 與 gh release verify 會把 token 送到 TUF 和檔案主機},
  author = {PlainCVE 團隊},
  year   = {2026},
  howpublished = {PlainCVE},
  url    = {https://plaincve.date/vulns/cve-2026-48501-github-cli-token-leak},
  note   = {更新於 2026-09-24}
}