CVE-2025-27840 解析：ESP32 藍牙韌體裡的 29 個隱藏 HCI 指令，是後門嗎？

2025 年 3 月，「十億台裝置使用的藍牙晶片被發現後門」的標題傳遍資安圈。主角是我們很熟悉的 ESP32。後來事情的發展比標題複雜得多：研究者自己把「後門」改口為「隱藏功能」，Espressif 則說明這些是除錯用指令，在一般用法下不會被遠端觸發。

這篇整理事件經過，並從技術角度回答開發者真正關心的問題：我的產品有沒有受影響？要怎麼處理？

事件經過

先搞懂 HCI

藍牙的軟體架構分成兩層：

• Host（主機端）：處理高階協定，例如 GATT、配對流程。ESP-IDF 裡的 Bluedroid、NimBLE 就是 Host
• Controller（控制器）：處理射頻、連線層等底層工作，通常是晶片廠商提供的韌體

兩者之間透過 HCI（Host Controller Interface） 溝通。Host 送出 HCI 指令，Controller 回傳 HCI 事件。一個 HCI 指令封包的格式是：

封包類型 0x01 | Opcode（2 bytes，little-endian）| 參數長度（1 byte）| 參數...

Opcode 由兩個部分組成：6 bits 的 OGF（指令群組）和 10 bits 的 OCF（群組內的指令編號）。藍牙規格把 OGF = 0x3F 保留給廠商自訂指令（vendor-specific commands），所以這類指令的 opcode 都落在 0xFC00 開頭：

def hci_opcode(ogf: int, ocf: int) -> int:
    return (ogf << 10) | ocf

hex(hci_opcode(0x3F, 0x01))  # '0xfc01'

廠商自訂 HCI 指令本身很常見。晶片廠用它來做韌體更新、讀取晶片溫度、產線測試等。問題在於這次找到的指令能做什麼，以及它們沒有被記錄在文件中。

這 29 個指令能做什麼

Tarlogic 透過逆向分析 ESP32 SDK 中公開的 ROM 二進位檔，找到 opcode 從 0xFC01 到 0xFC44 共 29 個指令。依功能大致可以分成幾類：

Tarlogic 列出了幾種可能的濫用情境：

• 偽造 MAC 位址：冒充其他裝置、繞過裝置追蹤
• 讀取記憶體：取出 Wi-Fi 密碼、藍牙配對金鑰等機密
• 寫入記憶體：在 ESP32 上執行程式碼、注入金鑰繞過驗證
• 常駐：把程式碼寫進 Flash，重開機後仍然存在。不過 Tarlogic 也提到，啟用 Secure Boot v2 會讓這件事困難許多

看到這張表，會覺得「後門」這個詞並不誇張。但關鍵問題是：誰能送出這些指令？

關鍵在威脅模型：誰能送出 HCI 指令

這些指令無法透過藍牙無線電、Wi-Fi 或網路從遠端觸發。要送出 HCI 指令，必須能存取 Host 和 Controller 之間的 HCI 介面。ESP32 的藍牙有兩種運作方式，風險完全不同：

一般用法：Host 與 Controller 在同一顆晶片上

絕大多數 ESP32 產品，包括所有用 Arduino 或 ESP-IDF 直接寫藍牙應用的專案，都是這種架構：

┌─────────────── ESP32 ───────────────┐
│  你的應用程式                         │
│      │                              │
│  Host（Bluedroid / NimBLE）          │
│      │  VHCI（晶片內部的虛擬 HCI）     │
│  Controller（藍牙韌體）               │
└─────────────────────────────────────┘

HCI 只是晶片內部的函式呼叫。能送出這些指令的程式碼，本來就是在 ESP32 上執行的韌體，它原本就能直接讀寫記憶體和 Flash。所以這些除錯指令並沒有增加新的攻擊面。攻擊者如果已經能在你的 ESP32 上執行程式碼，用不用這些指令都沒有差別。

有風險的用法：UART-HCI（Hosted 模式）

另一種較少見的架構，是把 ESP32 當成外接的藍牙模組，由另一顆處理器或電腦擔任 Host：

┌──── 外部主機 ────┐     UART / USB     ┌──── ESP32 ────┐
│  應用程式 + Host  │ ─── HCI 指令 ────▶ │  Controller   │
└─────────────────┘                    └───────────────┘

這時 ESP32 會完全信任從序列埠收到的所有 HCI 指令。攻擊者只要能控制外部主機，或者實體接觸到序列埠，就能用這些指令讀寫 ESP32 的記憶體與 Flash、修改 MAC 位址。

因此，Espressif 和多位資安專家都把它定位成第二階段的攻擊手法：攻擊者必須先取得主機或實體存取權，才用得到這些指令，它本身不構成一個獨立的漏洞。

爭議：後門、隱藏功能，還是正常的除錯介面？

事件中各方的立場：

• Tarlogic：最初稱為「後門」，在外界批評研究被過度渲染後，改稱「隱藏功能」比較恰當
• Espressif：這些是為了測試而放進藍牙控制器 IP 的除錯指令，本身不會對 ESP32 造成安全風險
• Xeno Kovah（Dark Mentor，藍牙資安研究者）：廠商自訂 HCI 指令是藍牙規格中很正常的設計；但他也直言，能夠讀寫記憶體是不好的安全設計，是不是漏洞要看使用情境

我們的看法比較接近 Kovah：稱為後門確實言過其實，但把強大的除錯功能留在量產韌體裡、而且沒有寫進文件，本身就是值得改進的做法。 開發者無法防範自己不知道的功能。

誰受影響？

• 只有初代 ESP32：ESP32-C、ESP32-S、ESP32-H 系列的藍牙控制器不支援這些指令，不受影響
• 一般單晶片應用：Host 與 Controller 都在 ESP32 上的產品，沒有實質影響
• UART-HCI / Hosted 模式：把 ESP32 當成外接藍牙控制器的產品，應該更新

確認專案用的是哪種模式，可以執行 idf.py menuconfig，在 Bluetooth controller 的設定裡查看 HCI 模式是 VHCI（晶片內部）還是 UART（H4）。

修補方式

Espressif 在安全公告 AR2025-004 中做了三件事：

1. 停用除錯用的 vendor HCI 指令介面
2. 新增 API 控制是否加入 Espressif 自己的 vendor HCI 指令，在序列埠 HCI 的使用情境下預設關閉
3. 補上 vendor HCI 指令與初始化 API 的文件

已修補的 ESP-IDF 版本：

給開發者的建議

不管有沒有直接受影響，這次事件都提醒了幾件 IoT 產品該做的事：

1. 更新 ESP-IDF：至少升級到上表的修補版本。Arduino-ESP32 的使用者，請確認所用版本對應的 ESP-IDF 是否已包含修補
2. 啟用 Secure Boot v2 與 Flash 加密：這是 Tarlogic 自己也提到、能大幅提高常駐攻擊難度的防線，也能防止 Flash 內容被直接讀出
3. 不要把 HCI 介面暴露在產品外部：量產產品不應該留著可以直接存取的 UART 除錯接點
4. 用 Hosted 模式時，把外部主機也納入威脅模型：ESP32 會無條件信任主機送來的指令，主機的安全性就等於藍牙模組的安全性

小結

CVE-2025-27840 是一個「標題比實際風險大」的典型案例。對大多數 ESP32 專案來說，這些指令並沒有開出新的攻擊路徑。但它也確實揭露了一個值得重視的問題：量產晶片裡藏著沒有文件記載、能讀寫記憶體的強大功能。

看資安新聞時，最重要的問題永遠是：攻擊者需要先具備什麼條件？ 把這個問題想清楚，才能判斷一個漏洞對自己的產品到底有多大的影響。

資料來源

• Tarlogic：ESP32 hidden HCI vendor commands, technical details and use cases（2025-03-20）
• Espressif Developer Portal：ESP32 Bluetooth: Clearing the Air（2025-03-10）
• Espressif：AR2025-004 Security Advisory Follow-Up: Updates and Fixes Regarding ESP32 Undocumented Bluetooth Commands（2025-05-22）
• INCIBE-CERT：Tarlogic discovers undocumented HCI commands in Espressif's ESP32 module（2025-03-21）
• GovInfoSecurity：Downgraded Alert Over IoT Wireless Chip 'Backdoor'（2025-03-10）
• BleepingComputer：Undocumented commands found in Bluetooth chip used by a billion devices