最快确认是否暴露于公开n-day漏洞的方式是直接查当前内核和软件包版本并比对已知cve列表：运行uname -r和cat /etc/os-release获取精确版本，用linux-exploit-suggester.sh -k "$(uname -r)"快速筛查高危本地提权漏洞，再分别用dpkg -l | grep polkit、rpm -q polkit、sudo --version、systemctl --version等命令验证关键用户态组件是否达到cve修复所需最低版本，并务必结合发行版官方安全公告交叉验证补丁实际生效状态。
直接查当前内核和软件包版本，比对已知 CVE 列表，是最快确认是否暴露于公开 N-Day 漏洞的方式。补丁没打 ≠ 一定被利用，但所有在野利用（in-the-wild）的 N-Day，都要求目标系统未更新对应修复版本。
确认内核与发行版精确版本
漏洞匹配依赖毫厘不差的版本号，比如 CVE-2022-0847 只影响 5.15.25 之前的内核，而 5.15.25-1ubuntu1（Ubuntu 衍生版）和 5.15.25-1.el9（RHEL 9）虽主版本相同，但补丁状态可能不同。
- 运行
uname -r获取内核版本（如5.15.0-101-generic），注意末尾的-generic或-aws等后缀也属于版本标识 - 执行
cat /etc/os-release查看ID、VERSION_ID和PRETTY_NAME，例如 Ubuntu 22.04 的VERSION_ID="22.04"，CentOS Stream 9 的ID="centos-stream" - 对 Debian/Ubuntu，用
apt list --installed | grep linux-image确认实际安装的 kernel 包名；对 RHEL/CentOS，用rpm -q kernel
用 linux-exploit-suggester 快速筛出高危 N-Day
这个脚本不依赖网络，只靠本地版本号查 CVE 映射表，特别适合离线环境或快速初筛。它输出的不是“可能有漏洞”，而是“该版本已知存在可本地提权的 exploit”。
- 下载最新版：
curl -sLO https://raw.githubusercontent.com/mzet-/linux-exploit-suggester/master/linux-exploit-suggester.sh - 赋予执行权限并运行：
chmod +x linux-exploit-suggester.sh && ./linux-exploit-suggester.sh -k "$(uname -r)" - 重点关注标为
[high]或含local root字样的条目，如CVE-2021-4034 (PwnKit)—— 这类几乎肯定未修复时就能被一键提权 - 注意它不会报告服务类漏洞（如 OpenSSH、Redis），只聚焦内核和基础用户态提权组件（polkit、sudo、systemd）
检查关键软件包是否已修复特定 CVE
内核只是冰山一角。像 polkit、sudo、glibc 这些用户态组件的 N-Day 同样高频被利用，且修复往往不升级内核，而是单独更新包。
- 查 polkit 版本及修复状态：
dpkg -l | grep polkit（Debian/Ubuntu）或rpm -q polkit（RHEL/CentOS），然后对照CVE-2021-4034要求的最低版本（0.105-26） - 查 sudo 是否为
CVE-2023-22809修复版：sudo --version输出应 ≥1.9.12p2；低于则普通用户可通过sudoedit绕过密码提权 - 别忽略
systemd：运行systemctl --version，若低于252.18（对应CVE-2023-49273），可能被滥用实现容器逃逸 - 所有查询结果必须和发行版官方安全公告比对，例如 Ubuntu 的 ubuntu.com/security 或 Red Hat 的 access.redhat.com/security/cve
验证补丁是否真正生效，而非仅版本号“看起来已更新”
有些厂商会 rebasing（基线重置）内核，即保留旧版本号但合并补丁，此时 uname -r 不变，但漏洞已修复；反之，某些第三方源打包的 kernel 可能版本号新，却漏掉关键 patch。
- 对内核漏洞，检查
/proc/sys/vm/unprivileged_userfaultfd：若值为0，说明CVE-2021-4154（userfaultfd 提权）已被禁用，即使内核版本未升 - 运行
grep -i "dirty\|pipe" /boot/config-$(uname -r)，确认CONFIG_USERFAULTFD、CONFIG_PIPE_WORKAROUNDS是否设为y或m，这是Dirty Pipe修复的关键编译选项 - 最稳妥方式：用
searchsploit搜索对应 CVE，下载 PoC（如dirty_pipe.c）在测试机上编译运行，观察是否真能复现 —— 但仅限隔离环境，切勿在生产机试
真正容易被忽略的是：很多团队只扫内核，却放任 polkit、sudo、systemd 这些用户态组件长期不更新。它们的 N-Day 利用门槛更低、检测更难、日志痕迹更少 —— 一次 pkexec 调用就可能让攻击者拿到 root，而你连进程都没看到。
