CVE on KnightLi的博客

poc-lab 補丁驗證：確認你的系統中近期高危漏洞是否已修復，涵蓋 Chrome CSSFontFeatureValuesMap UAF、NGINX Rift、Dirty Frag、Fragnesia

Fri, 22 May 2026 23:13:24 +0800

poc-lab 是一個面向近期高嚴重性漏洞的 PoC 與復現腳本倉庫，重點收集新披露、有影響力的 CVE 復現材料。專案覆蓋範圍包括 Linux 核心、Windows、macOS、容器、服務元件和瀏覽器相關漏洞。

從倉庫定位看，它更像是一個安全研究資料庫，而不是面向普通使用者的一鍵工具合集。每個漏洞目錄通常會包含 PoC 腳本、建置檔案和說明文件，用來幫助研究人員理解漏洞影響、復現條件和參考資料。

專案主要內容

倉庫目前按照漏洞編號或漏洞名稱組織目錄。已經列出的完整漏洞名稱包括：

CVE-2026-2441：Chrome CSSFontFeatureValuesMap use-after-free，簡稱 Chrome CSSFontFeatureValuesMap UAF。
CVE-2026-27623：Pre-Authentication Denial of Service from malformed RESP request，即畸形 RESP 請求導致的預認證拒絕服務漏洞。
CVE-2026-31429：Slab Cross-Cache，Linux 核心 slab 跨快取利用方向漏洞。
CVE-2026-31431：Copy Fail，Linux 核心相關漏洞。
CVE-2026-31635：DirtyDecrypt，系統安全邊界相關漏洞。
CVE-2026-42945：NGINX Rift，NGINX 相關高危漏洞。
CVE-2026-43284：Dirty Frag，Linux 核心相關漏洞。
CVE-2026-43494：PinTheft，權限或憑證安全邊界相關漏洞。
CVE-2026-43500：Dirty Frag，Linux 核心相關漏洞。
CVE-2026-46300：Fragnesia，Linux 核心相關漏洞。
CVE-2026-46333：SSH Keysign pwn，SSH keysign 安全邊界相關漏洞。

這些名稱可以看出，專案關注的不只是單一平台，而是橫跨瀏覽器、Linux 核心、服務端元件和系統安全邊界。對做漏洞分析、補丁驗證、偵測規則編寫和安全課程實驗的人來說，這類資料有一定參考價值。

目錄結構

專案 README 中說明，每個漏洞目錄會盡量保持一致結構。常見檔案包括：

exploit.py 或 exploit.sh：PoC 腳本
README.md：漏洞資訊、受影響版本、復現步驟和參考資料
build 或相關建置檔案：用於編譯或準備復現環境

倉庫結構大致如下：

poc-lab/
├── CVE-2026-XXXXX/
│   ├── exploit
│   ├── build
│   └── README.md
├── VULN-NAME/
│   ├── exploit.sh
│   └── README.md
└── ...

如果漏洞已經分配 CVE 編號，目錄會優先使用 CVE 命名；如果還沒有 CVE，則可能使用公開漏洞名稱。

適合哪些場景

這類倉庫更適合以下用途：

安全研究人員復現漏洞觸發條件。
企業安全團隊驗證補丁是否生效。
偵測工程師編寫 IDS、EDR、WAF 或日誌偵測規則。
安全課程或內部培訓中建構隔離實驗環境。
研究人員對比不同漏洞的利用前提和防護思路。

它不適合直接用於生產環境掃描，也不應該用於未授權系統。PoC 的價值在於幫助理解風險和驗證防護，而不是擴大攻擊面。

使用時需要注意什麼

第一，必須在隔離環境中測試。漏洞復現可能觸發崩潰、權限變化、檔案損壞或服務不可用，不應在辦公機、生產伺服器或第三方系統上直接運行。

第二，要先閱讀每個漏洞目錄內的 README.md。不同 PoC 的依賴、目標版本、觸發條件和風險不同，只看根目錄說明遠遠不夠。

第三，要確認授權邊界。即便只是運行公開 PoC，只要目標系統不屬於自己或沒有明確授權，就可能帶來法律和合規風險。

第四，復現完成後應回到防護層面。包括確認補丁版本、補充偵測規則、檢查暴露面、更新資產清單和沉澱應急流程。

為什麼這類倉庫值得關注

近年來，高危漏洞從披露到出現公開利用細節的時間越來越短。對防守方來說，只有安全公告和 CVE 描述通常不夠，還需要理解漏洞在真實環境中的觸發條件、利用限制和偵測訊號。

poc-lab 這類倉庫的意義在於，把分散的高危漏洞復現材料按目錄整理起來，讓研究者能更快完成風險驗證。它不替代官方公告、廠商補丁和安全基線，但可以作為補丁驗證和偵測工程的補充資料。

不過也要看到風險：公開 PoC 會降低復現門檻。如果組織內部沒有及時補丁管理和資產梳理能力，公開復現材料可能會放大暴露窗口。因此，對企業安全團隊來說，關注這類專案的同時，更重要的是建立快速評估和修復流程。

小結

poc-lab 是一個近期高危漏洞 PoC 與復現腳本集合，覆蓋 Linux 核心、瀏覽器、服務元件和系統安全相關問題。它適合安全研究、補丁驗證和偵測規則開發，但必須放在授權、隔離和負責任披露的邊界內使用。

對普通讀者來說，關注這類專案的重點不是「怎麼運行 PoC」，而是理解一個事實：高危漏洞公開後的驗證和利用節奏正在加快，安全團隊需要更快完成資產識別、補丁評估、偵測補充和風險閉環。

參考資料：

GitHub 專案：https://github.com/Unclecheng-li/poc-lab/tree/main
中文 README：https://github.com/Unclecheng-li/poc-lab/blob/main/README.zh-CN.md

CVE-2026-43494 / PinTheft：Linux RDS 與 io_uring 組合出的本地提權風險

Fri, 22 May 2026 15:16:59 +0800

CVE-2026-43494 是一個 Linux 核心本地權限提升風險，外界也用 PinTheft 來稱呼相關利用鏈。它的關鍵不在遠端入口，而在於本地低權限使用者能否同時碰到 RDS zerocopy、io_uring fixed buffer、可讀 SUID-root 程式和合適的核心版本。

需要先說明一個編號細節：Unclecheng-li/poc-lab 倉庫目錄名寫的是 CVE-2026-43494 PinTheft，README 標題裡又寫了 QVD-2026-27616 - PinTheft。從公開 CVE 條目和第三方通告來看，CVE-2026-43494 指向的是 Linux kernel RDS zerocopy 中 op_nents 未正確重置引發的 double-free / 引用計數異常問題；QVD-2026-27616 更像是奇安信風險通告編號。實際排查時建議同時記錄這兩個標識，但以發行版安全公告和核心補丁狀態為準。

漏洞核心是什麼？

這個問題出現在 Linux RDS，也就是 Reliable Datagram Sockets 的 zerocopy 發送路徑中。公開描述裡的關鍵函式是：

1
2

rds_message_zcopy_from_user()
rds_message_purge()

當 iov_iter_get_pages2() 在 rds_message_zcopy_from_user() 中失敗時，已經 pin 住的頁面會先被錯誤路徑釋放；但相關 op_nents 資訊沒有被正確清零，後續 rds_message_purge() 仍可能按殘留條目再釋放一次。結果就是同一批頁面引用被多減，形成可被利用的引用計數錯誤。

單看 RDS bug，它是核心記憶體管理裡的錯誤路徑問題。PinTheft 的危險之處在於利用鏈把它和 io_uring 固定緩衝區機制連了起來：io_uring 仍保存著舊的 struct page *，而頁面本身已經被釋放並重新分配給其他用途。PoC 進一步把這個狀態引向 SUID-root 程式的 page cache 覆寫，最終達到本地提權。

為什麼叫 PinTheft

io_uring REGISTER_BUFFERS 會固定使用者頁。對普通頁面來說，FOLL_PIN 並不只是簡單增加一個引用，而是透過較大的 bias 增加 page refcount。公開 PoC 中使用了 GUP_PIN_COUNTING_BIAS = 1024 這個概念。

PinTheft 這個名字的意思是：攻擊鏈透過 RDS zerocopy 的失敗路徑，一次次「偷走」這些 pin 引用。等引用被耗掉後，io_uring 仍以為自己持有有效頁面，但該實體頁已經可以被釋放並被 page cache 重新占用。

這類漏洞容易被誤讀成「直接改了磁碟上的 /usr/bin/su」。更準確的說法是：利用鏈嘗試覆寫的是記憶體中的 page cache。檔案本體不一定被寫回磁碟，但核心執行該 SUID 程式時可能從被污染的頁快取取指令，從而執行攻擊載荷。

觸發條件並不寬

這不是一個「任意 Linux 伺服器都能遠端打」的漏洞。公開資訊顯示，利用鏈至少依賴這些條件：

核心啟用了 CONFIG_RDS 和 CONFIG_RDS_TCP。
系統啟用了 CONFIG_IO_URING，且 kernel.io_uring_disabled=0。
rds / rds_tcp 模組已經載入，或低權限使用者可以觸發自動載入。
本地存在可讀的 SUID-root 二進位程式，例如 /usr/bin/su、/usr/bin/passwd、/usr/bin/pkexec。
公開 PoC 還依賴較新的 IORING_REGISTER_CLONE_BUFFERS API，CloudLinux 的分析提到公共 PoC 更偏向 kernel 6.13 及以上形態。

只要其中一環不成立，公開鏈路就會斷掉。比如很多 RHEL 系發行版預設不編譯 RDS，Ubuntu 舊核心可能缺少 PoC 需要的 io_uring clone buffer API，部分環境也會限制非特權使用者自動載入 RDS 模組。

一分鐘自查

先看核心設定：

1
2

zgrep -E "CONFIG_(RDS|RDS_TCP|IO_URING)" /proc/config.gz 2>/dev/null \
  || grep -E "CONFIG_(RDS|RDS_TCP|IO_URING)" /boot/config-$(uname -r)

再看 io_uring 是否被禁用：

`1`	`cat /proc/sys/kernel/io_uring_disabled 2>/dev/null`

常見含義可以按這個思路理解：

0：允許使用，風險面最大。
1：限制非特權使用者使用，具體行為看核心版本和發行版策略。
2：禁用 io_uring。

檢查 RDS 模組是否存在、是否可載入：

1
2

lsmod | grep -E "^rds|^rds_tcp"
modprobe -n -v rds_tcp 2>&1 | head -3

如果 CONFIG_RDS 是 not set，或者系統根本沒有 rds_tcp 模組，通常就無法走到這個 bug。反過來，如果 RDS 可用、io_uring 未禁用、系統又是較新的通用核心，就應該提高優先級繼續確認發行版修復狀態。

哪些機器更值得優先看？

優先排查這些環境：

多使用者 Linux 主機、教學機、跳板機、共享開發機。
容器宿主機，尤其是允許不可信本地使用者或較寬鬆容器逃逸面的環境。
開啟較新 mainline / rolling kernel 的桌面或伺服器，例如 Arch 一類滾動發行版。
HPC、Oracle RAC 或其他可能真實使用 RDS 的場景。
允許非特權使用者執行大量本地程式碼的 CI worker、建置機和實驗環境。

普通 Web 服務如果只有受控服務帳號執行應用，並且 RDS 未啟用，實際風險會低很多。但「低很多」不等於不用處理：核心本地提權的典型影響是攻擊者先透過 Web、SSH、CI、容器或應用漏洞拿到低權限，再用本地提權擴大控制面。

臨時緩解建議

正式修復仍應以發行版核心更新為準。補丁、回溯版本和受影響範圍需要看 Debian、Ubuntu、RHEL、AlmaLinux、Rocky Linux、SUSE、Arch、雲廠商或容器基礎映像各自的安全公告，不要只按上游版本號判斷。

在等待補丁或無法馬上重啟核心時，可以按環境選擇臨時措施：

# 如果業務不依賴 RDS，可阻止相關模組載入
sudo sh -c "printf 'install rds /bin/false\ninstall rds_tcp /bin/false\ninstall rds_rdma /bin/false\n' > /etc/modprobe.d/pintheft.conf"
sudo rmmod rds_tcp 2>/dev/null
sudo rmmod rds_rdma 2>/dev/null
sudo rmmod rds 2>/dev/null

如果業務不依賴 io_uring，也可以考慮禁用或限制它：

`1`	`sudo sysctl -w kernel.io_uring_disabled=2`

持久化設定需要寫入對應的 /etc/sysctl.d/*.conf。不過這一步要謹慎，現代資料庫、代理、執行時或高效能 I/O 程式可能使用 io_uring；生產環境修改前最好先確認業務依賴。

修復後怎麼驗證

升級核心後，不要只看套件管理器輸出成功。建議確認三件事：

1
2
3

uname -a
cat /proc/sys/kernel/io_uring_disabled 2>/dev/null
modprobe -n -v rds_tcp 2>&1 | head -3

如果發行版公告明確寫明已修復 CVE-2026-43494，即使 uname -r 看起來不是最新上游版本，也可能是已經回溯補丁的穩定核心。反過來，如果核心來源是自行編譯、第三方倉庫、雲市場映像或容器宿主機模板，就要繼續核對補丁 commit 和建置時間。

參考資訊

近期四個 Linux 本地提權漏洞影響梳理：Copy Fail、Dirty Frag、Fragnesia 與 ssh-keysign-pwn

Wed, 20 May 2026 23:00:37 +0800

最近 Linux 生態連續出現幾起高關注度的本地安全問題。單獨看，它們分別落在加密介面、網路/IPsec 路徑、頁快取處理、ptrace 存取檢查等不同位置；放在一起看，真正值得警惕的是同一個結論：只要攻擊者已經拿到低權限本地執行點，Linux 宿主機、容器節點、CI 機器和多使用者伺服器的風險都會被明顯放大。

本文重點不複述每個漏洞的技術細節，而是整理它們對實際環境的影響，並給出站內四篇單獨分析文章作為延伸閱讀。

四次事件分別影響什麼

近期最需要關注的四個風險是：

Copy Fail（CVE-2026-31431）：低權限本地使用者可能透過內核加密相關路徑影響頁快取，進而擴大權限。
Dirty Frag（CVE-2026-43284 / CVE-2026-43500 相關）：風險集中在 xfrm/ESP、RxRPC 等網路和內核資料路徑，後滲透階段危害很高。
Fragnesia（CVE-2026-46300）：與 Dirty Frag 相近，同樣圍繞 XFRM ESP-in-TCP、共享 fragment 和頁快取寫入風險展開。
ssh-keysign-pwn（CVE-2026-46333）：不是直接 root shell 類型漏洞，而是本地資訊洩露風險，可能讀取 SSH 主機私鑰、/etc/shadow 等敏感檔案。

這四類問題的入口不同，緩解方式也不完全一樣。不能因為處理了 Copy Fail，就預設 Dirty Frag 和 Fragnesia 也安全；也不能因為禁用了某些網路模組，就認為 ssh-keysign-pwn 的資訊洩露風險自動消失。

Copy Fail：容器和 CI 節點優先級很高

Copy Fail 的關鍵影響不是「某個應用崩潰」，而是低權限執行能力可能被轉化為 root 權限。它對以下環境尤其敏感：

允許使用者上傳或執行程式碼的 CI/CD 節點。
託管不可信工作負載的容器宿主機。
開發測試機、跳板機、共享伺服器。
執行舊內核且補丁節奏較慢的雲主機。

Copy Fail 的危險點在於攻擊門檻偏低，而且容易和容器場景疊加。很多團隊把容器當作強隔離邊界，但普通容器預設仍共享宿主機內核。如果攻擊者能在容器內取得 shell，內核本地提權就可能把容器問題放大為宿主機問題。

詳細分析見站內文章：Copy Fail 漏洞 CVE-2026-31431：Linux 內核檔案複製路徑中的容器逃逸風險。

Dirty Frag：後滲透階段的放大器

Dirty Frag 更像是攻擊者進入系統後的權限放大工具。它不是典型的遠端無認證漏洞，前提通常是攻擊者已經透過弱密碼、WebShell、低權限服務帳號、容器任務或其他方式取得本地執行能力。

它的實際影響主要體現在：

已被入侵的低權限帳號可能進一步變成 root。
容器環境中的低權限執行點可能威脅宿主機。
使用 IPsec、ESP、RxRPC 或相關內核網路能力的系統需要謹慎評估補丁和臨時緩解。
安全團隊不能只看邊界防護，還要關注入侵後的提權鏈條。

Dirty Frag 提醒運維團隊：本地提權漏洞雖然不是第一入口，卻可能決定一次入侵最終能走多遠。只要存在低權限落點，攻擊者就會尋找內核漏洞把權限推到最高。

詳細分析見站內文章：Dirty Frag CVE-2026-43284：Linux 本地提權漏洞風險與緩解指南。

Fragnesia：同類攻擊面沒有一次性清乾淨

Fragnesia 的重要性在於，它說明 Dirty Frag 附近的攻擊面並不是一個孤立問題。即使某個漏洞被修復，相鄰路徑、相似資料結構、相同模組組合裡仍可能存在新的可利用點。

它對運維的影響主要是：

不能只按漏洞名稱做一次性處置，要按攻擊面持續檢查。
esp4、esp6、rxrpc、XFRM、ESP-in-TCP 等相關路徑需要結合業務依賴評估。
如果系統不依賴相關網路能力，可以考慮臨時禁用，但必須先在測試環境確認不會影響 VPN、IPsec、隧道或內部網路功能。
頁快取污染類風險可能帶來「看似檔案沒改，實際執行路徑受影響」的檢測盲點。

Fragnesia 對企業最大的提醒是：補丁管理不能只盯單個 CVE。更穩妥的做法是圍繞子系統和攻擊面建立清單，確認哪些機器暴露相關能力，哪些業務真正需要這些模組。

詳細分析見站內文章：Fragnesia (CVE-2026-46300)：Linux 內核本地提權漏洞影響與緩解。

ssh-keysign-pwn：不直接 root，也足夠危險

ssh-keysign-pwn 與前三個漏洞的性質不同。它更偏向本地敏感資訊洩露，不是直接拿 root shell 的漏洞。但在真實攻擊中，敏感資訊洩露常常能變成更嚴重的後果。

它的影響重點包括：

SSH host private keys 洩露後，可能影響主機身分可信度。
/etc/shadow 等檔案被讀取後，可能引發離線破解和帳號接管。
多使用者伺服器、跳板機、建置機、共享開發機風險更高。
即使攻擊者沒有立刻提權，也可能拿到後續橫向移動需要的憑據材料。

這類問題容易被低估，因為它沒有「直接 root shell」那麼刺激。但對企業環境來說，密鑰和密碼雜湊洩露往往意味著更長週期的清理：輪換 SSH 主機密鑰、排查信任關係、檢查帳號密碼、審計登入日誌，都可能成為必要動作。

詳細分析見站內文章：ssh-keysign-pwn（CVE-2026-46333）解讀：Linux 本地資訊洩露、SSH 主機密鑰與 /etc/shadow 風險。

共同影響：容器隔離不能再被當作強邊界

這四次事件合在一起，最直接的影響是重新提醒大家：普通容器隔離不是虛擬機隔離。

Docker、containerd 和 Kubernetes 依賴 namespace、cgroup、capabilities、seccomp、AppArmor 或 SELinux 等機制減少攻擊面，但它們通常仍共享宿主機內核。只要漏洞發生在共享內核裡，容器內的低權限執行點就可能成為攻擊入口。

高風險環境應重點檢查：

是否允許不可信程式碼執行在共享宿主機上。
容器是否預設 root 使用者執行。
是否授予了不必要的 capabilities。
seccomp 配置是否過寬。
多租戶工作負載是否應該遷移到 gVisor、Kata Containers、Firecracker microVM、獨立虛擬機或專用節點。

對 CI/CD 平台尤其要謹慎。建置任務天然會執行外部程式碼、依賴安裝腳本、測試腳本和臨時二進位。如果這些任務與長期服務共享宿主機，一次本地提權就可能影響更大的基礎設施。

共同影響：補丁必須落到「正在執行的內核」

Linux 內核補丁有一個很常見的誤區：套件管理器顯示已經更新，不代表機器正在執行新內核。

運維上至少要確認三件事：

`1`	`uname -a`

確認目前執行內核版本。

`1`	`dpkg -l \| grep linux-image`

或在 RHEL 系發行版上：

`1`	`rpm -qa \| grep kernel`

確認已安裝內核套件。

最後，還要確認機器已經重啟到修復後的內核。對不能重啟的核心業務，要評估 livepatch、熱補丁或短期隔離方案，但不要把臨時緩解當作最終修復。

共同影響：攻擊面最小化要具體到模組和系統呼叫

這幾次漏洞涉及的路徑提醒我們，Linux 加固不能只停留在「更新系統」和「開防火牆」。

更具體的檢查方向包括：

AF_ALG / algif_aead 是否被業務使用。
XFRM、ESP、ESP-in-TCP、IPsec 是否被 VPN、隧道或安全閘道依賴。
RxRPC 是否需要啟用。
非特權使用者命名空間是否必須開放。
容器是否能建立過寬的 socket 類型。
ptrace 存取策略是否過鬆。

如果業務確實不需要某些能力，可以評估禁用模組、調整 sysctl、收緊 seccomp、減少 capabilities。生產環境不要盲目複製命令，應先盤點依賴，再灰度執行。

建議的處置順序

第一，優先修復可本地執行程式碼的高暴露機器：

容器宿主機。
CI/CD runner。
跳板機。
多使用者伺服器。
對外服務所在主機。
執行不可信插件、腳本、擴充的系統。

第二，確認發行版公告和實際執行內核。不要只看上游版本號，Debian、Ubuntu、RHEL、AlmaLinux、Rocky Linux、SUSE、openEuler 等發行版可能會 backport 安全補丁。

第三，收緊容器執行策略。盡量做到非 root 使用者、最小 capabilities、no-new-privileges、唯讀檔案系統、明確 seccomp 和 AppArmor/SELinux 策略。

第四，檢查密鑰和憑據風險。尤其是涉及 ssh-keysign-pwn 的環境，應評估 SSH host key、/etc/shadow、跳板機憑據和 CI secrets 是否需要輪換。

第五，補上監控。重點關注異常 root shell、可疑本地提權 PoC、關鍵檔案修改、異常 ptrace 行為、容器程序存取宿主機路徑、CI 節點上的異常網路連線。

結論

這四次事件的重點不是「Linux 不安全了」，而是「預設信任不夠用了」。

Linux 仍然是透明、可修復、可裁剪、可加固的主流系統。但在容器、CI、多租戶和 AI 自動化程式碼執行越來越普遍的環境裡，低權限執行點已經不能被看作小問題。只要內核裡存在可利用的本地提權或敏感資訊洩露漏洞，局部入侵就可能變成宿主機控制、憑據洩露或橫向移動。

更現實的做法是把這四次事件當成一次提醒：補丁要快，重啟要確認，模組要按需啟用，容器要收緊，密鑰要能輪換，多租戶要重新評估隔離等級。

站內延伸閱讀：

ssh-keysign-pwn（CVE-2026-46333）解讀：Linux 本地資訊外洩、SSH 主機金鑰與 /etc/shadow 風險

Sun, 17 May 2026 09:29:03 +0800

ssh-keysign-pwn 是圍繞 Linux kernel __ptrace_may_access() 邏輯問題公開的一組利用路徑，CVE 編號為 CVE-2026-46333。它不是遠端未授權漏洞，也不是直接取得 root shell 的漏洞，但風險仍然很高：本地低權限使用者可能讀取本不該存取的 root 敏感檔案，例如 SSH 主機私鑰或 /etc/shadow。

對維運來說，重點不是重現 PoC，而是盡快判斷哪些機器受影響、升級核心、重新啟動生效，並在必要時輪換 SSH host keys 和重設密碼。

先說結論

這次漏洞的處置優先級很高，原因有四點：

觸發條件是本地低權限使用者，不需要 root。
已有公開 PoC，利用門檻明顯降低。
影響目標不是普通檔案，而可能是 SSH 主機私鑰和 /etc/shadow。
修復需要核心修補並重新啟動，不能只升級套件後不重啟。

如果你的伺服器有多使用者、本地 shell、共享主機、CI runner、容器宿主機、學生機房、跳板機或任何「不完全可信的本地使用者」，應該優先處理。

漏洞是什麼

Qualys 在 2026 年 5 月 15 日透過 oss-security 公開說明：他們此前向 security@kernel.org 回報了 Linux kernel __ptrace_may_access() 的邏輯問題，上游修復已由 Linus 合入。隨後社群出現公開利用程式，因此 Qualys 將資訊發到 oss-security。

Linux kernel CVE 團隊隨後為這個問題分配了 CVE-2026-46333。NVD 頁面顯示該 CVE 來源為 kernel.org，問題描述對應核心提交 ptrace: slightly saner 'get_dumpable()' logic。

簡單說，這個漏洞出現在程序退出路徑上。某些特權程序正在退出時，核心中與 ptrace 存取檢查相關的邏輯可能因目標任務已經沒有 mm，而繞過本應依賴的 dumpable 檢查。攻擊者可以在很窄的競態窗口中，取得正在退出的特權程序仍然開啟的檔案描述符。

這也是為什麼它被稱為 ssh-keysign-pwn：公開利用路徑之一會圍繞 ssh-keysign 讀取 SSH host private keys。

為什麼能讀到 SSH 主機私鑰和 /etc/shadow

這個問題本質上是本地資訊外洩。它利用的是特權程式在退出過程中「記憶體描述符已經脫離，但檔案描述符還沒關閉」的時間窗口。

AlmaLinux 的公告對風險說得比較清楚：如果特權程式在降權前開啟了敏感檔案，而攻擊者在退出窗口中成功取得對應檔案描述符，就可能讀取這些敏感檔案。

公開討論中常見的兩個目標是：

ssh-keysign：可能涉及 /etc/ssh/ssh_host_*_key 這類 SSH 主機私鑰。
chage：可能涉及 /etc/shadow。

SSH 主機私鑰外洩後，攻擊者可能偽裝成該主機，影響 SSH 主機身分信任。/etc/shadow 外洩後，攻擊者可以離線破解密碼雜湊，進一步擴大影響。

這也是為什麼它雖然不是「直接 root shell」，但仍然應按高優先級處理。

影響範圍怎麼判斷

從上游角度看，這是 Linux kernel 的漏洞。NVD 記錄顯示該問題在 2026 年 5 月 15 日進入 NVD 資料集，當時 NVD 還沒有給出 CVSS 評分。

發行版層面的狀態要以各自公告為準：

AlmaLinux 8、9、10 都發布了處理說明，並在 2026 年 5 月 16 日更新稱 patched kernels 已進入生產倉庫。
Debian security tracker 已列出 bullseye、bookworm、trixie、sid 等分支的 vulnerable/fixed 狀態和固定版本。
其他發行版需要分別查看 Ubuntu、Red Hat、SUSE、Arch、Alpine 等官方安全頁面或更新源。

不要只按核心大版本判斷是否安全。發行版會 backport 修復，同一個上游版本號在不同發行版中可能代表不同修補狀態。

應該優先處理哪些機器

建議按風險排序處理：

多使用者伺服器和共享主機。
有普通 shell 帳號的跳板機、教學機、開發機。
CI runner、建置機、託管平台宿主機。
容器宿主機和虛擬化宿主機，尤其是不完全可信 workload 共存的環境。
公開服務機器，雖然漏洞需要本地存取，但一旦 Web/RCE/弱密碼帶來低權限落點，風險會疊加。

純單使用者桌面環境風險相對低一些，但仍建議隨系統更新修復。原因很簡單：本地低權限程式碼執行在桌面上並不少見，瀏覽器、開發工具、腳本和第三方軟體都可能成為落點。

修復建議

首選方案是安裝發行版提供的修復核心並重新啟動。

不同發行版命令不同，原則相同：

更新軟體源中繼資料。
安裝包含 CVE-2026-46333 修復的 kernel 套件。
重新啟動進入新核心。
用 uname -r 和發行版安全公告核對目前執行中的核心是否已修復。

AlmaLinux 公告中提到，生產倉庫已推出修復核心，使用者可以執行常規 dnf upgrade 並重啟。Debian tracker 也列出了多個分支的 fixed versions。

需要注意：只安裝新 kernel 套件但不重啟，舊核心仍在執行，漏洞仍然存在。

臨時緩解：收緊 ptrace_scope

如果暫時不能重啟，可以先收緊 Yama 的 ptrace_scope。

Qualys 在 oss-security 後續回覆中確認，將 /proc/sys/kernel/yama/ptrace_scope 設定為 2（admin-only attach）或 3（no attach）可以阻止他們已知的公開利用路徑。但他們也說明，理論上可能存在其他利用方式，所以這只是緩解，不是修復。

臨時設定可以用：

`1`	`sudo sysctl -w kernel.yama.ptrace_scope=3`

持久化可以寫入 sysctl 設定：

`1`	`echo 'kernel.yama.ptrace_scope = 3' \| sudo tee /etc/sysctl.d/99-ssh-keysign-pwn.conf`

ptrace_scope=3 會停用 ptrace attach，可能影響 gdb、strace -p 等除錯場景。如果生產環境需要除錯，可以評估使用 2。無論選哪一個，都應盡快安排核心升級和重啟。

是否需要輪換 SSH 主機金鑰

如果機器在漏洞公開前後存在以下情況，建議保守處理：

有不可信本地使用者。
有共享主機或容器/CI 多租戶環境。
有 Web 漏洞、弱密碼、供應鏈腳本等可能給攻擊者本地落點。
日誌中出現可疑本地程序、異常除錯行為或公開 PoC 檔案。
機器在修復前暴露了較長時間。

保守處置包括：

修復並重啟後輪換 SSH host keys。
更新已知主機指紋管理系統。
通知依賴該主機指紋的自動化系統。
檢查 SSH 連線告警，避免誤把合法指紋變化當成中間人攻擊，或反過來忽略真實風險。

如果懷疑 /etc/shadow 已外洩，還應評估密碼重設、禁止弱密碼、檢查是否存在可離線破解的舊雜湊。

需要監控什麼

這類漏洞利用窗口很短，傳統日誌未必能完整記錄。但仍可以關注：

普通使用者目錄下是否出現 ssh-keysign-pwn、chage_pwn 或類似 PoC 檔案。
可疑編譯行為，例如短時間內編譯陌生 C 程式。
異常存取 /etc/ssh/ssh_host_*_key、/etc/shadow 的跡象。
異常 pidfd_getfd、ptrace、除錯器相關行為。
SSH 主機指紋被外部系統回報異常。

這些訊號不能證明一定被利用，也不能證明沒有被利用。真正的優先事項仍然是補丁、重啟、憑證輪換和風險隔離。

常見誤區

第一個誤區：它不是 OpenSSH 遠端漏洞。名字裡有 ssh-keysign，但根因在 Linux kernel 的 ptrace 存取檢查邏輯，不是 sshd 遠端認證流程。

第二個誤區：沒有本地使用者就完全沒風險。漏洞確實需要本地執行條件，但很多真實攻擊鏈會先透過 Web 服務、CI、腳本、弱密碼或容器逃逸前置步驟取得低權限本地落點。

第三個誤區：設定 ptrace_scope 就夠了。它是臨時緩解，不是根本修復。核心更新和重啟仍然需要做。

第四個誤區：只要沒被拿 root 就沒事。SSH 主機私鑰和 /etc/shadow 的外洩本身就足以導致後續橫向移動、主機偽裝和離線破解風險。

處置清單

建議按這個順序執行：

盤點受影響 Linux 主機，特別是多使用者和共享環境。
查看發行版官方安全公告，確認 fixed kernel 版本。
安裝修復核心並重啟。
暫時不能重啟的機器，先設定 kernel.yama.ptrace_scope=2 或 3。
修復後核對正在執行的核心版本。
對高風險機器輪換 SSH host keys。
如果懷疑 /etc/shadow 外洩，評估密碼重設和帳號稽核。
檢查是否存在公開 PoC、異常編譯和可疑本地除錯行為。

總結

ssh-keysign-pwn（CVE-2026-46333）是一個本地資訊外洩漏洞，根因在 Linux kernel __ptrace_may_access() 相關邏輯。它不需要遠端直接打進來，也不直接給 root shell，但可以讓低權限本地使用者讀取高價值敏感檔案，這使它在多使用者、共享主機、CI 和容器宿主環境中非常值得警惕。

最可靠的修復是升級到發行版提供的修復核心並重啟。ptrace_scope=2/3 可以作為臨時緩解，但不能替代補丁。已經暴露在風險窗口中的關鍵主機，還應考慮 SSH 主機金鑰輪換和密碼風險評估。

參考連結：

CVE-2026-42945 怎麼排查？Nginx Rift 漏洞觸發條件、版本檢查與升級建議

Fri, 15 May 2026 17:55:42 +0800

CVE-2026-42945 是 NGINX Open Source 和 NGINX Plus 中的一個安全漏洞，外界也把它稱為 Nginx Rift。它出現在 ngx_http_rewrite_module，漏洞類型是 heap-based buffer overflow。

這類新聞很容易被寫成「潛伏 18 年」「不用密碼遠端控制」「三成伺服器中招」。這些說法有傳播性，但看補丁和 NVD 描述時，最好把風險拆開看：它確實嚴重，也確實不需要登入帳號；但並不是所有 Nginx 實例都會自動被接管，觸發需要特定 rewrite 設定和請求條件。

先看官方描述

NVD 對 CVE-2026-42945 的描述可以概括為：

影響 NGINX Plus 和 NGINX Open Source。
漏洞位於 ngx_http_rewrite_module。
當 rewrite 指令後面跟著 rewrite、if 或 set 指令，並且使用未命名的 PCRE 捕獲組，例如 $1、$2，同時替換字串裡包含問號 ? 時，可能觸發問題。
未認證攻擊者可以傳送構造請求觸發漏洞。
結果可能是 NGINX worker 程序發生 heap buffer overflow 並重啟。
如果系統關閉了 ASLR，存在程式碼執行可能。

F5 作為 CNA 給出的評分是：

CVSS v4.0：9.2，Critical。
CVSS v3.1：8.1，High。
CWE：CWE-122 Heap-based Buffer Overflow。

所以，這不是普通的「設定寫錯導致 404」問題，而是 Nginx 官方安全修復範圍內的記憶體安全漏洞。

哪些說法需要降溫

第一，「不用密碼」基本可以理解為未認證攻擊。也就是說，攻擊者不需要登入 Nginx 後台，不需要拿到 SSH，也不需要應用系統帳號。但這不等於任何公網 Nginx 都能被隨手接管。

第二，「直接遠端控制」要看條件。官方描述裡更穩妥的說法是：漏洞可導致 worker 程序重啟；在 ASLR 關閉的系統上，程式碼執行是可能結果。對啟用了 ASLR、發行版編譯加固完整、執行權限受限的環境，風險路徑會更複雜。

第三，「30% 伺服器中招」不能簡單等同於「所有 Nginx 市占率都是漏洞暴露面」。真正暴露要同時看版本、是否啟用受影響模組、是否存在特定 rewrite 設定、發行版是否已經回補補丁，以及 Nginx 執行環境的加固狀態。

更準確的判斷方式是：只要你在生產環境執行 Nginx，就應該盡快檢查；但不要只按標題裡的比例判斷自己是否中招。

受影響範圍怎麼判斷

從 nginx.org 發布資訊看，2026 年 5 月 13 日發布的 nginx-1.30.1 stable 和 nginx-1.31.0 mainline 包含多項安全修復，其中包括 ngx_http_rewrite_module 的 buffer overflow，也就是 CVE-2026-42945。

如果你使用官方 Nginx 原始碼或官方套件，可以優先關注：

NGINX Open Source stable：升級到 1.30.1 或之後版本。
NGINX Open Source mainline：升級到 1.31.0 或之後版本。
NGINX Plus：查看 F5 對應分支的修復版本。

如果你使用 Debian、Ubuntu、RHEL、AlmaLinux、Rocky Linux、Alpine、容器映像、Plesk、控制面板、Ingress Controller 或雲廠商託管元件，不要只看 nginx -v 裡的上游版本號。很多發行版會把安全補丁 backport 到舊版本套件裡，版本號看起來舊，但補丁可能已經合入。

一分鐘判斷是否需要緊急處理

可以先按下面幾個問題快速分級：

這台 Nginx 是否直接暴露在公網，或者位於 API Gateway、反向代理、負載均衡、Ingress 入口層？
是否使用官方 Nginx 套件、原始碼編譯套件、第三方面板、容器映像，且還沒有確認 CVE-2026-42945 修復狀態？
設定裡是否存在複雜 rewrite 規則，尤其是連續 rewrite、if、set，以及 $1、$2 這類未命名捕獲組？
是否存在把請求路徑、查詢參數或使用者可控輸入帶入 rewrite 目標的場景？
系統加固是否較弱，例如 ASLR 被關閉、worker 權限過高、容器權限過寬？

如果前兩項命中，並且 rewrite 設定還沒有排查，建議按高優先級處理。公網入口、共享環境、Kubernetes Ingress、邊緣代理和承載登入/API 流量的 Nginx，應該優先升級或替換到確認修復的套件。

Debian / Ubuntu / RHEL / Alpine 如何確認修復

發行版使用者不要只看 nginx -v。Debian、Ubuntu、RHEL、AlmaLinux、Rocky Linux、Alpine 這類系統經常把安全補丁回補到穩定分支，表面版本號可能仍然低於 nginx.org 的 1.30.1 或 1.31.0。

Debian / Ubuntu 可以優先看安全公告、套件 changelog 和可升級列表：

nginx -v
nginx -V
apt list --upgradable | grep nginx
apt changelog nginx | grep -i "CVE-2026-42945"

RHEL / AlmaLinux / Rocky Linux 可以看安全更新和套件變更記錄：

1
2

yum updateinfo list security | grep -i nginx
rpm -q --changelog nginx | grep -i "CVE-2026-42945"

Alpine 可以檢查目前套件版本和安全分支更新：

1
2

apk info -v nginx
apk version -v nginx

如果套件管理器、發行版安全公告或廠商 advisory 明確寫明已修復 CVE-2026-42945，即使上游版本號看起來不新，也可以按「已回補修復」處理。反過來，如果只是版本號較高但來源不明，仍然要確認建置日期和補丁來源。

容器映像與 Ingress Controller 怎麼查

容器環境要檢查映像裡的 Nginx，而不是只看宿主機。先確認映像實際內建版本：

1
2

docker run --rm your-nginx-image nginx -v
docker run --rm your-nginx-image nginx -V

還要看基礎映像是否更新過。如果映像基於 Debian、Ubuntu、Alpine 或發行版套件建置，判斷方式應回到對應發行版的安全公告和套件 changelog。只重啟舊映像沒有意義，映像本身需要重新建置或替換。

Kubernetes Ingress 需要同時確認三件事：

Ingress Controller 專案是否發布了針對 CVE-2026-42945 的 advisory 或修復版本。
目前叢集執行的 controller 映像 digest 是否已經更新，而不是只改了 tag。
controller 內建 Nginx 版本、建置參數和模板設定是否仍然包含高風險 rewrite 規則。

可以先看執行中的映像：

1
2

kubectl -n ingress-nginx get pods -o wide
kubectl -n ingress-nginx describe pod <pod-name> | grep -i image

如果使用雲廠商託管 Ingress 或網關，還要查對應雲服務公告。託管元件通常不是使用者自己 apt upgrade 能解決的，需要等待廠商修復或切換到已修復版本。

rewrite 設定重點排查哪些寫法

這個漏洞和 rewrite 設定有關，排查時可以先搜尋 Nginx 設定：

1
2

grep -R "rewrite" /etc/nginx -n
grep -R "\\$[0-9]" /etc/nginx -n

重點關注類似模式：

`1`	`rewrite ^/old/(.*)$ /new/$1? permanent;`

這裡的 $1、$2 這類未命名捕獲組，以及替換目標中的 ?，是官方描述裡的關鍵條件之一。排查時尤其關注下面幾類寫法：

一個 rewrite 後面緊跟另一個 rewrite、if 或 set。
正則裡使用 (.*)、(.+) 這類寬泛捕獲，並在目標裡用 $1、$2。
rewrite 目標裡帶 ?，用於拼接或丟棄查詢參數。
rewrite 輸入來自公網路徑、Host、URI、參數或上游可控值。
面板、網關、Ingress 註解或模板自動生成的 rewrite 規則。

如果短時間內無法升級，可以先做臨時緩解：

減少複雜 rewrite 規則。
把未命名捕獲組改成更清晰的命名捕獲。
避免在替換字串裡拼接不必要的 ?。
對高風險入口加 WAF 或反向代理規則。
確認系統啟用了 ASLR。
降低 Nginx worker 執行權限，確認 systemd sandbox、SELinux/AppArmor 等加固狀態。

這些只是緩解，不是替代補丁。

修復優先級

建議按暴露面排序：

公網入口 Nginx。
反向代理、API Gateway、邊緣網關。
多租戶環境裡的 Nginx。
Kubernetes Ingress Controller。
Plesk、面板工具、雲市場映像等自帶 Nginx 的元件。
內網但承載關鍵業務的 Nginx。

升級後如何驗證：nginx -t、reload、worker 狀態

更新後不要只看套件管理器提示成功，還要確認設定、程序和實際二進位都已經切換。先驗證設定：

`1`	`nginx -t`

確認沒有錯誤後再平滑載入：

`1`	`systemctl reload nginx`

如果套件升級涉及二進位替換，建議確認舊 worker 已退出：

`1`	`ps aux \| grep nginx`

也可以查看主程序啟動時間和二進位路徑，確認執行中的服務不是舊程序繼續駐留。必要時安排維護窗口重啟服務，避免舊 worker 或舊容器繼續處理請求。

容器和 Ingress 環境還要確認新映像已經真正滾動完成：

1
2

kubectl -n ingress-nginx rollout status deployment/<deployment-name>
kubectl -n ingress-nginx get pods -o wide

驗證重點不是「命令執行過」，而是「線上流量已經由包含修復的 Nginx 程序承載」。

不要忽略同批次 Nginx 修復

nginx.org 在同一天發布的 1.30.1 和 1.31.0 不只修復了 CVE-2026-42945。發布資訊還提到 HTTP/2 request injection、SCGI/uWSGI buffer overread、charset module buffer overread、HTTP/3 address spoofing、OCSP resolver use-after-free 等問題。

這意味著生產環境不應該只針對單個 CVE 做臨時規則，而是應該把 Nginx 這一輪安全更新當成一次整體升級來處理。

小結

CVE-2026-42945 的關鍵點不是「所有 Nginx 都會被秒控」，而是：一個長期存在於 rewrite 模組裡的記憶體安全漏洞，在特定設定下可被未認證請求觸發，最直接後果是 worker 崩潰重啟；在 ASLR 關閉等較弱環境下，程式碼執行風險更高。

對維運來說，處理順序很簡單：

確認 Nginx 來源和版本。
查看發行版、F5、nginx.org 或雲廠商公告。
盡快升級到包含修復的版本或發行版安全套件。
排查複雜 rewrite 設定，尤其是 $1、$2 和 ? 組合。
確認 ASLR、權限隔離和服務重載狀態。

標題可以嚇人，修復要冷靜。先確認暴露面，再升級，再回頭清理高風險 rewrite 規則。

參考連結

Dirty Frag、Copy Fail 與 Fragnesia：近期三個 Linux 本地提權漏洞對比

Fri, 15 May 2026 13:24:04 +0800

最近 Linux 核心連續出現幾個高關注度的本地提權漏洞：Dirty Frag、Copy Fail 和 Fragnesia。它們看起來像一組「同類事件」，因為最終效果都很接近：低權限本地使用者可能把權限提升到 root。

但從維運處置角度看，不能把它們混成一個漏洞。三者的入口模組、觸發路徑、緩解方式和補丁節奏都不同。更準確的理解是：它們暴露了 Linux 核心在「頁面快取、splice、socket buffer、加密路徑」這些複雜交界處的共同風險。

本文只做風險和處置分析，不展開可復現利用步驟。

三個漏洞分別是什麼

Dirty Frag：CVE-2026-43284

Dirty Frag 主要指向 Linux 核心網路路徑裡的頁面快取寫入問題。公開資料中，它通常和兩個問題一起討論：xfrm-ESP 側的 CVE-2026-43284，以及 rxrpc 側的 CVE-2026-43500。

其中 CVE-2026-43284 與 ESP 處理共享 skb fragment 時的原地解密有關。問題的關鍵不是攻擊者直接修改磁碟檔案，而是讓核心在不該寫的共享頁面上發生寫入，進而影響頁面快取裡的檔案內容。

維運上最需要記住的是：Dirty Frag 觸達的是 esp4、esp6、rxrpc 這一組核心模組和網路子系統路徑。它和 IPsec、ESP、RxRPC 相關，臨時緩解也會圍繞這些模組展開。

Copy Fail：CVE-2026-31431

Copy Fail 是 Theori / Xint Code 披露的 Linux 核心本地提權漏洞。它的入口不在 IPsec 網路路徑，而在核心使用者態加密 API 的 algif_aead / AF_ALG 相關路徑。

公開說明中提到，它源於 2017 年引入的一處原地最佳化：某些情況下，核心沒有按預期複製資料，而是把頁面快取頁放進可寫目標路徑裡。攻擊者可以借助 AF_ALG 與 splice() 組合，對頁面快取支援的頁面做小範圍可控寫入。

它的風險點在於可利用性很強，而且影響面跨多個主流發行版。和 Dirty Frag 不同，Copy Fail 的臨時緩解重點是限制或禁用 algif_aead，以及在容器和 CI 環境中限制 AF_ALG socket。

Fragnesia：CVE-2026-46300

Fragnesia 是 V12 Security 披露的另一個 Linux 核心本地提權漏洞，和 Dirty Frag 屬於相近攻擊面。它不是 Dirty Frag 的同一個 bug，但仍然圍繞 IPsec ESP / rxrpc 相關模組，以及頁面快取寫入效果展開。

AlmaLinux 的說明把它定位為同一程式碼區域裡的第三個本地 root 問題。其關鍵點在於 skb_try_coalesce() 在合併 socket buffer 片段時沒有正確保留共享 fragment 標記，導致後續 XFRM ESP-in-TCP 接收路徑可能在外部頁面快取頁上做原地解密。

也就是說，Fragnesia 和 Dirty Frag 更接近：兩者都繞著 esp4、esp6、rxrpc、skb fragment、ESP 解密路徑轉。它們的臨時緩解也高度重疊。

相同點：為什麼都危險

這三個漏洞的共同點不是「程式碼位置完全一樣」，而是攻擊結果和風險模型非常像。

第一，它們都是本地提權。攻擊者通常需要先在機器上取得普通使用者程式碼執行能力，然後再把權限提升到 root。對單使用者桌面來說，它不是遠端一鍵入侵；但對多使用者伺服器、CI runner、容器宿主機、共享開發機和暴露 SSH 的 VPS 來說，低權限入口並不罕見。

第二，它們都和頁面快取寫入有關。攻擊者不一定永久改寫磁碟檔案，而是影響記憶體中的頁面快取副本。這會讓傳統檔案完整性檢查變得不夠可靠：磁碟 hash 可能正常，但執行路徑讀到的頁面快取內容已經被污染。

第三，它們都偏向確定性邏輯漏洞，而不是傳統意義上很吃時序的競爭條件。公開資料多次強調這類漏洞不依賴贏得 race condition。對防守方來說，這意味著「利用成功率」不能按老經驗低估。

第四，它們都放大了容器和自動化執行環境的風險。容器內的低權限程式碼、CI 任務、建置腳本、第三方外掛，一旦能觸達宿主核心相關介面，就可能把漏洞從「本地問題」變成「平台問題」。

不同點：不要用一個補丁思路套全部

三者最大的區別在入口模組。

Copy Fail 的關鍵入口是 algif_aead / AF_ALG，屬於核心使用者態加密 API。它的臨時防護重點是禁用或限制 algif_aead，以及用 seccomp 阻斷容器裡建立 AF_ALG socket。

Dirty Frag 的關鍵入口在 xfrm-ESP 和 rxrpc。它更接近網路協定和 socket buffer 處理路徑，臨時防護通常會考慮禁用 esp4、esp6、rxrpc。但這可能影響 IPsec、VPN、隧道或相關網路能力。

Fragnesia 的入口也在 Dirty Frag 相近區域，但具體問題落在 skb_try_coalesce() 沒有保留共享 fragment 標記。它更像是 Dirty Frag 風險面裡的另一個分支，而不是 Copy Fail 的加密 API 問題。

所以，不能因為已經處理了 Copy Fail，就認為 Dirty Frag 和 Fragnesia 也被覆蓋；也不能因為禁用了 esp4 / esp6，就認為 Copy Fail 自動消失。它們需要分別確認補丁狀態和緩解策略。

影響範圍該怎麼判斷

判斷這類漏洞是否受影響，不要只看發行版名字，也不要只看核心大版本號。發行版會回合補丁，雲廠商會維護自己的核心分支，企業發行版還可能有額外 backport。

更穩妥的順序是：

先看發行版安全公告和核心套件 changelog。
再核對 CVE 是否已被目前核心套件修復。
對雲主機、容器宿主機和 CI 節點，額外關注雲廠商或平台方公告。
對臨時緩解，確認業務是否依賴對應模組。
完成核心升級後安排重啟，確保實際執行核心已經切換。

這一步最容易踩坑的是「套件已經更新，但機器還沒重啟」。核心漏洞不是普通使用者態服務升級，安裝新套件之後，舊核心仍可能繼續執行。

維運優先級

這些漏洞最該優先處理的機器，不是「所有 Linux 平均排隊」，而是低權限程式碼最容易出現的地方。

優先級最高的環境包括：

多使用者登入伺服器
CI / CD runner
建置機和製品打包機
容器宿主機和 Kubernetes 節點
共享開發機
暴露 SSH 的雲主機和 VPS
執行第三方腳本、外掛、任務佇列的平台
有 Web 漏洞、弱密碼或歷史入侵痕跡的機器

相對封閉、單使用者、沒有外部程式碼執行入口的機器，風險仍然存在，但處置順序可以排在後面。

臨時緩解應該怎麼理解

臨時緩解不是補丁替代品。它的價值是幫你在無法立刻重啟或等待發行版補丁時降低暴露面。

對 Copy Fail，重點關注 algif_aead 和 AF_ALG。如果業務沒有使用核心 AF_ALG 加密介面，可以評估禁用相關模組；容器環境則應優先檢查 seccomp 策略，避免不受信任工作負載隨意建立對應 socket。

對 Dirty Frag 和 Fragnesia，重點關注 esp4、esp6、rxrpc。如果系統不依賴 IPsec ESP、相關 VPN、隧道或 RxRPC，可以評估臨時禁用。但生產環境不要盲目執行，因為這些模組可能影響真實網路業務。

最終仍然要回到核心更新。臨時緩解只能減少攻擊面，不能證明系統已經徹底安全。

這三個漏洞說明了什麼

這組漏洞真正值得警惕的地方，不只是 CVE 數量，而是它們都集中在核心高複雜度路徑：零拷貝、splice、socket buffer、頁面快取、加密介面、協定堆疊最佳化。

這些路徑的共同特點是效能收益很大，但所有權邊界也更難維護。一個 fragment 是否共享、一個頁面是否還能原地寫、一個最佳化是否真的只是減少複製，都會變成安全邊界的一部分。

對安全團隊和維運團隊來說，結論很實際：

本地提權漏洞要按「已有低權限入口會被放大」處理。
容器不是核心漏洞的天然隔離邊界。
檔案完整性檢查不能只看磁碟內容。
CI、建置機、外掛平台要當成高優先級資產。
核心補丁需要驗證「已安裝」和「已執行」兩個狀態。

小結

Dirty Frag、Copy Fail 和 Fragnesia 都是近期 Linux 本地提權風險裡的高優先級事件，但它們不是同一個漏洞的三個名字。

Copy Fail 走的是 algif_aead / AF_ALG 加密介面路徑；Dirty Frag 走的是 xfrm-ESP 與 rxrpc 相關路徑；Fragnesia 則在 Dirty Frag 相近攻擊面上，透過 skb fragment 標記處理問題再次觸發頁面快取寫入風險。

處置上，最穩妥的做法是：按發行版公告升級核心並重啟；對無法立即升級的系統，分別按漏洞入口評估臨時禁用模組或收緊 seccomp；對多租戶、CI、容器宿主機和共享開發環境優先處理。

參考資料：

Theori Copy Fail 說明：https://github.com/theori-io/copy-fail-CVE-2026-31431
CERT-EU Copy Fail 安全公告：https://cert.europa.eu/publications/security-advisories/2026-005/
AlmaLinux Dirty Frag 說明：https://almalinux.org/blog/2026-05-07-dirty-frag/
AlmaLinux Fragnesia 說明：https://almalinux.org/blog/2026-05-13-fragnesia-cve-2026-46300/
V12 Security Fragnesia PoC 說明：https://github.com/v12-security/pocs/tree/main/fragnesia

2026 年 5 月 Edge 爆高危漏洞 CVE-2026-2441：造訪惡意網頁可能被遠端執行程式碼

Wed, 06 May 2026 08:30:17 +0800

Microsoft Edge 近期發布了多輪安全更新，修復來自 Chromium 專案及 Edge 元件的多個安全問題。其中，CVE-2026-2441 已被 Chromium 團隊報告已遭在野利用，Microsoft Edge 的穩定版和延伸穩定版均已提供修復。

如果日常使用 Edge 瀏覽網頁，尤其是在 Windows 裝置上處理登入帳號、郵件、網銀、後台管理或企業系統，建議盡快確認瀏覽器已經升級到最新版本。

漏洞風險

CVE-2026-2441 屬於已被攻擊者關注並利用的高風險漏洞。瀏覽器漏洞的典型利用方式，是誘導使用者造訪包含特製內容的網頁，觸發渲染引擎或相關元件缺陷。

在實際攻擊中，這類漏洞可能帶來以下風險：

執行惡意程式碼，或配合其他漏洞進一步突破沙箱限制。
繞過部分安全限制，擴大攻擊面。
竊取瀏覽器中的敏感資料、工作階段資訊或頁面內容。
造成瀏覽器當機、頁面異常或阻斷服務。

需要注意的是，官方通常不會在修補程式剛發布時公開完整攻擊細節，避免漏洞被更多攻擊者重現。因此，對一般使用者來說，最有效的防護措施就是及時更新。

受影響範圍

Microsoft Edge 基於 Chromium，相關漏洞會影響多個平台上的 Edge 版本，包括 Windows、macOS、Linux 以及行動端版本。只要瀏覽器版本低於包含修復的版本，就存在風險。

根據 Microsoft Edge 安全更新發行說明，2026 年 2 月 14 日發布的 Edge 穩定通道 145.0.3800.58 已包含 CVE-2026-2441 修復；2026 年 2 月 17 日發布的延伸穩定通道 144.0.3719.130 也包含該修復。後續版本會繼續累積 Chromium 專案的安全修補。

截至 2026 年 5 月 6 日，Edge 安全更新頁面中最新列出的穩定通道安全版本為 2026 年 4 月 30 日發布的 147.0.3912.98。如果本機版本明顯低於這些版本，應立即更新。

立即更新 Edge

一般使用者可以按下面步驟檢查並更新：

開啟 Microsoft Edge。
在網址列輸入 edge://settings/help 並按 Enter。
等待瀏覽器自動檢查更新。
更新完成後，點擊「重新啟動」。

企業環境中，管理員應檢查端點管理策略、WSUS、Intune、群組原則或第三方修補系統，確認 Edge 更新沒有被長期延遲。對無法立即更新的裝置，應減少造訪未知網站，並優先限制高風險使用者群組的外部網頁存取。

防護建議

盡快升級 Edge，並在更新後重新啟動瀏覽器。
不要點擊來源不明的郵件連結、聊天連結和廣告跳轉。
避免在舊版本瀏覽器中造訪後台管理、支付、郵箱等敏感頁面。
保持 Windows、防毒軟體和瀏覽器擴充功能同步更新。
刪除長期不用或來源不明的瀏覽器擴充功能。

參考來源

小結

CVE-2026-2441 的重點不在於漏洞細節有多複雜，而在於它已經被報告已遭在野利用。對個人使用者和企業終端來說，最直接的處置方式是開啟 edge://settings/help，確認 Edge 已經完成更新並重新啟動。

Copy Fail 漏洞 CVE-2026-31431：Linux 核心檔案複製路徑中的容器逃逸風險

Fri, 01 May 2026 18:42:34 +0800

Copy Fail 是一個影響 Linux 核心檔案複製路徑的漏洞，編號為 CVE-2026-31431。 Bugcrowd 的分析把它稱為一個值得關注的核心級問題：在特定條件下，非特權使用者可以利用檔案複製相關邏輯觸發越權寫入，進而造成權限提升或容器逃逸。

從風險角度看，它不是普通應用層漏洞。問題發生在核心處理檔案複製和頁面快取的路徑上，因此影響面會延伸到容器、共享主機、CI/CD Runner、PaaS 平台和多租戶 Linux 環境。如果攻擊者已經能在系統裡執行低權限程式碼，漏洞就可能成為進一步突破隔離邊界的跳板。

漏洞大致發生在哪裡

Copy Fail 關聯的是 Linux 核心中的檔案複製能力。現代 Linux 提供了多種高效複製路徑，例如 copy_file_range、splice 類路徑以及不同檔案系統之間的資料複製最佳化。這些機制的目標是減少使用者態和核心態之間的資料搬運，提高大檔案複製效能。

問題在於，高效能複製路徑通常會複用頁面快取、檔案偏移、權限檢查和檔案系統回呼。如果其中某個邊界條件處理不嚴，核心可能在錯誤的權限上下文裡執行寫入，或者把本不應該被修改的資料頁暴露給攻擊者控制。

Copy Fail 的核心風險可以概括為：

攻擊者不需要 root 權限；
攻擊入口來自常見檔案複製能力；
影響點在核心態；
在容器環境裡，漏洞可能繞過命名空間和掛載隔離；
成功利用後可能寫入宿主機上不應被容器修改的內容。

這也是它被重點討論的原因。容器安全依賴 Linux 核心提供隔離能力，一旦核心路徑本身出現越權寫入，容器邊界就會變得脆弱。

為什麼容器場景更敏感

容器並不是虛擬機。容器內行程和宿主機共享同一個 Linux 核心，只是透過 namespace、cgroup、capability、seccomp、AppArmor/SELinux 等機制做隔離。

如果漏洞發生在使用者態服務裡，通常只影響某個容器或某個行程。但如果漏洞發生在核心裡，尤其是可以被非特權使用者觸發的核心漏洞，攻擊者可能從容器內部影響宿主機。

Copy Fail 的危險點就在這裡。很多平台允許使用者提交建置任務、執行腳本、啟動容器或執行外掛。攻擊者只要能在容器裡執行程式碼，就可能嘗試利用核心檔案複製路徑突破隔離。

高風險環境包括：

Kubernetes 叢集中的不可信工作負載；
CI/CD 平台的共享 Runner；
允許使用者上傳程式碼執行的沙箱平台；
多租戶 Linux 主機；
容器化 PaaS；
執行第三方外掛或擴充的系統。

如果這些環境裡的核心版本處於受影響範圍，而且缺少額外限制，風險就會明顯升高。

受影響範圍要看核心補丁狀態

這類漏洞的判斷不能只看發行版名稱。同一個 Ubuntu、Debian、RHEL、Fedora 或 Arch 版本，是否受影響取決於目前實際執行的核心套件，以及發行版是否已經回補補丁。

排查時應優先確認三件事：

目前執行核心版本；
發行版安全公告是否提到 CVE-2026-31431；
雲端廠商或託管平台是否已經完成宿主機核心修復。

可以先在系統上確認核心版本：

`1`	`uname -a`

然後查看發行版安全公告、核心 changelog 或雲端平台公告。不要只根據主版本號判斷是否安全，因為很多企業發行版會把安全補丁回補到舊版本核心裡。

臨時緩解思路

最可靠的修復方式仍然是更新核心。但在補丁無法立刻部署的環境裡，可以先降低暴露面。

常見緩解方向包括：

禁止不可信使用者執行特權容器；
避免給容器掛載敏感宿主機路徑；
收緊容器 capability，尤其不要隨意授予 CAP_SYS_ADMIN；
使用 seccomp、AppArmor 或 SELinux 限制危險系統呼叫和檔案存取；
將不可信工作負載遷移到隔離更強的虛擬機；
對 CI/CD Runner 做按任務銷毀，避免長期複用同一宿主機；
監控異常檔案寫入、權限變更和容器逃逸跡象。

這些措施不能替代補丁。它們的作用是降低攻擊成功率和影響面，特別是在補丁發布到生產環境之前爭取緩衝時間。

修復優先級

建議按環境風險排序處理。

優先修復：

對外提供容器執行能力的平台；
執行不可信程式碼的 CI/CD 節點；
多租戶 Kubernetes 節點；
有使用者自定義外掛或腳本執行能力的系統；
共享開發機、教學機、實驗平台。

相對低優先級：

單使用者桌面；
只執行可信服務的內網主機；
已經使用虛擬機隔離不可信程式碼的環境。

即便風險較低，也建議隨發行版更新核心。核心漏洞常常會被組合進更複雜的攻擊鏈裡，拖延補丁沒有太多收益。

給維運團隊的檢查清單

可以按下面順序處理：

盤點所有 Linux 主機和容器節點；
標記會執行不可信程式碼的機器；
檢查目前核心版本和發行版安全公告；
優先更新高風險節點；
對無法立即更新的節點啟用臨時隔離策略；
檢查容器執行時設定，移除不必要的特權和宿主機掛載；
更新後重啟節點，確認新核心已經實際生效；
保留變更記錄，方便後續稽核。

核心套件安裝完成並不代表系統已經執行在新核心上。更新後必須重啟，並再次確認：

`1`	`uname -a`

小結

Copy Fail / CVE-2026-31431 的重點不是某個應用崩潰，而是 Linux 核心檔案複製路徑中的權限邊界問題。它讓非特權程式碼有機會觸碰更高權限的資料寫入路徑，因此在容器和多租戶環境裡尤其值得重視。

處理這類漏洞時，最重要的是兩件事：

盡快跟進發行版或雲端廠商提供的核心補丁；
在補丁部署前限制不可信程式碼、特權容器和敏感宿主機掛載。

對個人桌面來說，它可能不是馬上需要恐慌的問題。但對執行容器平台、CI/CD、沙箱和共享主機的團隊來說，應該把它當作高優先級核心安全更新處理。

參考來源：