[SUMMARY]Squid 的 CVE-2026-47729 是一個 FTP gateway 的 out-of-bounds read 漏洞，預設設定即可受影響，可能洩露其他使用者的 HTTP 請求內容與敏感資訊。官方已於 Squid 7.6 修補，需盡快更新並檢查代理與 FTP 相關流量。[\/
近期公開的 CVE-2026-47729，又被命名為 Squidbleed，是發生在開源網頁代理伺服器與網路快取軟體 Squid 的記憶體洩漏漏洞。依據公開情資，這個問題存在於 Squid 的預設配置中，影響範圍涵蓋多個版本與多個以官方套件庫提供 Squid 的 Linux 發行版。該漏洞屬於類似 Heartbleed-style 的記憶體讀取問題，攻擊者可透過特定 FTP gateway 流程，從不相關的交易資料中讀出內部記憶體內容。[2]
官方修補資訊指出，Squid 7.6 已包含對 CVE-2026-47729 的修正；相關修補也已先後合入 master/v8 與 master/v7 分支。公開資訊同時提到，這起問題是由 Calif 團隊以 AI 輔助研究方式發現，並在 MADBugs 帳號釋出概念驗證程式碼，顯示其研究成果已足以驗證漏洞可被實際觸發。[2]
從技術路徑來看，CVE-2026-47729 的核心問題是 Out-of-bounds Read，而觸發點位於 Squid 的 FTP directory listing parser。公開分析指出，這段邏輯與舊式 FTP 伺服器輸出的格式差異有關，特別是 NetWare FTP 伺服器在檔名修改時間與檔名前會額外輸出 4 個空格，而一般 FTP 伺服器只會有 1 個空格。[2]
漏洞的成因在於程式後續用來尋找字元的邏輯，將 strchr(w_space, '\0') 的回傳值視為可繼續前進的空白區段。由於在 C 語言中，字串結尾字元 '\0' 也是字串的一部分，strchr() 對它的查找會回傳非 NULL，導致指標 copyFrom 可能越界掃描後續記憶體。結果是 heap overread 發生，系統可能把不屬於該次 FTP 回應的記憶體內容回傳給攻擊者。[2]
Calif 提出的修補方式，是在 if 與 while 條件式前半段加上 *copyFrom &&，先確認目前位置不是字串結尾，再進一步執行後面的條件判斷。這種 short-circuit 邏輯可避免在 *copyFrom 已經是 '\0' 時仍呼叫 strchr()，從源頭阻止越界讀取。[2]
值得注意的是，官方公告把 CVE-2026-47729 定義為對 FTP gateway 的攻擊，而非一般瀏覽快取讀取路徑。這表示漏洞雖然存在於 Squid 核心軟體，但實際風險與是否啟用 FTP 支援、是否讓 proxy 可連到會回應異常 FTP directory listing 的主機有直接關係。[2]
公開情資明確指出，Squid 的 default configuration 即可能受影響，且 FTP support is enabled out of the box，預設 ACL 中也包含 port 21，因此不需要特殊旗標或非預設設定即可觸發風險。只要攻擊者能控制一台可被代理伺服器存取的 FTP server，就有機會誘發這個 out-of-bounds read。[2]
在攻擊結果上，外洩內容可能來自 random unrelated transactions，也就是其他使用者經過同一個 Squid instance 的流量。公開報告特別指出，這些被洩露的資料可能是 HTTP 請求，而 HTTP 請求中常見的敏感項目包括密碼與 API key，因此影響不僅是內容曝光，也可能延伸到帳號接管、服務授權濫用與橫向存取風險。[2]
此外，相關報導提到多個 Linux 發行版已公告受影響版本，包括 SUSE、Amazon Linux、Debian。這代表問題不只存在於上游原始碼，也可能擴散到企業常用的套件管理環境與長期維運中的代理節點，實際暴露面比單一產品公告更廣。[2]
至於風險評等，目前已出現不同廠商給出差異化的 CVSS 評分，例如 Rapid7 給出 10 分、SUSE 給出 6.5 分、Tenable 給出 9.1 分。這種落差通常反映了評分者對攻擊前提、可利用性與實際影響面的不同假設，也提醒防守方應以「可直接洩露敏感資訊」的角度保守處置，而不是僅依單一分數判斷。[2]
最優先的措施是更新到已修補版本。依公開資料，Squid 7.6 已包含 CVE-2026-47729 的修正，若環境中仍使用較舊版本，應儘速升級到含修補的版本或套用發行版提供的安全更新。[2]
第二項重點是檢查 proxy 是否暴露 FTP gateway 能力。由於此漏洞與 FTP 目錄列表解析直接相關，維運團隊應盤點 Squid 是否能連向外部 FTP server，並針對不必要的 FTP 存取路徑建立限制，降低攻擊者可操控的輸入面。[2]
第三，應監控異常的 HTTP 與 FTP 交易。因為攻擊結果可能表現為不尋常的請求內容、看似無關的回應片段，或代理日誌中出現異常的 directory listing 解析行為，SOC 與代理管理人員應將這類跡象納入偵測規則。[2]
第四，若組織有能力進行程式層檢查，應確認 Squid 的版本分支與發行版套件是否已納入修補，並避免僅依表面版本號判斷是否安全。公開情資顯示，修補先後被合入不同 branch，實務上仍需以套件維護者公告與實際部署版本為準。[2]
最後，對於承載登入、金鑰交換或內部系統請求的 proxy 節點，應假設既有流量可能已遭局部外洩，並依風險等級重新輪替 API key、session token 與其他敏感憑證。這一點雖然超出漏洞本身的修補範圍，但對降低後續濫用風險很重要。[2]
5步驟修補清單
參考資料