Exim 郵件伺服器近期揭露了一個嚴重的安全漏洞 CVE-2026-45185，內部代號為 Dead.Letter。這個漏洞主要影響在編譯時選擇使用 GnuTLS 函式庫的 Exim 版本，可能導致遠端程式碼執行（Remote Code Execution, RCE），讓攻擊者在未經授權的情況下接管郵件伺服器。
首先我們需要了解 Exim 的角色。Exim 是一個開源的郵件傳輸代理伺服器（Mail Transfer Agent, MTA），負責在類 Unix 系統中接收、路由並遞送電子郵件。它處理的是 SMTP 協定，而 SMTP 有一個擴展功能稱為 CHUNKING，對應的指令是 BDAT。傳統的郵件傳輸需要先告知郵件大小，而 BDAT 允許將郵件內容分成多個區塊傳送，提高傳輸效率。
漏洞的核心在於記憶體管理錯誤，具體屬於 Use-After-Free（釋放後使用）類型。Use-After-Free 是指程式在釋放（free）了一塊記憶體後，仍然持有指向該位置的指標（pointer）並嘗試對其進行寫入或讀取。這類漏洞非常危險，因為被釋放的記憶體可能已被重新分配給其他重要的系統數據，一旦發生錯誤寫入，就會導致堆疊損壞（Heap Corruption），進而讓攻擊者控制程式執行流。
這次的漏洞觸發路徑相當精巧。當 Exim 透過 TLS（傳輸層安全協定）加密連線處理 BDAT 區塊傳輸時，如果客戶端在郵件內容尚未傳輸完成前，突然發送一個 TLS close_notify 警報（通知伺服器關閉加密連線），接著又在同一個 TCP 連線中發送最後一個明文位元組，就會觸發問題。
在這種特定順序下，Exim 會因為收到 TLS 關閉通知而提前釋放 TLS 傳輸緩衝區。然而，負責處理 BDAT 接收的封裝函數（Wrapper）並未意識到緩衝區已失效，它會嘗試呼叫 ungetc() 函式將一個換行符號寫回該緩衝區。由於該記憶體區域已經被釋放，這個單一位元組的寫入會直接覆蓋掉記憶體分配器（Allocator）的元數據（Metadata）。
記憶體分配器的元數據就像是地圖，記錄了哪些記憶體塊是可用或已佔用的。一旦地圖被損壞，攻擊者就可以利用這種損壞來建構更複雜的記憶體操作原語（Primitives），最終達成執行任意程式碼的目的。
影響範圍與限制
此漏洞影響 Exim 4.97 至 4.99.2 版本。但有一個關鍵的限制：只有在編譯時設定 USE_GNUTLS=yes 的版本才會受影響。如果你使用的是 OpenSSL 函式庫來處理 TLS，則不受此漏洞影響。這說明了漏洞出在 Exim 與 GnuTLS 交互處理連線關閉的邏輯缺陷，而非 SMTP 協定本身的問題。
修復方案與建議
Exim 官方已在 4.99.3 版本中修復此問題。修復的核心在於確保當 BDAT 傳輸過程中收到 TLS 關閉通知時，會立即且乾淨地重設整個輸入處理堆疊（Input Processing Stack），防止程式繼續使用已經失效的指標。
對於維運工程師而言，由於目前沒有有效的暫時緩解措施（Mitigations），唯一的解決方案就是將 Exim 升級至 4.99.3 或更高版本。
來源：thehackernews.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。