plaincve:~$

// 威脅簡報

CVE-2026-61742

DBHub HTTP 模式 DNS rebinding:惡意網頁可透過瀏覽器在你的資料庫執行 SQL

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

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

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

DBHub 以 HTTP 模式執行時不需登入,來源檢查又能被 DNS rebinding 繞過,惡意網頁可借受害者的瀏覽器執行 SQL。

誰會中使用 @bytebase/dbhub 0.22.4 以前(0.22.5 之前)、並以 HTTP 傳輸模式(--transport http 或環境變數 TRANSPORT=http)啟動的使用者或組織。預設的 stdio 模式不受這個瀏覽器攻擊途徑影響。
後果受害者開啟攻擊者控制的網頁,且其電腦連得到 DBHub HTTP 伺服器、攻擊者能把自己的網域重新指向該伺服器時,對方就能透過受害者的瀏覽器呼叫 DBHub 的 MCP 工具:讀取、列舉資料庫內容,依工具權限與資料庫帳號權限,還可能寫入資料。
現在該做什麼升級到 0.22.5 以上。受影響的版本沒有可以擋下這個攻擊的設定選項;還不能升級時,改用不受影響的 stdio 模式,不要以 HTTP 模式執行。
受影響版本0.22.4 以前的版本(維護者公告列 <= 0.22.4,CVE 紀錄列 < 0.22.5,兩者相同);公告實際測試的是 0.21.2
修好的版本0.22.5 以上(維護者公告與 CVE 紀錄)
CVSS 向量
顯示完整向量CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
時間點
  • 首次公開 2026-06-24

藍隊應對手冊

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

DETECT確認我受影響嗎?有沒有入侵跡象?
  1. 01確認版本

    @bytebase/dbhub 版本低於 0.22.5(即 0.22.4 以前)就在維護者公告與 CVE 紀錄所列的受影響範圍內。

    唯讀查詢
    npm ls @bytebase/dbhub
  2. 02確認是否以 HTTP 模式執行

    只有 HTTP 傳輸模式受這個攻擊途徑影響;預設的 stdio 模式不受影響。官方文件指出傳輸模式除了 --transport 參數,也能用環境變數 TRANSPORT 或 .env 檔設定,所以這個指令同時找命令列參數與程序環境變數。限制:只看得到你有權限讀取的程序環境(別的使用者或容器內的程序可能看不到),也讀不到 .env 檔;沒有輸出不代表沒用 HTTP 模式,請再檢查 DBHub 的 .env 檔、docker compose 或服務設定裡的 TRANSPORT。也檢查綁定位址:預設 0.0.0.0 會開在所有網路介面上。

    唯讀查詢
    ps axeww | grep -i '[d]bhub' | grep -oE -- '--transport[= ]+[a-z]+|TRANSPORT=[a-z]+'
    步驟 1
  3. 03檢查資料庫是否有不明操作

    我們查閱的來源中未見偵測指引。PlainCVE 建議:檢視 DBHub 所用資料庫帳號的查詢與異動紀錄,找出不是你或你的 AI 工具發出的操作。

    步驟 5
MITIGATE修補 / 緩解先修補;還不能修補時先擋住
  1. 01升級到 0.22.5 以上

    維護者公告與 CVE 紀錄都列 0.22.5 為修補版本。這個指令會變更專案的相依套件;全域安裝的改用 npm install -g,以 npx 啟動的請在套件名稱後指定版本(例如 @bytebase/dbhub@latest)。

    會變更環境
    npm install @bytebase/dbhub@latest
    步驟 4
  2. 02確認本機安裝的版本

    列出專案內與全域安裝的 @bytebase/dbhub 版本,確認都是 0.22.5 以上。沒有安裝時,npm 會印出專案(或全域)路徑與「└── (empty)」,並以非 0 的結束代碼結束。

    唯讀查詢
    npm ls @bytebase/dbhub; npm ls -g @bytebase/dbhub
    步驟 4
  3. 03升級後:維持主機允許清單,再加上 token 認證

    受影響的版本沒有這兩個選項:--allowed-hosts 是修補 PR

    步驟 1步驟 3
  4. 04還不能升級:改用 stdio 模式

    受影響的版本沒有可以擋下這個攻擊的設定選項。官方公告指出 stdio 模式不受這個瀏覽器攻擊途徑影響,所以升級前不要以 HTTP 模式執行。只限制哪些網路連得到它不夠,因為 DNS rebinding 是從可信網路內受害者自己的瀏覽器發動(PlainCVE 的判斷)。

    步驟 1步驟 2
RESPOND應變發現入侵跡象時
  1. 01輪替資料庫憑證並檢查資料

    PlainCVE 建議:若發現可疑操作,輪替 DBHub 使用的資料庫帳密,並檢查資料是否遭竄改。這是預防性建議,我們查閱的來源中未見事件回應指引。

    步驟 5
HARDEN強化長期避免同類問題
  1. 01資料庫帳號最小權限

    官方公告指出影響程度取決於工具權限與資料庫帳號;接正式環境或高權限帳號時嚴重度可能升為 Critical。

    步驟 5
  2. 02不要把本機開發工具開在所有網路介面

    PlainCVE 的判斷:限縮綁定位址能減少可連到的人,但 DNS rebinding 是借受害者自己的瀏覽器發動,光改綁定位址不夠,仍需主機允許清單(0.22.5 起)與 token(1.2.0 起)。

    步驟 1步驟 3
完整修復步驟與說明
  1. 升級: npm install @bytebase/dbhub@latest(或 npx 啟動時指定新版),確認版本 ≥ 0.22.5(維護者公告與 CVE 紀錄列的修補版本)。
  2. 還不能升級: 受影響的版本沒有能擋下這個攻擊的設定選項。--allowed-hosts 是修補 PR #340 才新增的,--auth-token 更晚,由 PR #390 加入、1.2.0 起才有。升級前請改用 stdio 模式(官方公告:不受這個攻擊途徑影響),不要以 HTTP 模式執行。
  3. 升級後的 HTTP 模式設定(依官方文件): 新版預設只允許本機與這台機器自己的主機名稱和 IP;透過反向代理或自訂網域連線時,用 --allowed-hosts 只加上你實際使用的名稱,不要設成 "*",那會關閉 DNS rebinding 防護。升到 1.2.0 以上後再設定 --auth-token,它預設是關閉的。
  4. 注意: 只把綁定位址改成本機、或只讓可信任的網路連到它,都不足以防 DNS rebinding,因為攻擊是從網路內受害者自己的瀏覽器發出的(PlainCVE 的判斷)。

攻擊流程

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

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

DBHub HTTP 模式 DNS rebinding:惡意網頁可透過瀏覽器在你的資料庫執行 SQL: 1. DBHub 以 HTTP 模式執行,沒有任何認證 → 2. 誘使受害者開啟攻擊者控制的網頁 → 3. 把自己的網域名稱「重新指向」DBHub 伺服器 → 4. 來源檢查誤判為可信任 → 5. 透過受害者瀏覽器呼叫 MCP 工具、執行 SQLCVE-2026-61742 · DBHub HTTP 模式 DNS rebinding:惡意網頁可透過瀏覽器在你的資料庫執行 SQL攻擊者你的系統DBHub 以 HTTP 模式執行,沒有任何認證 — 以 --transport http 啟動時,/mcp 端點不需要任何 token 或密鑰就接受工具呼叫。官方文件指出預設綁定位址 0.0.0.0 會開在所有網路介面上。 1DBHub 以 HTTP 模式執行,沒有任何認證誘使受害者開啟攻擊者控制的網頁 — 受害者的電腦必須連得到 DBHub 的 HTTP 伺服器。 2誘使受害者開啟攻擊者控制的網頁把自己的網域名稱「重新指向」DBHub 伺服器 — 這就是 DNS rebinding:瀏覽器仍以為在跟攻擊者的網站溝通,實際上請求已送到 DBHub。 3把自己的網域名稱「重新指向」DBHub 伺服器來源檢查誤判為可信任 — 舊版只比對 Origin 與 Host 兩個標頭的主機名稱是否相同,沒有比對允許清單;重新指向後兩者都是攻擊者的網域,自然相同。 4來源檢查誤判為可信任透過受害者瀏覽器呼叫 MCP 工具、執行 SQL — 不需要提示詞注入或 AI 模型參與。示範設定下可讀寫示範用 SQLite;接上真實資料庫時可讀取、列舉,並可能寫入資料,視工具權限與資料庫帳號而定。 5透過受害者瀏覽器呼叫MCP 工具、執行 SQL攻擊路徑可在此擋下PlainCVE · plaincve.date/vulns/cve-2026-61742-dbhub-mcp-dns-rebinding · CC BY 4.0
DBHub HTTP 模式 DNS rebinding:惡意網頁可透過瀏覽器在你的資料庫執行 SQL: 1. DBHub 以 HTTP 模式執行,沒有任何認證 → 2. 誘使受害者開啟攻擊者控制的網頁 → 3. 把自己的網域名稱「重新指向」DBHub 伺服器 → 4. 來源檢查誤判為可信任 → 5. 透過受害者瀏覽器呼叫 MCP 工具、執行 SQLCVE-2026-61742 · DBHub HTTP 模式 DNSrebinding:惡意網頁可透過瀏覽器在你的資料庫執行 SQLDBHub 以 HTTP 模式執行,沒有任何認證 — 以 --transport http 啟動時,/mcp 端點不需要任何 token 或密鑰就接受工具呼叫。官方文件指出預設綁定位址 0.0.0.0 會開在所有網路介面上。 1你的系統DBHub 以 HTTP 模式執行,沒有任何認證誘使受害者開啟攻擊者控制的網頁 — 受害者的電腦必須連得到 DBHub 的 HTTP 伺服器。 2攻擊者誘使受害者開啟攻擊者控制的網頁把自己的網域名稱「重新指向」DBHub 伺服器 — 這就是 DNS rebinding:瀏覽器仍以為在跟攻擊者的網站溝通,實際上請求已送到 DBHub。 3攻擊者把自己的網域名稱「重新指向」DBHub伺服器來源檢查誤判為可信任 — 舊版只比對 Origin 與 Host 兩個標頭的主機名稱是否相同,沒有比對允許清單;重新指向後兩者都是攻擊者的網域,自然相同。 4你的系統來源檢查誤判為可信任透過受害者瀏覽器呼叫 MCP 工具、執行 SQL — 不需要提示詞注入或 AI 模型參與。示範設定下可讀寫示範用 SQLite;接上真實資料庫時可讀取、列舉,並可能寫入資料,視工具權限與資料庫帳號而定。 5攻擊者透過受害者瀏覽器呼叫 MCP 工具、執行SQL攻擊路徑可在此擋下PlainCVE · CC BY 4.0plaincve.date/vulns/cve-2026-61742-dbhub-mcp-dns-rebinding
圖片可自由用於報導與教學,採 CC BY 4.0,圖上已附出處。
  1. 你的系統

    DBHub 以 HTTP 模式執行,沒有任何認證

    以 --transport http 啟動時,/mcp 端點不需要任何 token 或密鑰就接受工具呼叫。官方文件指出預設綁定位址 0.0.0.0 會開在所有網路介面上。

    防禦: 不需要時改用預設的 stdio 模式;需要 HTTP 時升級到 1.2.0 以上並設定 --auth-token(這個選項從 1.2.0 才有)。

  2. 攻擊者

    誘使受害者開啟攻擊者控制的網頁

    受害者的電腦必須連得到 DBHub 的 HTTP 伺服器。

  3. 攻擊者

    把自己的網域名稱「重新指向」DBHub 伺服器

    這就是 DNS rebinding:瀏覽器仍以為在跟攻擊者的網站溝通,實際上請求已送到 DBHub。

    防禦: 升級到 0.22.5 以上:新版會檢查 Host 是否在允許清單上,不在清單上的請求會被 403 拒絕;要加其他主機名稱用 --allowed-hosts(不要設成「*」)。

  4. 你的系統

    來源檢查誤判為可信任

    舊版只比對 Origin 與 Host 兩個標頭的主機名稱是否相同,沒有比對允許清單;重新指向後兩者都是攻擊者的網域,自然相同。

    防禦: 升級到 0.22.5 以上(維護者公告與 CVE 紀錄列的修補版本)。依修補 PR

  5. 攻擊者

    透過受害者瀏覽器呼叫 MCP 工具、執行 SQL

    不需要提示詞注入或 AI 模型參與。示範設定下可讀寫示範用 SQLite;接上真實資料庫時可讀取、列舉,並可能寫入資料,視工具權限與資料庫帳號而定。

    防禦: 給 DBHub 使用的資料庫帳號最小權限,例如唯讀。

影響範圍

DBHub 是 Bytebase 開發的資料庫 MCP 伺服器(MCP 是讓 AI 助理呼叫外部工具的協定),支援 Postgres、MySQL、SQL Server、Oracle、MariaDB 與 SQLite,npm 套件名稱為 @bytebase/dbhub。

條件是否受影響
0.22.4 以前 + 以 HTTP 模式(--transport http 或環境變數 TRANSPORT=http)執行受影響(維護者公告、CVE 紀錄)
0.22.5 以上已修補(維護者公告、CVE 紀錄)
以預設的 stdio 模式執行官方公告:不受這個瀏覽器攻擊途徑影響

維護者公告列出的受影響範圍是 0.22.4 以前、修補版本 0.22.5,與 CVE 紀錄的「0.22.5 之前」相同;公告內實際測試的版本是 0.21.2。

攻擊要成立,還需要:受害者開啟攻擊者控制的網頁、受害者的電腦連得到 DBHub 的 HTTP 伺服器,以及攻擊者控制一個可以重新指向該伺服器的網域名稱。官方文件也提醒,HTTP 模式預設綁定 0.0.0.0,會開在所有網路介面上。

原理

這個漏洞有兩個缺口疊在一起:

  1. 沒有認證(CWE-306)。 在測試版本中,HTTP 模式的 /mcp 端點不需要任何 token(存取用的通行碼)、密鑰或類似 CSRF 防護的憑證,就接受工具呼叫。
  2. 來源檢查不夠嚴(CWE-346)。 伺服器想阻擋來自其他網站的瀏覽器請求,但它只確認 Origin(請求從哪個網站來)和 Host(要送到哪個主機)兩個標頭的主機名稱「相同」,沒有比對一份明確的允許清單。

DNS rebinding 正好利用第二點:攻擊者先讓受害者開啟自己的網頁,再把自己的網域改指向 DBHub 伺服器。這時瀏覽器送出的請求,Origin 和 Host 都是攻擊者的網域,兩者相同,於是被當成可信任。官方公告指出,惡意網站因此能穩定地從受害者瀏覽器呼叫 DBHub 的 MCP 工具,不需要提示詞注入,也不需要 AI 模型參與。

影響:示範設定下可讀寫示範用的 SQLite 資料庫;接上真實資料庫時,可讀取、列舉內容,並可能寫入,視 DBHub 的工具權限與資料庫帳號而定。沒有任何來源宣稱能在作業系統上執行程式碼(PlainCVE 的判斷:已知影響是透過 DBHub 執行 SQL 與 MCP 工具)。

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

展開程式碼範例(js)
// 只檢查兩個標頭是否一致
if (hostname(req.headers.origin) === hostname(req.headers.host)) {
  allow(); // DNS rebinding 後兩者都是攻擊者網域,仍然相同
}

較安全的思路(概念示意):

展開程式碼範例(js)
// 主機必須在明確的允許清單上,且需要有效 token
if (allowedHosts.includes(hostname(req.headers.host)) && validToken(req)) {
  allow();
} else {
  reject(403);
}

實際修補是 2026-06-24 合併的 PR #340。依它的 commit 說明,新版不再只比對兩個標頭是否相同,而是每個請求都要求 Host(以及有帶的 Origin)在明確的主機允許清單上,清單預設包含本機位址。上面的「較安全思路」只是說明原則;PR #340 說明 token 認證不在這次修補範圍內,另由 issue #66 追蹤,後來由 PR #390 加入 --auth-token,1.2.0 起提供。

時間軸

日期事件
2026-06-24 03:23 UTC修補 PR #340 在公開 repo 開啟,說明寫出漏洞成因並列出公告編號 GHSA-fm8p-53ww-hf6w
2026-06-24 04:04 UTC修補 PR #340 合併
2026-06-24 04:22 UTC0.22.5 上架 npm
2026-06-24 04:25 UTC維護者在 GitHub 公開安全公告 GHSA-fm8p-53ww-hf6w
2026-07-10CVE 編號保留
2026-07-31PR #390 合併(新增 --auth-token,關閉 issue #66),同日 1.2.0 上架
2026-09-24 17:30 UTCCVE 紀錄公開
2026-09-24NVD 收錄,狀態為「Received」(尚未分析)
2026-09-24 19:36 UTCGitHub 審核過的公告出現在 OSV
2026-09-25仍未列入 CISA KEV

依 npm registry 與 GitHub 公告的時間紀錄,0.22.5 上架約 3 分鐘後,維護者就公開了安全公告;CVE 紀錄則到 2026-09-24 才公開,比公告晚了三個月。

延伸閱讀

  • 評分差異: CNA(GitHub)的 CVSS 4.0 為 9.3,GitLab 的 CVSS 3.1 為 9.8,官方公告則建議 High,接上正式環境或高權限帳號時可能為 Critical;TheHackerWire 標為「Info」,與其他來源都不一致。NVD 尚未分析。
  • 使用者互動: CVSS 向量寫的是不需使用者互動(UI:N),但公告描述的攻擊情境仍需受害者開啟攻擊者網頁。PlainCVE 認為 UI:N 值得商榷。
  • PoC 說法不一: 官方公告附有可重現的 PoC,CISA 的 SSVC 資料也標為「poc」(並標為可自動化、技術影響「total」);TheHackerWire 卻說尚無確認的公開利用程式。
  • 利用狀況: 截至 2026-09-25 未列入 CISA KEV;沒有來源回報實際遭利用,也沒有證據顯示是零時差攻擊。
  • 何時引入有問題的程式碼,來源沒有說明。
  • 相關弱點類型:CWE-306、CWE-346。

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

AI 審稿2026-09-30 · 審稿規則

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

來源

  1. 安全公告GHSA-fm8p-53ww-hf6w — DBHub HTTP transport DNS rebinding allows unauthenticated browser-origin SQL execution · Bytebase (GitHub), 2026-06-24 · 查閱 2026-09-28
  2. CVE / NVD / OSVCVE-2026-61742 Record · CVE Program, 2026-09-24 · 查閱 2026-09-25
  3. CVE / NVD / OSVNVD - CVE-2026-61742 · NIST, 2026-09-24 · 查閱 2026-09-25
  4. 安全公告GitLab Advisory Database: CVE-2026-61742 in @bytebase/dbhub · GitLab · 查閱 2026-09-25
  5. 安全公告OSV: GHSA-fm8p-53ww-hf6w · OSV, 2026-09-24 · 查閱 2026-09-25
  6. 廠商說明DBHub command-line configuration · Bytebase · 查閱 2026-09-28
  7. 修補 commit / 版本PR #340: fix: enforce Host allow-list on HTTP transport to block DNS rebinding · Bytebase (GitHub), 2026-06-24 · 查閱 2026-09-28
  8. 修補 commit / 版本PR #390: feat(server): add bearer token auth for HTTP transport · Bytebase (GitHub), 2026-07-31 · 查閱 2026-09-28
    新增 --auth-token;說明寫 Fixes
  9. 廠商說明DBHub v1.2.0 release notes · Bytebase (GitHub), 2026-07-31 · 查閱 2026-09-28
    列出 PR
  10. 其他@bytebase/dbhub npm registry metadata · npm · 查閱 2026-09-28
    各版本上架時間(time 欄位)
  11. 研究文章CVE-2026-61742: Missing Authentication for Critical Function in bytebase dbhub · OffSeq · 查閱 2026-09-25
  12. 新聞報導CVE-2026-61742 · TheHackerWire · 查閱 2026-09-25

媒體簡報

一句話

DBHub 是 Bytebase 開發的開源工具,讓 AI 助理透過 MCP 協定存取 Postgres、MySQL 等資料庫。它的 HTTP 模式沒有認證,來源檢查又能被 DNS rebinding 手法繞過;在特定條件下(受害者電腦連得到 DBHub HTTP 伺服器、攻擊者控制可重新指向的網域),使用者開啟惡意網頁後,攻擊者就能借其瀏覽器在資料庫上執行 SQL。維護者公告與 CVE 紀錄都指出 0.22.5 已修補;目前沒有來源回報實際遭利用。

關鍵數字

嚴重度(CNA)
CVSS 4.0 9.3(Critical) cveawg.mitre.org
嚴重度(GitLab)
CVSS 3.1 9.8 advisories.gitlab.com
官方建議嚴重度
High,接正式或高權限帳號時可能為 Critical github.com
修補版本
0.22.5 github.com
維護者公告公開
2026-06-24 github.com
CVE 公開
2026-09-24 cveawg.mitre.org

已確認

  • DBHub HTTP 模式的 /mcp 端點不需認證,且來源檢查只比對 Origin 與 Host 是否相同,可被 DNS rebinding 繞過。
  • 預設的 stdio 模式不受這個瀏覽器攻擊途徑影響。
  • 截至 2026-09-25,未列入 CISA 已知遭利用漏洞清單。

尚未確認 / 說法不一

  • 嚴重度說法不一:CNA 9.3、GitLab 9.8、官方公告建議 High,TheHackerWire 則標為 Info。
  • 是否有公開 PoC 說法不一:官方公告附有 PoC,CISA 資料標為 poc;TheHackerWire 稱尚無確認的公開利用程式。
  • 沒有來源回報實際遭利用,也沒有證據顯示曾是零時差攻擊。

可引用的一句話

這個漏洞不用駭進伺服器,只要讓你的瀏覽器替攻擊者去敲資料庫的門。

圖片

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

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

如何引用本頁

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

PlainCVE 團隊(2026)。《DBHub HTTP 模式 DNS rebinding:惡意網頁可透過瀏覽器在你的資料庫執行 SQL》。PlainCVE。https://plaincve.date/vulns/cve-2026-61742-dbhub-mcp-dns-rebinding(查閱日期:YYYY-MM-DD)
BibTeX
@misc{cve202661742dbhubmcpdnsrebinding2026,
  title  = {DBHub HTTP 模式 DNS rebinding:惡意網頁可透過瀏覽器在你的資料庫執行 SQL},
  author = {PlainCVE 團隊},
  year   = {2026},
  howpublished = {PlainCVE},
  url    = {https://plaincve.date/vulns/cve-2026-61742-dbhub-mcp-dns-rebinding},
  note   = {更新於 2026-09-30}
}