// 威脅簡報

BotSharp 寫死的 JWT 簽章金鑰:沒換掉預設金鑰,攻擊者能偽造登入憑證,冒充已知使用者(CVE 紀錄稱包括管理員)

CVSS: 9.3 CRITICAL
CISA KEV: 未列入
弱點類型: CWE-321
主題: Web 應用 · AI 安全

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

AI 審稿 2026-10-18(未經人工)指令測試:未提供漏洞重現:未進行驗證紀錄 ↓

BotSharp 5.2.0 以前(含)的設定檔內建公開的 JWT 簽章金鑰;若沒有替換,任何人都能偽造登入憑證,冒充已知使用者(CVE 紀錄稱包括管理員,發現者的報告則說未確立管理員權限)。

誰會中	執行 BotSharp WebStarter 5.2.0 以前(含)的版本、沒有用環境變數或其他設定來源覆寫 Jwt:Key,且 API 可從網路連到的部署。
後果	CVE 紀錄(CNA,VulnCheck)寫:不需帳號的遠端攻擊者可以冒充任何已知使用者(包括管理員),操作需要登入([Authorize])的 API 路由。CVE 紀錄引用的發現者報告則只確認偽造憑證能通過 [Authorize] 驗證,明說沒有確立管理員權限、權限提升或存取特定使用者資料,也沒有做執行期驗證。
現在該做什麼	目前沒有已知的修補版本(非官方建議;維護者尚未發布公告)。研究者與第三方網站 OffSeq 建議用環境變數、user secret 或命令列選項把 Jwt:Key 換成只有你知道的隨機值;PlainCVE 另建議限制 WebStarter API 的網路存取(研究者指出攻擊者必須能透過網路連到 API)。
受影響版本	5.2.0 以前(含)的所有版本;研究者在 r5.2-image-composition(commit a11ee03)與 master commit 5151983 上確認,更早的版本未測試
修好的版本	目前沒有已知的修補版本
CVSS 向量	顯示完整向量 `CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N`
時間點	首次公開 2026-10-11

藍隊應對手冊

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

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

01確認是否仍在使用預設金鑰
受影響條件:執行 BotSharp WebStarter 5.2.0 以前(含)且沿用預設的簽章驗證(enableValidation = true)、Jwt:Key 沒有被環境變數、user secret 或命令列選項覆寫、API 可從網路連到;攻擊者還需知道要冒充的使用者身分。在 BotSharp 原始碼根目錄執行下面的指令(只讀檔案);已發布的部署請改查部署目錄裡的 appsettings.json。注意:原始碼裡的設定檔一定會看到提交的金鑰,這個指令看不出部署是否用環境變數、user secret 或命令列選項覆寫了 Jwt:Key,請另外檢查部署環境的設定。如果部署實際使用的 Jwt:Key 和提交的相同且 API 可連到,就應視為受影響。
唯讀查詢
```
grep -n -A4 '"Jwt"' src/WebStarter/appsettings.json
```
步驟 1 步驟 4

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

01換掉 Jwt:Key
目前沒有已知的官方修補。第三方網站 OffSeq 建議把 Jwt:Key 換成安全、獨一無二的值,且不要寫死或提交在設定檔裡;研究者指出,只要透過其他設定來源覆寫 Jwt:Key,就不會再用到預設金鑰。這不是官方建議。
步驟 1 步驟 4
02限制 WebStarter API 的網路存取
攻擊者必須能連到 API。在換好金鑰之前,只讓可信任的網路存取它。這是 PlainCVE 的建議,不是官方建議。
步驟 3

RESPOND應變發現入侵跡象時

01檢查需登入路由上的異常活動
廠商未提供偵測指引。PlainCVE 建議:檢查管理員與其他高權限帳號在 [Authorize] 路由上的操作,找出不是本人做的動作。
步驟 5
02換金鑰後讓舊憑證全部失效
PlainCVE 的分析:因為驗證直接使用 Jwt:Key,換掉金鑰後,用舊金鑰簽出的憑證(包含偽造的)都無法再通過驗證,使用者需要重新登入。
步驟 4

HARDEN強化長期避免同類問題

01不要把簽章金鑰提交到程式庫
金鑰放在環境變數或密鑰管理服務,每個部署各自產生。
步驟 1
02追蹤官方修補
截至撰稿時,沒有已知的官方安全公告或修補 commit,研究者指出最新 master 仍是同一把金鑰。

完整修復步驟與說明

目前沒有已知的官方修補或安全公告,以下都不是官方建議。

先換金鑰,再考慮其他事。 研究者指出,只要透過其他設定來源覆寫 Jwt:Key,就不會再用到預設金鑰。在 .NET 中可用環境變數、user secret 或命令列選項提供新值。新值請用夠長的隨機字串,且不要提交到程式庫。
注意順序。 PlainCVE 的分析:換金鑰後,所有用舊金鑰簽的憑證(包括可能被偽造的)都會失效,使用者需要重新登入;這是預期行為。
確認生效。 部署後確認實際使用的 Jwt:Key 已不是 appsettings.json 裡的那一個。

攻擊流程

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

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

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

攻擊者
從公開的程式庫取得預設金鑰
WebStarter 的 appsettings.json 把 Jwt:Key 直接提交進專案,簽發者(issuer)與受眾(audience)也固定為 botsharp。
防禦: 用環境變數、user secret 或命令列選項把 Jwt:Key 換成自己的隨機值,公開的金鑰就失去作用。
攻擊者
用這把金鑰簽出假的登入憑證
憑證裡填入攻擊者知道的某個使用者身分(CVE 紀錄稱可包括管理員;發現者的報告說未確立管理員權限)。不需要任何帳號。
攻擊者
把假憑證送到 WebStarter API
攻擊者必須能透過網路連到 API。
防禦: 不要讓 WebStarter API 直接暴露在不受信任的網路。
你的系統
系統用同一把金鑰驗證簽章,驗證通過
JWT 處理程式直接從 Jwt:Key 設定值取得驗證金鑰;WebStarter 預設開啟簽章驗證,但驗的是大家都拿得到的那把金鑰。
防禦: 換掉金鑰後,用公開金鑰簽的憑證就無法通過驗證。
攻擊者
以該使用者身分操作需要登入的 API
影響範圍是標示 [Authorize] 的路由,例如建立對話;[AllowAnonymous] 的路由本來就不需要登入。
防禦: 檢查管理員帳號在需登入路由上的活動是否異常。

影響範圍

條件	是否受影響
BotSharp WebStarter 5.2.0 以前(含)+ 沿用專案內建的 Jwt:Key + API 可從網路連到	受影響
已用環境變數、user secret 或命令列選項把 Jwt:Key 換成自己的值	研究者指出此時不會使用預設金鑰
任何已知版本	目前沒有已知的修補版本

研究者在 r5.2-image-composition(commit a11ee03,2025-10-17 標記)與 master commit 5151983 上確認了問題,兩者的金鑰與驗證設定完全相同;更早的版本沒有測試。CVE 寫的「5.2.0」,PlainCVE 的判斷是最可能指 r5.2-image-composition 這個發布標籤,但沒有任何來源明確這樣說。

原理

登入後,伺服器會發給使用者一張 JWT(一段簽了章的「通行證」),之後每次請求都出示它。伺服器用一把秘密的簽章金鑰(這裡是對稱金鑰)檢查章是不是自己蓋的。

BotSharp 的 WebStarter 專案把這把金鑰直接寫在 appsettings.json 裡並提交到公開程式庫,簽發者與受眾也固定為 botsharp。官方程式碼中的 JWT 處理程式直接從 Jwt:Key 取得驗證金鑰;WebStarter 也確實開啟了簽章驗證。問題在於:驗的是一把人人都看得到的金鑰。只要部署時沒有覆寫它,攻擊者就能自己簽出通行證,通過標示 [Authorize] 的 API 路由(例如建立對話)的登入檢查。CVE 紀錄說這能冒充任何身分已知的使用者(包括管理員);發現者的報告則只確認能通過登入檢查,明說沒有確立管理員權限或存取特定使用者資料,也沒有做執行期驗證。這對應 CWE-321(使用寫死的加密金鑰)。

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

展開程式碼範例(csharp)

// 金鑰跟著原始碼一起散布
var key = config["Jwt:Key"]; // 來自提交進程式庫的 appsettings.json

較安全的做法(概念示意):

展開程式碼範例(csharp)

// 金鑰只從部署環境取得,沒有設定就拒絕啟動
var key = config["Jwt:Key"]; // 由環境變數或密鑰管理服務提供
if (string.IsNullOrEmpty(key) || key == ShippedDefaultKey)
    throw new InvalidOperationException("請設定專屬的 Jwt:Key");

時間軸

日期	事件
2025-10-17	r5.2-image-composition(commit a11ee03)標記,研究者確認此版本受影響
不明	研究者撰寫報告時,協調揭露仍在進行、尚未指派 CVE
2026-10-11	VulnCheck 公開 CVE 紀錄;NVD 收到紀錄(尚未分析);GitHub 發布未審查的公告 GHSA-w9f8-hvcg-hgcm
2026-10-12	仍未列入 CISA KEV

驗證紀錄 AI 依審稿規則逐項核對來源,全部通過;未經人工審稿,也尚未在我們的環境重現

AI 審稿	2026-10-18 · 審稿規則

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

來源

CVE / NVD / OSVCVE-2026-108860 record (CVE Services API) · CVE Program / VulnCheck, 2026-10-11 · 查閱 2026-10-12
CVE / NVD / OSVNVD - CVE-2026-108860 · NIST, 2026-10-11 · 查閱 2026-10-12
安全公告GHSA-w9f8-hvcg-hgcm (unreviewed GitHub advisory) · GitHub, 2026-10-11 · 查閱 2026-10-12
廠商說明src/WebStarter/appsettings.json at a11ee03 · SciSharp (GitHub) · 查閱 2026-10-12
廠商說明BotSharpOpenApiExtensions.cs at a11ee03 · SciSharp (GitHub) · 查閱 2026-10-12
其他CVE-2026-108860 tracker entry · HOL Guard · 查閱 2026-10-12
其他CVE-2026-108860: Use of Hard-coded Cryptographic Key in SciSharp BotSharp · OffSeq Radar · 查閱 2026-10-12

媒體簡報

一句話

開源專案 BotSharp 在 5.2.0 以前(含)的 WebStarter 專案設定檔(appsettings.json)裡,直接放了一把用來簽發登入憑證的金鑰,而這把金鑰在公開程式庫裡人人看得到。如果部署時沒有換掉它,不需要帳號的遠端攻擊者就能自己簽出憑證,冒充已知使用者;CVE 紀錄稱包括管理員,但發現者的報告說未確立管理員權限,也沒有做執行期驗證。漏洞由 VulnCheck 於 2026 年 10 月 11 日公開,評為 CVSS 4.0 的 9.3 分;目前沒有已知的修補版本。

關鍵數字

嚴重度: CVSS 4.0 9.3 / CVSS 3.1 9.1(VulnCheck) cveawg.mitre.org
受影響版本: 5.2.0 以前(含) cveawg.mitre.org
CVE 公開: 2026-10-11(由 VulnCheck 指派) cveawg.mitre.org
發現者: hieuPenguinnn cveawg.mitre.org
修補版本: 未知(第三方追蹤網站標示「未回報」) hol.org

已確認

BotSharp WebStarter 的 appsettings.json 在官方程式庫中提交了 Jwt:Key,issuer 與 audience 固定為 botsharp。
截至 2026-10-12,未列入 CISA 已知遭利用漏洞清單。

尚未確認 / 說法不一

CVE 紀錄(CNA)寫:若未覆寫金鑰,不需認證的遠端攻擊者可冒充任何已知使用者(包括管理員),作用於 [Authorize] 保護的 API 路由;但它引用的發現者報告只做靜態分析,明說沒有確立管理員權限,也沒有做執行期驗證。
沒有已知的修補版本或官方安全公告;研究者指出最新 master 仍有同一把金鑰。
嚴重度說法不一:CNA 評為「嚴重」(9.1/9.3),研究者標示為「高,有條件」。
有新聞網站稱可導致「完全接管主機」,但 CVE 紀錄只描述 API 上的身分冒充,沒有主要來源支持此說法。
是否已遭實際利用,目前沒有任何證據可以確認或排除。

可引用的一句話

當所有人都拿到同一把印章,蓋上去的章就證明不了任何事。

圖片

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

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

BotSharp 寫死的 JWT 簽章金鑰:沒換掉預設金鑰,攻擊者能偽造登入憑證,冒充已知使用者(CVE 紀錄稱包括管理員)

開源專案 BotSharp 在 5.2.0 以前(含)的 WebStarter 專案設定檔(appsettings.json)裡,直接放了一把用來簽發登入憑證的金鑰,而這把金鑰在公開程式庫裡人人看得到。如果部署時沒有換掉它,不需要帳號的遠端攻擊者就能自己簽出憑證,冒充已知使用者;CVE 紀錄稱包括管理員,但發現者的報告說未確立管理員權限,也沒有做執行期驗證。漏洞由 VulnCheck 於 2026 年 10 月 11 日公開,評為 CVSS 4.0 的 9.3 分;目前沒有已知的修補版本。

關鍵數字:
- 嚴重度:CVSS 4.0 9.3 / CVSS 3.1 9.1(VulnCheck)(https://cveawg.mitre.org/api/cve/CVE-2026-108860)
- 受影響版本:5.2.0 以前(含)(https://cveawg.mitre.org/api/cve/CVE-2026-108860)
- CVE 公開:2026-10-11(由 VulnCheck 指派)(https://cveawg.mitre.org/api/cve/CVE-2026-108860)
- 發現者:hieuPenguinnn(https://cveawg.mitre.org/api/cve/CVE-2026-108860)
- 修補版本:未知(第三方追蹤網站標示「未回報」)(https://hol.org/guard/security/cves/CVE-2026-108860-botsharp-through-520-authentication-bypass-via)

已確認:
- BotSharp WebStarter 的 appsettings.json 在官方程式庫中提交了 Jwt:Key,issuer 與 audience 固定為 botsharp。
- 截至 2026-10-12,未列入 CISA 已知遭利用漏洞清單。

尚未確認 / 說法不一:
- CVE 紀錄(CNA)寫:若未覆寫金鑰,不需認證的遠端攻擊者可冒充任何已知使用者(包括管理員),作用於 [Authorize] 保護的 API 路由;但它引用的發現者報告只做靜態分析,明說沒有確立管理員權限,也沒有做執行期驗證。
- 沒有已知的修補版本或官方安全公告;研究者指出最新 master 仍有同一把金鑰。
- 嚴重度說法不一:CNA 評為「嚴重」(9.1/9.3),研究者標示為「高,有條件」。
- 有新聞網站稱可導致「完全接管主機」,但 CVE 紀錄只描述 API 上的身分冒充,沒有主要來源支持此說法。
- 是否已遭實際利用,目前沒有任何證據可以確認或排除。

「當所有人都拿到同一把印章,蓋上去的章就證明不了任何事。」— PlainCVE
https://plaincve.date/vulns/cve-2026-108860-botsharp-hardcoded-jwt-key

如何引用本頁

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

PlainCVE 團隊(2026)。《BotSharp 寫死的 JWT 簽章金鑰:沒換掉預設金鑰,攻擊者能偽造登入憑證,冒充已知使用者(CVE 紀錄稱包括管理員)》。PlainCVE。https://plaincve.date/vulns/cve-2026-108860-botsharp-hardcoded-jwt-key(查閱日期:YYYY-MM-DD)

BibTeX

@misc{cve2026108860botsharphardcodedjwtkey2026,
  title  = {BotSharp 寫死的 JWT 簽章金鑰:沒換掉預設金鑰,攻擊者能偽造登入憑證,冒充已知使用者(CVE 紀錄稱包括管理員)},
  author = {PlainCVE 團隊},
  year   = {2026},
  howpublished = {PlainCVE},
  url    = {https://plaincve.date/vulns/cve-2026-108860-botsharp-hardcoded-jwt-key},
  note   = {更新於 2026-10-18}
}