如果你的環境裡有一台 Splunk Enterprise 10，這週請把它排到清單最上面。CVE-2026-20253 於 2026 年 6 月 10 日由 Splunk 揭露，CVSS 9.8（Critical），是一個免登入的遠端攻擊：根因在 Splunk 10 引入的 PostgreSQL sidecar 服務，它的還原端點完全沒有任何驗證控制（CWE-306）。任何能連到這台機器的人，不需要帳密，就能在 Splunk 主機上建立或截斷任意檔案——研究者已示範把這個「寫檔原語」串成遠端執行程式碼（RCE）。更糟的是，公開 PoC 已在 GitHub 流通。
用人話講這條攻擊鏈。Splunk 10 為了支援新的資料服務，附帶一個 PostgreSQL「sidecar」小服務，它有兩個還原端點（/v1/postgres/recovery/backup 與 /v1/postgres/recovery/restore），原本應該只給內部用——但它們沒做任何身分驗證，而且可以透過 Splunk 主 Web 應用的代理機制從外面被打到。攻擊者先用無認證的檔案寫入落地一個檔案，再濫用 PostgreSQL 的 lo_export 函式把惡意腳本寫到磁碟並觸發執行，整條鏈不需要任何憑證、不需要使用者互動。它是 S:U / C:H / I:H / A:H——機密、完整、可用性全高。
影響範圍很具體：Splunk Enterprise 10.2.0–10.2.3（修補版 10.2.4） 與 10.0.0–10.0.6（修補版 10.0.7）。10.4.0 不受影響；Splunk Cloud 不受影響（不使用 PostgreSQL sidecar）。要特別注意：這個 sidecar 在 AWS 上的 Splunk Enterprise 預設啟用，等於雲端部署「開箱就暴露」。揭露時間軸是：6/10 廠商公告 → 數日內公開 PoC → 6/15 多家安全廠商發出分析與外部攻擊面偵測，把「網際網路可達的舊版」直接列為高風險。
接下來我會解：漏洞類型與攻擊路徑、三類角色今天該做什麼、補丁與（在 PHP/Nginx/Linux 環境也通用的）緩解對照、可監看的指標，以及為什麼「監控主機被打」比一般 RCE 更危險。
技術細節：漏洞類型與攻擊路徑
分類上這是 Missing Authentication for Critical Function（CWE-306），再鏈到任意檔案寫入與 RCE。攻擊複雜度低、無需認證、無需互動。攻擊者打 sidecar 還原端點 → 無認證寫/截斷檔案 → 用 lo_export 把 payload 寫到可執行路徑 → 觸發執行。Splunk 明說沒有 workaround，補丁是唯一根治。即使你不是 Splunk 用戶，這個模式對 Laravel／Nginx 團隊也是一記警鐘：內部服務端點絕不該透過反向代理在無認證下被外部打到。在補丁落地前，可在代理層先把還原端點擋掉、把管理介面鎖進信任網段：
# nginx 緩解：擋掉 PostgreSQL sidecar 還原端點（暫時，非根治）
location ~* ^/v1/postgres/recovery/(backup|restore) {
deny all;
return 403;
}
# 管理／sidecar 只開放信任網段
location /en-US/manager/ {
allow 10.0.0.0/8; # 你的內網
deny all;
}同理，任何用 PostgreSQL／MySQL 的應用都該檢查：DB 帳號是否擁有不必要的 lo_export／檔案寫入權限？把「資料庫能寫檔」這條路徑收掉，能擋掉一大類「SQL→寫檔→RCE」攻擊。
三類讀者的立刻行動
- 系統管理員：盤點所有 Splunk Enterprise 版本，受影響的升到 10.2.4 或 10.0.7。AWS 上的部署優先，因為 sidecar 預設開。無法立即補的，先用網段隔離把 sidecar／管理面從公網收回。
- 開發者：檢查你維護的服務裡，有沒有「內部端點被反向代理意外曝光」的同類問題；收緊 DB 帳號權限，移除非必要的檔案寫入能力（如 PostgreSQL
lo_export、MySQLFILE權限）。 - 接案商／顧問：對有跑 Splunk 或任何自架監控／log 平台的客戶，寄一封通告：說明 CVE、是否受影響、你建議的補丁與隔離步驟、以及你何時可協助處理。範本見下方聯絡資訊。
補丁 vs 緩解措施對照
| 方式 | 做什麼 | 效果 | 限制 |
|---|---|---|---|
| 立即補丁（根治） | 升級到 10.2.4 或 10.0.7（10.4.0 不受影響） | 完全消除漏洞，Splunk 表明這是唯一根治 | 需排升級窗口、驗證相容性 |
| 網段隔離（緩解） | 把管理介面與 sidecar 限制在信任 IP，移出公網 | 大幅降低外部可達性 | 內網橫向移動仍可能；非根治 |
| 反向代理擋路徑（緩解） | 在 nginx／WAF deny 還原端點 | 擋掉已知攻擊路徑 | 可能有其他路徑；治標 |
| 檔案系統／程序監看（偵測） | 監看 Splunk 服務帳號的異常寫檔與程序執行 | 能及早發現利用嘗試 | 偵測不等於阻擋 |
IOC 與威脅情資
Splunk 未公布正式 IOC，偵測以行為為主。可監看的指標：
- 對
/v1/postgres/recovery/backup或/restore的非預期存取請求。 - Splunk 服務帳號可寫目錄出現異常的新建／截斷檔案。
- 非由已知使用者或排程搜尋觸發的程序執行（特別是 Python 腳本）。
- 非預期的資料庫 backup／restore 操作紀錄。
- 來自陌生 IP 或雲端託管位址段、針對 Splunk Web 介面的掃描。
不會告訴你的事
- 「我們是內網」不等於安全。sidecar 可透過主 Web 應用代理被打到，只要有人能到你的 Splunk Web，就可能繞到這條路。內網一旦有一台被釣，整條鏈就成立。
- 監控主機被打比一般 RCE 更糟。Splunk 蒐集全環境的 log 與憑證碎片，拿下它等於拿到一張環境地圖與橫向移動的起點。把它當「次要系統」延後修補，是最常見也最危險的判斷錯誤。
這代表的更大趨勢
從揭露到公開 PoC 只隔了幾天，這已是 2026 年的常態：邊緣與管理面服務一旦出現「免認證 + 可達」的組合，攻擊產業化的機器會在數日內把它武器化。CWE-306 這種「忘了加驗證」的低級錯誤，在新加入的附屬服務（sidecar、agent、recovery API）上反覆出現——因為它們常被當成「內部用、不會曝光」而跳過認證設計。SecOps 的重點正從「修 CVE」轉向「盤清每一個對外可達的端點到底有沒有驗證」。
常見問題 FAQ
我跑的是 Splunk Cloud，需要動作嗎？
不需要。Splunk Cloud 不使用 PostgreSQL sidecar，不受 CVE-2026-20253 影響。只有自管的 Splunk Enterprise 10.0.x／10.2.x 需要升級。
我把 Splunk 放在內網，還會中嗎？
仍有風險。漏洞可透過主 Web 應用代理被觸發，只要攻擊者能到達 Splunk Web（例如先釣到一台內網機器），就能利用。內網不是豁免，補丁與網段隔離都要做。
沒辦法馬上升級怎麼辦？
Splunk 表明沒有官方 workaround，但你可以先把管理介面與 sidecar 限制到信任網段、在反向代理擋掉還原端點、並加強檔案與程序監看。這些是緩解，不是根治，補丁仍要盡快排。
怎麼判斷有沒有被打過？
檢查 Splunk 服務帳號可寫目錄的異常新檔、非預期的 backup/restore 紀錄、以及非排程觸發的程序執行。發現可疑跡象就走事故應變：隔離、保留證據、輪換該主機可接觸到的憑證。
我的觀點
主流會把這歸類為「又一個該打的 critical CVE，補就對了」。我的判斷是：這顆的真正教訓不在 Splunk，而在「附屬服務免認證」這個正在系統性重演的設計病。sidecar、agent、recovery API 這些近年被塞進產品的小組件，常因為「反正只給內部」而跳過驗證——然後被一個代理路徑曝光，CVSS 直接 9.8。對 ScriptWalker 這種看護客戶系統的工作室，這是一個很實在的看護機會：與其等客戶問「我有沒有事」，不如主動做一輪「對外可達端點 × 是否有驗證」的盤點——把每個經過 nginx 曝光的內部 API、管理面、metrics、recovery 端點列出來，逐一確認驗證與網段。這種主動通報與盤點，正是把一次性接案變成長期信任關係的支點。需要我們替你的環境跑一輪？
- Email：[email protected]
- 電話：0916-224-047
- LINE：@ufv9089p