觀點 · 資訊分享

Apache Solr 啟用 BasicAuth 時偷偷多建 4 個公開預設帳號：CVE-2026-44825 該怎麼查

用 bin/solr auth enable 開啟 Solr 登入驗證時，除了你指定的帳號，還會悄悄建立 4 個有公開預設密碼的帳號，攻擊者可取得管理權限。Apache 5 月 29 日公告，NVD 在 6 月 1 日收錄 CVE-2026-44825。

一句話看懂：用 Solr 的指令啟用登入驗證時，系統會偷偷多建 4 個有公開預設密碼的帳號，知道密碼的人就能拿到管理權限；官方給了不用升級的緩解方式。

Solr 驗證多出預設帳號資訊圖卡：啟用登入驗證卻悄悄多建 4 個預設帳號，可取得管理權限

先用白話講：預設帳號為什麼危險？

想像你換了一把新門鎖，師傅幫你設好你自己的密碼，卻順手多留了四組「出廠預設密碼」，而且這四組密碼印在產品說明書上，全世界都查得到。你以為門鎖只有你能開，其實每個人都能。

這次 Apache Solr 的狀況就是這樣：你開啟登入驗證，系統卻在背後多建立了預設帳號。

漏洞編號：CVE-2026-44825
影響版本：Apache Solr 9.4.0 至 9.10.1，以及 10.0.0
成因：用 bin/solr auth enable 啟用 BasicAuth 時，除了你指定的帳號，還會悄悄安裝帶有公開預設密碼的範本帳號：superadmin、admin、search、index
後果：遠端攻擊者可用這些公開的預設認證，取得整個叢集的完整管理權限
時間：Apache 在 5 月 29 日於 oss-security 公告，NVD 在 6 月 1 日收錄；NVD 評 9.8，Apache 自己評 8.1

情況	是否受影響
用 `bin/solr auth enable` 啟用，且沒改過範本帳號密碼	受影響
用該指令啟用，但已為範本帳號設強密碼	不受影響
沒有用該指令啟用 BasicAuth	不受影響

接案時常遇到客戶的內部搜尋引擎或商品搜尋用 Solr，而且常常是好幾年前別人架好的。這種系統最怕的就是「當初怎麼開驗證的，沒人記得」。

最快的檢查方式是打開 security.json，看有沒有這四個帳號，還有它們的密碼是不是還沒改。這個動作只要幾分鐘，不需要升級也不用重啟整套流程，卻能堵住最大的洞。順便也檢查一下 Solr 的管理介面有沒有被放到網際網路上，能擋在內網或 VPN 後面最好。

Apache Solr 是什麼？

一套開源的企業級搜尋平台，很多網站與公司用來做全文搜尋、商品搜尋。

我怎麼知道自己受不受影響？

官方說明不受影響的情況有兩種：沒有用 bin/solr auth enable 啟動 BasicAuth，或啟動之後已為範本帳號設定強密碼。如果你是用這個指令啟用的，就要檢查 security.json。

現在要怎麼處理？

官方的緊急做法是：刪除 security.json 裡的 superadmin、admin、search、index 四個範本帳號，或把它們的密碼改成強密碼。修正版 9.11.0 與 10.1.0 在公告當時尚未釋出。

作者

接案做系統開發、網站與主機託管。觀點裡的文章都是我自己寫的,寫的是做專案時第一手遇到的事。