資安公司 Theori 旗下的 Xint Code 團隊近日公開了一項被稱為 Copy Fail 的 Linux 核心安全漏洞。該漏洞已被登錄為 CVE-2026-31431，主要影響 Linux Kernel 中與 algif_aead、AF_ALG 加密介面相關的邏輯處理。研究團隊指出，攻擊者在取得本機低權限帳號或容器內程式執行能力後，可能透過該缺陷提升至 root 權限，這不是傳統意義上的遠端未授權攻擊，但對多租戶主機、容器平台、CI/CD Runner、NAS 與雲端工作負載而言，風險仍不可低估。
根據 Xint Code 的技術說明，Copy Fail 的核心問題在於 Linux 核心加密子系統中 authencesn、AF_ALG 與 splice() 的交互行為。攻擊者可利用該缺陷對 page cache 造成受控寫入，進一步達成權限提升，研究團隊也指出，此類攻擊不一定會改變磁碟上的檔案內容，因此傳統檔案完整性檢查未必能直接偵測到異常。美國 CISA 也已將 CVE-2026-31431 納入 Known Exploited Vulnerabilities Catalog，要求相關單位依供應商指引套用修補或緩解措施。
QNAP：特定 ARM64 NAS 受影響，修補仍在進行中
QNAP 已於 2026 年 5 月 2 日發布 QSA-26-16 安全公告，確認 Copy Fail 影響部分執行 QTS 且採用 ARM64 架構、Linux Kernel 5.10 的 NAS 機型。QNAP 同時強調，所有 x86 架構 QNAP NAS、所有 QuTS hero NAS、執行 QTS 4.x 的 ARM NAS，以及 ARM 架構但不是 Linux Kernel 5.10 的機型不受影響。目前該公告狀態為 Investigating，QNAP 表示正在調查並開發更新，修補檔發布後會更新公告內容。
在更新檔尚未發布前，QNAP 尚未提供可完全修補漏洞的官方 workaround，而是建議使用者先採取降低暴露面的防護措施。具體包含：限制一般使用者取得 shell 或終端機權限，Container Station 僅部署受信任映像檔，並限制容器環境存取；停用不必要的服務與應用程式，包括預設網頁連接埠 80，避免 NAS 直接暴露於網際網路，並透過 QuFirewall 或硬體防火牆限制可連線來源。
對 NAS 環境而言，這代表 Copy Fail 的實際攻擊門檻通常不是直接從網路打進 NAS，而是攻擊者已經取得本機帳號、SSH/shell、惡意 App、受污染容器或某個可在 NAS 上執行程式碼的入口。因此，QNAP 使用者在等待更新時，應優先檢查 NAS 是否開放 SSH、是否有不必要的外部連線服務、Container Station 是否執行來源不明映像檔，以及是否有讓一般帳號具備過高的終端機操作權限。
主要 Linux 發行版與雲端平台修補進度
Ubuntu 已將 Copy Fail 評為 High，並指出 26.04 以前的多個 Ubuntu 版本受影響。Canonical 已先透過 kmod 更新阻擋 algif_aead 載入，作為 kernel 更新釋出前的緩解措施，官方同時建議使用者執行標準系統更新並重新開機，以確保 mitigation 生效。Debian 安全追蹤頁面則已列出 Bullseye、Bookworm、Trixie 等版本對應的修補核心套件。
Red Hat 將此漏洞評為 Important，確認低權限本機帳號可能藉此提升為 root，並表示正針對受影響產品準備修補。NVD 目前列出的受影響產品範圍包含 RHEL 8、RHEL 9、RHEL 10 與 OpenShift 4 等。SUSE 也將此漏洞列為 Important，官方 CVE 頁面顯示整體狀態仍有待完成，但已陸續發布多個產品線的安全公告與修補套件，管理者應依自身 SLES、SUSE Liberty Linux 或相關產品版本套用對應更新。
Amazon Linux 方面，AWS 安全中心公告顯示 Amazon Linux 2 與 Amazon Linux 2023 的多個 kernel 套件受影響，截至該公告頁面最後修改時間，相關套件仍標示為 Pending Fix，建議使用 AWS 工作負載的管理者持續追蹤 ALAS 更新並優先處理具備多租戶、容器或使用者程式執行能力的主機。
AlmaLinux 已於 5 月 1 日表示修補核心正在推送至正式環境，並列出 AlmaLinux 8、9、10 與 AlmaLinux Kitten 10 的修補版本。Oracle Linux 也發布 ELSA-2026-50253，針對 Unbreakable Enterprise Kernel 提供 Copy Fail 安全更新。Arch Linux 安全公告則顯示 linux 套件已於 6.19.12-1 修復。
CloudLinux 與 KernelCare 提供了較值得注意的補充。CloudLinux 指出，CloudLinux 7 不受影響，但 CloudLinux 7h、8、9、10 等不同產品線需依核心版本處理，KernelCare 也已提供免重開機 live patch 方案。不過 CloudLinux 特別提醒，對 CloudLinux、AlmaLinux 與其他 RHEL-family 系統而言，若 algif_aead 是 built-in kernel component，單純使用 modprobe 黑名單並不會真正阻擋漏洞，可能造成錯誤安全感。
CIQ 針對 Rocky Linux LTS 變體也發布說明，建議可更新核心並重新開機，若短期內無法更新，則可使用 initcall_blacklist=algif_aead_init 開機參數作為暫時緩解。這一點也再次提醒管理者，Copy Fail 的緩解方式必須依照發行版與核心配置決定，不能直接套用單一指令到所有 Linux 系統。
暫時性防護建議：先修補，其次才是緩解
最優先的處理方式仍然是套用原廠 kernel、NAS 韌體或安全更新。對 Ubuntu/Debian 類系統，若官方指引確認 algif_aead 是可載入模組，可透過 kmod 或 modprobe 設定阻擋該模組載入。例如：
echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif_aead.conf
sudo rmmod algif_aead 2>/dev/null
grep -qE '^algif_aead ' /proc/modules && echo "algif_aead still loaded" || echo "algif_aead not loaded"但在 RHEL-family、CloudLinux、Rocky、AlmaLinux 等情境，若 algif_aead 是編進核心而非模組，應依供應商建議使用開機參數：
sudo grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"
sudo reboot
grep initcall_blacklist /proc/cmdline對容器平台、Kubernetes 節點、CI/CD Runner、支援使用者上傳程式碼的 SaaS 平台，應額外考慮封鎖 AF_ALG socket 建立、限制非信任容器映像檔、降低容器權限、重新佈署可能暴露過的節點，並將容器內 RCE視為可能升級成宿主機風險的事件處理。Microsoft Defender 團隊也建議管理者在修補前加強網路隔離、存取控制、日誌檢查與偵測規則，並針對可疑容器或主機進行後續清理。
結語
CyberQ 建議，Copy Fail 並不是單純遠端掃描就能直接入侵的漏洞，但它危險之處在於攻擊鏈後段的放大效果，一旦攻擊者已經取得低權限本機帳號、容器內執行能力、CI Runner 工作權限或 NAS 上的程式執行入口，就可能進一步嘗試提升至 root。對企業而言，這類漏洞最需要優先處理的不是單一裸機，而是所有允許不受信任程式碼執行的環境，包括容器叢集、開發測試主機、雲端 VM、共享 Linux Server 與 NAS 應用平台。
CyberQ 指出，對 QNAP 與其他品牌 NAS 用戶而言，目前重點是確認自己的 NAS 是否屬於 ARM64、QTS、Linux Kernel 5.10 的受影響範圍，在更新釋出前，應立即檢查 SSH、終端機權限、Container Station 映像檔來源、不必要的對外服務，以及是否有將 NAS 暴露於網際網路。對一般 Linux 管理者而言，則應依照發行版公告優先更新 kernel，若必須先做緩解，務必確認 algif_aead 在自己的系統中到底是可載入模組，還是已編進核心，避免套用錯誤指令而產生防護已完成的錯覺。
首圖由 Nano Banana AI 生成
