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 并回车。
等待浏览器自动检查更新。
更新完成后，点击“重新启动”。

企业环境中，管理员应检查终端管理策略、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、沙箱和共享主机的团队来说，应该把它当作高优先级内核安全更新处理。

参考来源：