觀點 · 資訊分享
圖片縮圖服務 imgproxy 拿到 9.8 分 CVE：一張特製 ICO 圖示就可能讓伺服器當掉，4.0.16 以前都要升級
imgproxy 的 ICO 讀取器有整數溢位漏洞，特製圖檔可能讓服務崩潰甚至執行程式碼。專案 9 月底就修好、10 月 6 日發布公告，11 月 8 日才取得 CVE-2026-123614，還沒升級的自架站請升到最新版。
- 發布
- 2026-11-08
- 篇幅
- 約 4 分鐘 · 1,862 字
- 結構
- 7 節 + 4 題常見問題
- 標籤
一句話看懂：圖片處理服務 imgproxy 的 ICO 讀取器有 9.8 分漏洞，一張特製圖示檔就可能讓服務崩潰；修補 9 月底就出了，CVE 11 月 8 日才補上，還沒升級的請升到最新版。
先用白話講：imgproxy 和這個漏洞是什麼？
imgproxy 是一套開源的「圖片加工廠」：網站把原圖交給它，它就即時縮小、裁切、轉成 WebP 再送給訪客。很多網站拿它產生縮圖，省下自己寫圖片處理程式的功夫。
這次的漏洞像是一個寫錯尺寸的包裹：包裹上寫「裡面有約 43 億 bytes」，工廠把這個數字加上 14 準備紙箱，結果數字太大「繞了一圈」，算出來只要 3 bytes 的小盒子。接著工廠照著原本的大數字往盒子裡塞東西，多出來的部分就溢到旁邊別人的位置，把記憶體弄亂。
發生什麼事
- 2026-09-28：imgproxy 釋出 4.0.16，說明修好 ICO 圖片讀取器的數個漏洞
- 2026-10-06：專案在 GitHub 發布安全公告 GHSA-hff9-5pqw-6w9f，評為嚴重等級（CVSS 3.1 為 9.8）
- 2026-11-08：漏洞取得編號 CVE-2026-123614 並公開在 NVD，CVSS 4.0 評 9.3 分
受影響版本是 4.0.0 到 4.0.15。官方公告說明，攻擊者不需要登入，只要讓 imgproxy 處理一個特製的 ICO 檔，就可能讓處理中的程序崩潰，堆積記憶體被破壞後也可能進一步被執行程式碼。
同一天的公告還包含兩個 ICO 讀取器的高風險漏洞（越界讀寫、記憶體無上限配置，都可能讓服務當掉）。之後的 4.0.17、4.0.21 也陸續修了 ICO 與 BMP 讀取器的問題。
該怎麼因應
| 你的狀況 | 建議 |
|---|---|
| 4.0.0～4.0.15 | 立刻升級，建議直接到 4.0.22 |
| 4.0.16～4.0.21 | 本 CVE 已修，但仍建議升到 4.0.22 |
| 不確定版本 | 查看容器映像檔標籤或服務啟動紀錄 |
給開發者的技術細節
問題程式碼在 vips/icoload.c：讀進 ICO 目錄裡 32 位元的 data_size 後，直接加上 BMP 檔頭長度去配置記憶體。官方公告的範例中，宣告的大小加上 14 之後溢位，只配置了 3 bytes，後續讀取卻照原本的大小往裡寫，造成堆積溢位（CWE-122、CWE-190、CWE-787）。
用 Docker Compose 部署的話，把 compose 檔裡 imgproxy 的映像檔標籤改成新版，再重新拉取並啟動：
docker compose pull imgproxy
docker compose up -d imgproxy
- 升級後確認服務回報的版本號
- 如果 imgproxy 直接對外開放、沒有限制可處理的圖片來源，也趁這次檢查設定，降低被任意餵圖的機會
我的看法
這類「晚發 CVE」很常見：專案早就修好了，CVE 編號幾週後才補上。好處是修補一定已經有了；壞處是很多人等看到 CVE 新聞才知道要升級，中間那一個多月其實一直暴露在風險裡。
接案時常會用 Docker 架一個縮圖服務，裝好就放著不管，因為「它只是在縮圖」。但圖片解析器處理的是外部送進來的檔案，本來就是攻擊面最大的地方之一。我的建議是：自架的圖片服務也要納入固定更新清單，至少每個月看一次 release，不要等出事才想起它。
名詞小辭典
- CVE：國際通用的漏洞編號，方便大家指的是同一個問題。
- CVSS：漏洞嚴重程度分數，滿分 10，9 分以上屬於「嚴重」。
- 整數溢位：數字超過變數能裝的上限後「繞回」很小的值，就像里程表跑到 99999 之後歸零。
- 堆積溢位（Heap overflow）：程式寫入的資料超出配置的記憶體範圍，蓋到旁邊的資料，可能造成當機或被利用來執行程式碼。