Ruby on Rails 一項嚴重漏洞，可讓未經認證的攻擊者僅憑上傳經精心設計的檔案，便在應用程式伺服器上任意寫入檔案 — 前提是該應用程式以 ImageMagick 處理上傳內容。
Rails 專案已透過公告披露此問題，並發布 8.1.4.1 及 8.0.5.2 兩個修補版本加以解決；The Hacker News 於 2026 年 11 月 4 日報導了這項漏洞。
受影響的元件是 Active Storage，即 Rails 內建用於處理檔案上傳、附件與變體（variant）的子系統。由於 Active Storage 在 Rails 應用程式中預設啟用，受影響的程式碼路徑是隨框架本身進入生產環境，而非開發者另行選擇安裝某個上傳函式庫的結果。這一點區別重大：這不是侷限於特定罕見設定的錯誤設定問題，而是任何依賴 ImageMagick 處理內容的 Rails 應用程式都可能在毫不知情的情況下承載的預設路徑暴露。
能夠在未經認證的情況下上傳檔案的攻擊者 — 例如透過開放註冊、聯絡表格或使用者內容端點 — 可觸發此漏洞，將內容寫入伺服器上任選位置。任意檔案寫入往往是通往更嚴重後果的常見途徑：覆寫設定檔、植入可執行程式碼，或竊取憑證，實際影響取決於應用程式處理程序的權限等級。
對於以 Rails 搭配 ImageMagick 營運的團隊，緩解措施有明確的優先次序，應依序執行。
優先套用修補。 升級至 8.1.4.1 或 8.0.5.2。公告確認這兩個分支獲得修復；使用較舊 Rails 版本的團隊應先向專案確認其分支是否有對應的修補版本，切勿直接假定已獲涵蓋，若沒有對應修補則應規劃升級路徑。
在伺服器端驗證上傳。 強制執行內容類型與副檔名檢查、限制檔案大小、在伺服器端產生檔案名稱而非信任用戶端提供的名稱，並拒絕所有不符合預期媒體類型允許清單的內容。
強化 ImageMagick 本身。 檢視 ImageMagick 建置所附的 policy.xml，停用應用程式並無實際需要的 coder 與 delegate — 特別是間接讀寫處理器，以及你接受的上傳組合以外的格式。嚴謹的政策可限制經設計的檔案能誘使處理程序做出什麼。
縮小爆炸半徑。 以未經授權（非特權）使用者身分執行上傳處理程序，僅授予其寫入所需儲存目錄的權限，並將 Active Storage 服務與系統路徑隔離。
在邊緣過濾。 檢查 multipart 上傳的 WAF 或反向代理規則可提供有用的一層防護，但只能作為修補的補充，不能取而代之。
就稽核而言，團隊可快速檢查三件事：應用程式是否存在未經認證的上傳端點；ImageMagick 是否為變體的設定處理器；以及已部署的 Rails 版本是否落在公告所列的修補版本之內。檢查處理器時，應確認 config.active_storage.variant_processor 在生產環境中實際解析為何，而非只依賴程式碼庫看似設定的值 — 團隊經常更換變體處理器，但管線的其他階段仍以 ImageMagick 執行外部命令，令暴露依然存在。
就本次審閱所見的披露資料，Rails 專案並未說明是否已指派 CVE 編號，本文亦未引用任何編號。
對於香港及其他地區的 IT 團隊與開源維護者，實際的重點是：背後原因是框架的預設行為，而非罕見的擴充功能。任何向未經認證使用者開放上傳功能的 Rails 部署，都應將套用修補版本視為優先事項，而非例行維護窗口項目。
Ruby on Rails 一項嚴重漏洞，可讓未經認證的攻擊者僅憑上傳經精心設計的檔案，便在應用程式伺服器上任意寫入檔案 — 前提是該應用程式以 ImageMagick 處理上傳內容。
Rails 專案已透過公告披露此問題，並發布 8.1.4.1 及 8.0.5.2 兩個修補版本加以解決；The Hacker News 於 2026 年 11 月 4 日報導了這項漏洞。
受影響的元件是 Active Storage，即 Rails 內建用於處理檔案上傳、附件與變體（variant）的子系統。由於 Active Storage 在 Rails 應用程式中預設啟用，受影響的程式碼路徑是隨框架本身進入生產環境，而非開發者另行選擇安裝某個上傳函式庫的結果。這一點區別重大：這不是侷限於特定罕見設定的錯誤設定問題，而是任何依賴 ImageMagick 處理內容的 Rails 應用程式都可能在毫不知情的情況下承載的預設路徑暴露。
能夠在未經認證的情況下上傳檔案的攻擊者 — 例如透過開放註冊、聯絡表格或使用者內容端點 — 可觸發此漏洞，將內容寫入伺服器上任選位置。任意檔案寫入往往是通往更嚴重後果的常見途徑：覆寫設定檔、植入可執行程式碼，或竊取憑證，實際影響取決於應用程式處理程序的權限等級。
對於以 Rails 搭配 ImageMagick 營運的團隊，緩解措施有明確的優先次序，應依序執行。
優先套用修補程式。 升級至 8.1.4.1 或 8.0.5.2。公告確認這兩個分支獲得修復；使用較舊 Rails 版本的團隊應先向專案確認其分支是否有對應的修補版本，切勿直接假定已獲涵蓋，若沒有對應修補則應規劃升級路徑。
在伺服器端驗證上傳。 強制執行內容類型與副檔名檢查、限制檔案大小、在伺服器端產生檔案名稱而非信任用戶端提供的名稱，並拒絕所有不符合預期媒體類型允許清單的內容。
強化 ImageMagick 本身。 檢視 ImageMagick 建置所附的 policy.xml，停用應用程式並無實際需要的 coder 與 delegate — 特別是間接讀寫處理器，以及你接受的上傳組合以外的格式。嚴謹的政策可限制經設計的檔案能誘使處理程序做出什麼。
縮小爆炸半徑。 以未經授權（非特權）使用者身分執行上傳處理程序，僅授予其寫入所需儲存目錄的權限，並將 Active Storage 服務與系統路徑隔離。
在邊緣過濾。 檢查 multipart 上傳的 WAF 或反向代理規則可提供有用的一層防護，但只能作為修補程式的補充，不能取而代之。
就稽核而言，團隊可快速檢查三件事：應用程式是否存在未經認證的上傳端點；ImageMagick 是否為變體的設定處理器；以及已部署的 Rails 版本是否落在公告所列的修補版本之內。檢查處理器時，應確認 config.active_storage.variant_processor 在生產環境中實際解析為何，而非只依賴程式碼庫看似設定的值 — 團隊經常更換變體處理器，但管線的其他階段仍以 ImageMagick 執行外部命令，令暴露依然存在。
就本次審閱所見的披露資料，Rails 專案並未說明是否已指派 CVE 編號，本文亦未引用任何編號。
對於香港及其他地區的 IT 團隊與開源維護者，實際的重點是：背後原因是框架的預設行為，而非罕見的擴充功能。任何向未經認證使用者開放上傳功能的 Rails 部署，都應將套用修補版本視為優先事項，而非例行維護窗口項目。