Open WebUI 於二零二六年十月二十九日發布 v0.12.5，這個累積 157,392 顆星標的自架 AI 平台在版本說明中標示本次更新包含安全修補。同一專案在 GitHub 已累積 166 筆安全公告，其中 71 筆高風險、1 筆嚴重，159 筆集中於二零二六年。
Open WebUI v0.12.5 於十月二十九日發布，屬安全性質修補，官方建議所有部署盡快更新，並加入工作階段分析與 API 金鑰輪替。
Open WebUI 是什麼？
Open WebUI 是以 Python 撰寫的自架 AI 平台，以圖形介面連接 Ollama 與 OpenAI 相容 API，可完全離線運行，並內建知識庫。
依照專案自述，Open WebUI 定位為「AI 的家」，是一套可擴充、功能完整、對使用者友善，且能以完全離線方式運行的自架平台。它本身不是模型，而是模型之上的介面層，把本地推論引擎與雲端 API 收納在同一套操作環境，讓使用者在同一個介面切換模型、管理對話與指派工具。
專案建立於二零二三年十月六日，主要語言為 Python，採用帶品牌保留條款的 Open WebUI 授權，累積 892 位貢獻者與 674 位訂閱者。對個人使用者而言，它解決本地模型缺少對話歷史、檔案上傳與行動裝置支援的問題；對團隊而言，它解決帳號、群組、權限與用量統計的治理問題。
v0.12.5 更新了哪些功能與修補？
本次更新加入管理員工作階段分析面板、筆記分頁與即時協作顯示、管理員代為輪替使用者 API 金鑰，並將文件嵌入改為每批一千個分塊處理，知識庫指令速度提升最多十倍。
版本說明把安全修補放在修復章節首位，並以粗體聲明此次包含安全修正，強烈建議所有部署盡快更新，同時說明這些修正不會列在更新日誌中，會在 CVE 編號分配後另行公開公告。這種處理方式在開源專案中並不罕見，用意是避免在修補擴散之前公開可利用的細節。
功能面最受注目的變動是管理員分析中的工作階段瀏覽器。管理員可以逐筆檢視對話的權杖用量、回應數、錯誤與時間跨度，並依模型、權杖區間或子代理篩選，前提是管理員對話存取權限已開啟。同一版本亦為筆記加入多層分頁與即時線上狀態，並允許管理員在使用者編輯視窗中輪替或刪除 API 金鑰。
效能與維運層面則有三項實質改動。大型文件改為預設每批一千個分塊進行嵌入與儲存，可透過環境變數調整批次大小，降低處理超大檔案時的記憶體峰值。知識庫的列表、讀取與搜尋指令改為不預先載入全部檔案全文，在大型知識庫上每次呼叫最多快十倍。OpenTelemetry 指標則開始排除健康檢查與探測請求，避免監控數據被稀釋。
為何 166 個安全公告構成警訊？
專案累積 166 筆安全公告，含 1 筆嚴重、71 筆高風險、87 筆中風險，159 筆於二零二六年公開，反映攻擊面隨功能擴張而放大。
把公告數量直接當成品質指標並不公允。Open WebUI 的功能邊界遠超一般聊天介面，它同時處理檔案上傳、文件預覽、終端執行、外部工具伺服器與單一登入，每一個環節都是獨立的攻擊面。當一個專案在一年內推進十餘個版本、每版加入數十項功能，公告數量上升屬於結構性結果。
然而數字仍然值得拆開檢視。已公開的高風險公告中，多筆涉及工作階段權杖竊取，例如社群統計訊息處理器可讓任何網站取得已登入使用者的權杖，文件預覽中的腳本亦可讓已驗證使用者取得他人權杖。另一筆高風險公告指出終端代理的權限設計缺陷，讓終端使用者能管理其他使用者的終端與政策。嚴重級別的紀錄則是一筆 LDAP 空白密碼認證繞過，於二零二六年五月公開。
這些類型的共同點在於，它們大多需要已驗證身分才能觸發，並非未授權的遠端執行。對外開放註冊的實例風險最高，因為任何訪客都能取得觸發條件；僅限內部帳號的部署，風險則取決於內部帳號的可信程度。
自架 AI 平台的主要攻擊面在哪裡？
主要攻擊面包括工作階段權杖傳遞、文件預覽腳本、工具伺服器憑證、終端權限邊界與 OAuth 簽入流程設計。
第一條線是身分。自架平台往往同時支援本地帳號、OAuth 與 LDAP，任何一條路徑的邊界判斷出錯，都可能演變成登入繞過或權限提升。公告紀錄顯示，角色只存在於 ID 權杖、未同步到存取權杖時，已被撤銷的使用者仍可透過權杖交換持續登入，這類問題在混合身分環境中格外隱蔽。
第二條線是內容渲染。聊天訊息、引用連結、DOCX 預覽與筆記都可能承載主動內容，只要預覽流程允許腳本執行，就會從顯示問題升級為工作階段竊取。第三條線是執行環境。終端與程式碼解譯器讓模型能夠實際執行動作，同時也讓提示注入從文字層面的困擾變成可操作的風險。
第四條線是外連。工具伺服器、MCP 伺服器與網頁抓取功能都會讓伺服器主動發出請求，若缺乏目的地限制，就可能被導向內部服務。已公開的紀錄中包含以 DNS 重綁定繞過檢查、進而存取內部服務的案例，這類問題在雲端與地端混合部署中特別難以察覺。
企業應該如何降低自架部署的風險？
實務做法包括把容器映像固定在明確標籤、建立每月修補窗口、關閉未使用的終端與程式碼解譯器、限制對外註冊，以及定期輪替使用者 API 金鑰。
修補節奏是最直接的控制項。專案的版本發布相當密集，十月十四日至二十九日之間就推出五個版本，其中包含安全性質的更新。把容器映像固定在明確標籤而非浮動標籤，並建立每月一次的升級與回滾演練，比事後補救更有效。
功能縮減同樣重要。終端、程式碼解譯器、網頁抓取與外部工具伺服器都屬於高權限能力，未實際使用的團隊應在管理設定中關閉，而不是留在預設開啟狀態。管理員對話存取權限也應只授予必要人員，因為工作階段分析會讀取實際對話內容。
網路層面則建議把平台放在反向代理之後，限制工具伺服器可連線的目的地位址，並將資料庫與向量儲存排除在公開網段之外。同時啟用稽核與指標輸出，把登入失敗、權杖輪替與工具呼叫異常納入告警，才能在公告公開與實際修補之間的空窗期內及早察覺異常行為。
如何升級到 v0.12.5？
Docker 部署先備份資料卷，再拉取新映像重建容器；pip 或 uv 部署以升級指令更新套件，完成後確認版本與管理設定。
容器部署的標準流程是先備份 open-webui 資料卷，再拉取映像並重建容器。資料卷承載帳號、對話與知識庫，備份步驟不可省略，因為部分版本包含資料表結構調整。
docker pull ghcr.io/open-webui/open-webui:main
docker stop open-webui && docker rm open-webui
docker run -d -p 3000:8080 \
-v open-webui:/app/backend/data \
--name open-webui \
ghcr.io/open-webui/open-webui:main
以 Python 套件方式部署的環境，可執行 pip install --upgrade open-webui 完成更新，若使用 uv 則改用對應的升級指令。升級後應確認版本號、管理設定的可視控制項是否保留，並重新檢視終端與工具伺服器的連線狀態，因為此版本調整了終端啟動的等待時間與逾時設定。
Open WebUI 的專案數據與版本節奏如何？
截至二零二六年十一月，專案累積 157,392 顆星標、22,885 次分叉、892 位貢獻者，最新版本 v0.12.5 於十月二十九日發布。
- 157,392GitHub 星標
- 22,885分叉次數
- 892貢獻者
- 166安全公告
版本節奏方面，v0.12.1 與 v0.12.2 於十月十四日同日發布，v0.12.3 於十月十六日，v0.12.4 於十月二十五日，v0.12.5 於十月二十九日，十日內推出五個版本。這種密度對自架使用者是雙面刃，一方面修補能快速到位，另一方面也意味著升級驗證必須自動化，否則維運負擔會迅速累積。
出處連結有哪些？
原始碼與版本說明位於 GitHub 的 open-webui/open-webui 儲存庫，安全公告於該儲存庫安全頁面公開。
專案的原始碼、版本說明與問題追蹤集中於 GitHub 儲存庫，安全公告同樣在該儲存庫的安全頁面公開，每一筆都附有影響版本範圍與修補版本。文件站點提供安裝、功能設定與企業方案的完整說明，社群討論則以 Discord 為主要渠道。
出處：https://github.com/open-webui/open-webui
總結：Open WebUI 適合什麼團隊？
適合需要把模型與對話資料留在自有硬體、同時要求權限治理與稽核能力的團隊；若維運人力不足或不願建立固定修補流程，託管服務仍是風險較低的選擇。
Open WebUI 的價值在於把散落的推論引擎、知識庫與工具整合成可治理的單一入口，這是它能在三年內累積十五萬顆星標的根本原因。v0.12.5 的意義則在於提醒：這種整合度同時帶來更大的攻擊面，平台的安全水位取決於使用者的維運紀律，而非專案單方面的努力。
對已有明確資料落地需求、具備容器維運能力、並且願意把修補納入例行流程的團隊，這個專案仍是目前最完整的自架選項之一。對維運人力有限、或把平台直接暴露在公網的小型團隊，先評估託管方案，或至少關閉非必要的高權限功能，會是更務實的起步方式。
