CentOS 的漏洞漏洞问题，其实和它“稳如老狗”的漏洞名声是一体两面的。很多人选 CentOS，漏洞就是漏洞冲着它保守、不折腾、漏洞十年不换大版本来的漏洞。但恰恰是漏洞这种长周期支持策略，让漏洞的漏洞暴露窗口和修复节奏变得特别微妙。你如果翻 CentOS 的漏洞邮件列表或者 CVE 公告，会发现一个规律：上游 RHEL 发了补丁，漏洞CentOS 通常要等几天到几周才跟进。漏洞这中间的漏洞时间差，就是漏洞风险。

我印象很深的漏洞一个例子是 2021 年底的 Log4Shell。当时 RHEL 7 和 8 上的漏洞 log4j 包很快出了更新，但 CentOS 7 的镜像源里，补丁晚了差不多两天才同步。别看两天不长，那会儿扫描器满互联网跑，很多没配自动更新的 CentOS 机器就被打穿了。有人会说，那用 yum-cron 自动更新不就行了？问题在于，CentOS 的更新策略默认是“不自动重启服务”，很多关键补丁需要重启进程才生效。你半夜三点更新了 glibc，但 httpd 没重启，漏洞照样在。

另一个常被忽略的点是 CentOS 8 的提前死亡。原本说支持到 2029 年，结果 2021 年底 Red Hat 宣布 CentOS 8 在 2022 年 1 月 1 日停止更新，比原计划早了八年。那段时间我帮几个小公司做迁移，发现他们的 CentOS 8 机器还在跑着 2020 年的内核，dnf update 直接报 404。漏洞库还在更新，但官方源已经关了，你只能切到 vault.centos.org 或者第三方镜像。那些镜像同步不及时，有些 CVE 修复包压根没进去。这种“半官方”状态下的漏洞管理，比彻底停更还麻烦——你以为还能打补丁，其实打上的可能是旧包。

CentOS 7 的情况更典型。它到 2024 年 6 月 30 日才正式 EOL，但最后一年里，很多低危漏洞的修复优先级被降得很低。比如 CVE-2023-4911（Looney Tunables），RHEL 7 出了补丁，CentOS 7 的更新却拖了将近一周。我在一台测试机上手动编译过 glibc 补丁，发现 CentOS 的 SRPM 里有些构建选项和 RHEL 不一致，直接 rpm 安装会报依赖冲突。这意味着你就算拿到补丁，也不一定能平滑升级。这种“上游有、下游缺”的碎片化，是 CentOS 漏洞治理里最头疼的事。

再说说内核漏洞。CentOS 默认内核版本很老，比如 CentOS 7 长期停在 3.10.0-1160 系列。很多新披露的提权漏洞，像 Dirty Pipe（CVE-2022-0847），官方只修了 5.16+ 的内核，CentOS 7 的 3.10 根本不受影响——这算是老内核的意外好处。但反过来，像 CVE-2022-0185 这种文件系统堆溢出，3.10 内核确实中招了，CentOS 的修复方式是打 backport 补丁。backport 的代码质量和主线不一样，有时候会引入新问题。我见过一次，打完补丁后某些容器里的 overlayfs 挂载变慢，查了半天发现是补丁里的锁粒度改大了。

那普通用户怎么办？我的做法是：别指望 CentOS 的官方源能及时覆盖所有漏洞。关键业务机器，要么上 RHEL 订阅，要么转 Rocky Linux 或 AlmaLinux——它们至少承诺和 RHEL 同步。如果非要用 CentOS 7 撑到最后一刻，至少把 yum 源换成 vault，然后自己搭个内部镜像，用 cvechecker 或者 osv-scanner 定期扫。别迷信“稳定”两个字，稳定往往意味着补丁来得慢，而攻击者不会等你。

最后说个观察：CentOS 的漏洞公告邮件列表里，很多修复包的描述只有一行“Security fix for CVE-XXXX-XXXX”，没有细节。你去看对应的 RHEL errata，才会发现原来还修了另一个没公开的漏洞。这种信息不对称，让 CentOS 用户在做风险评估时天然吃亏。所以，如果你还在跑 CentOS，别只看它说了什么，多去翻翻 RHEL 的公告，那才是完整的拼图。