Black Hat Europe 2025 | Token Injection: Crashing LLM Inference With Special Tokens
三句話摘要
研究人員揭示「Token 注入」攻擊手法，透過在輸入文字中嵌入特殊控制 Token，可讓 vLLM、TensorRT-LLM、Ollama 等主流 LLM 推理引擎直接崩潰。 --- 在 LLM 推理引擎中，特殊控制 Token 與用戶輸入沒有任何邊界隔離，任何人只需一條聊天訊息就能讓整個多租戶服務崩潰——這是比提示注入更底層、影響範圍更廣的基礎設施漏洞，而修復它的開關早就存在，只是沒人打開。 攻擊面在推理基礎設施，而非模型本身。 傳統 AI 安全研究聚焦於越獄和提示注入，本研究刻意向右移動，鎖定服務引擎層——因為該層採用多租戶架構，一個用戶崩潰即波及所有人。
重點整理
重點- 1
攻擊面在推理基礎設施，而非模型本身。 傳統 AI 安全研究聚焦於越獄和提示注入，本研究刻意向右移動，鎖定服務引擎層——因為該層採用多租戶架構，一個用戶崩潰即波及所有人。
- 2
特殊 Token 與用戶輸入共用同一資料流，邊界完全模糊。 分詞器一旦將輸入文字解析成特殊 Token ID，後端系統會無條件信任並執行對應的控制邏輯，這與 SQL 注入的根本原因完全相同。
- 3
崩潰機制跨越多個語言層。 以 TensorRT-LLM 為例，攻擊在 Python 層產生垃圾維度數值，流入 C++ 層造成狀態機損毀，最終在 CUDA 層觸發 GPU 設備端斷言錯誤，屬於不可恢復性崩潰。
- 4
防禦方案存在但未被採用。 Hugging Face Tokenizer 提供 `split_special_tokens` 參數，設為 `true` 即可阻斷攻擊，但因兼容性問題預設為 `false`，導致整個生態系統長期暴露在風險中。
- 5
--
實用技巧與重點
乾貨- 受測框架與結果：
- vLLM：注入 `<video_start>` + `<video_pad>` → HTTP 500，`IndexError: list index out of range`
- TensorRT-LLM（NVIDIA）：兩步攻擊，第一請求埋地雷，第二請求觸發 CUDA 設備端錯誤，GPU worker 終止，服務需重啟
- Ollama（Gemma 3）：注入 `<image_soft_token>` → 段錯誤（Segmentation Fault），OS 強制終止進程
- Silicon Flow、Med AI：注入特殊 Token 至聊天框，服務立即中斷
- NVIDIA NIM：HTTP 500，推理 worker 崩潰
- Google Vertex AI：返回「提交失敗」錯誤
- Open Router：注入後無回應輸出
- Microsoft Azure AI Foundry：輸出混亂，可觸發失敗
- 特殊 Token 分類（4 類）：
- 邊界類：如 `<end_of_text>`
- 上下文佔位類：mask 型空白標記
- 結構類：定義 user/system 角色
- 多模態類：圖像、視頻存放位置（數量最多，超過 1300 個，為主要攻擊面）
- Token 數量統計：
- DeepSeek、Meta LLaMA、Kimiko（Qwen 系列）等模型定義數百至數千個特殊 Token
- Kimiko 擁有最大量的特殊 Token（圖表中黃色長條最長）
- 修復方案：
- Hugging Face Tokenizer 參數：`split_special_tokens=True`
- 效果：將惡意 Token 拆成純文字，徹底阻斷攻擊
- 現狀：約 0% 的開源模型預設啟用
- 廠商回應：
- 已確認並修復：Real M、NVIDIA、Microsoft、Google
- 承認但稱為「Self-DoS」（不算漏洞）：Meta
- 已啟動修復但未認定為漏洞：MLX
- 未回覆：SD long / Llama（截至演講時）
- --
結論
結論“在 LLM 推理引擎中，特殊控制 Token 與用戶輸入沒有任何邊界隔離，任何人只需一條聊天訊息就能讓整個多租戶服務崩潰——這是比提示注入更底層、影響範圍更廣的基礎設施漏洞，而修復它的開關早就存在，只是沒人打開。”
完整解析
詳細現代 LLM 推理引擎（如 vLLM、TensorRT-LLM、Ollama）扮演的角色是使用者文字與 GPU 硬體之間的橋梁，且幾乎全部採用多租戶架構——單一實例同時服務數百名用戶。這個設計讓它們成為極具吸引力的攻擊目標：只要讓一個實例崩潰，所有用戶的服務都會中斷。然而在 AI 安全領域，絕大多數研究者的目光都停留在模型層的越獄與提示注入，沒有人認真審視推理基礎設施本身的健壯性。
來自華中科技大學的丁宏宇與蚂蚁集团的徐子桐發現了這個盲點，並提出「Token 注入」攻擊。其原理源自 LLM 的運作機制：每個模型在 `tokenizer_config.json` 中都定義了數量不等的「特殊 Token」，這些 Token 不是普通文字，而是控制指令——告訴模型何時停止、如何切換角色、如何處理圖像或視頻。關鍵問題在於，這些特殊 Token 與用戶輸入的普通文字共用同一條資料流，分詞器在將文字轉換成數字 ID 時，無法區分「用戶真的上傳了圖像」還是「用戶只是在文字裡打了一個圖像 Token」。一旦分詞器產出了對應的 Token ID，後端系統就會無條件信任並執行對應邏輯。
攻擊者只需要在 HTTP 請求的文字欄位中插入特殊 Token 的字串（如 `<video_start>`），不需要任何圖像或視頻檔案。以 vLLM 為例，引擎收到 `video_start` Token 後，認定有視頻存在，嘗試從元數據列表讀取視頻大小，卻撞上空列表，直接拋出 `IndexError`，服務崩潰。TensorRT-LLM 的情況更複雜：第一個惡意請求讓 Python 層計算出垃圾維度數值，這些數值流入 C++ 層破壞狀態機，再流入 CUDA 層，讓 GPU 嘗試對形狀無效的矩陣執行乘法，最終觸發設備端斷言錯誤——這是 GPU 硬體層的不可恢復性崩潰，服務必須重啟。Ollama 則因為 Go、CGo 與 C 引擎三層之間的錯誤傳播，最終觸發段錯誤，由作業系統強制終止進程。
研究團隊進一步在真實雲端平台上驗證，Silicon Flow、NVIDIA NIM、Google Vertex AI、Open Router、Microsoft Azure AI Foundry 均出現不同程度的服務中斷或錯誤回應。他們還設計了黑盒模糊測試器，嘗試探索跨用戶資料洩漏與推理操縱的可能性，雖然在純黑盒條件下未能成功，但研究者認為更深入的白盒研究有機會觸發這類攻擊。解法其實早已存在——Hugging Face Tokenizer 的 `split_special_tokens=True` 參數可以完全阻斷此類攻擊，但因為設為 `true` 會破壞許多現有推理引擎的啟動兼容性，幾乎所有開源模型都維持預設的 `false`。
---
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
