CUPS 漏洞如何颠覆我对 Linux 服务器安全的认知

那年我刚接手公司的生产服务器集群，清一色 Rocky Linux 9，内核 5.14跑着 K8s，所有我认知里“安全”的样子它都有了：

SELinux 开着，firewalld 跑着，root 登录关了，SSH 密钥 + 两步验证，密码强度正则恨不得精确到小数点后八位。

直到某天凌晨 2 点，我在排查一个奇怪的系统资源占用时，顺手敲了一行：

ps aux | grep cups

屏幕上跳出了一行我从未在意过的进程：

root  0.0  0.1  /usr/sbin/cupsd -l

CUPS。Common Unix Printing System。

一个打印服务。跑在生产 K8s 集群的 master 节点上。以 root 身份。

那一刻我愣住了。

CUPS 是什么？为什么它在我服务器上

CUPS 是 Linux 和类 Unix 系统标准的开源打印系统。大多数发行版在安装时默认就把它装上了——Ubuntu、Debian、Rocky Linux、CentOS，无一例外。

你可能会问：服务器要打印什么？

好问题。我也问过自己。

现实是：很多服务器上装 CUPS 纯粹是“历史遗留”。一些邮件系统用它生成 PDF 报告，一些监控平台用它输出报表，某些 ERP 系统甚至把它作为内部工作流的一部分。你不用的功能，不代表它不在跑。它只是安静地躺在那里，等着被人发现。

而问题恰恰就在这里：CUPS 默认配置会把打印服务暴露在网络接口上。

如果你在 Rocky Linux 9 上执行：

netstat -tlnp | grep 631
# 或者
ss -tlnp | grep 631

很可能会看到 cupsd 正在监听 631 端口（IPP，Internet Printing Protocol），等待着来自网络任意角落的请求。

这就是那把“房间里的大象”。

2026 年 4 月：那把大象突然活了

2026 年 4 月 3 日，OpenPrinting 官方披露了一组高危漏洞，其中最严重的两个是：

CVE-2026-34980：OpenPrinting CUPS 远程代码执行漏洞，CVSS 9.8，已公开 PoC。

CVE-2026-34990：OpenPrinting CUPS 认证绕过漏洞，CVSS 7.8，本地提权，PoC 同样已公开。

4 月 9 日，奇安信CERT正式发布安全风险通告，并宣布已成功复现这两个漏洞。

这意味着什么？意味着全球千千万万个 Linux 服务器——那些你以为“固若金汤”的生产机器——突然多了一条敞开的攻击路径。

而很多人，甚至还不知道 CUPS 跑在自己服务器上。

我花了一晚上研究漏洞原理，发现比我想象的更可怕

先说 CVE-2026-34980。

CUPS 在处理打印任务属性时，存在输入验证缺陷。具体来说，系统在序列化（serialize）和反序列化（deserialize）打印选项的过程中，没有对特殊字符做正确的转义处理。

这听起来像是个“打印相关的小问题”，但实际上：攻击者只需要构造一个包含恶意载荷的打印请求，发到目标服务器的 631 端口，就可以在 cupsd 进程上下文中执行任意代码。

而且——不需要任何认证。

受影响版本：OpenPrinting CUPS ≤ 2.4.16。

你不需要开启什么“危险功能”，不需要开放额外端口，不需要任何奇怪配置。只要 cupsd 进程在跑，只要它监听在网络接口上，你就是目标。

再说 CVE-2026-34990。

如果说 CVE-2026-34980 是“远程破门”，那 CVE-2026-34990 就是“本地提权”。

CUPS 在处理本地打印机创建和认证令牌管理时，逻辑存在缺陷。系统创建临时打印机时，对设备 URI 的校验存在竞态窗口——安全检查发生在“临时状态清除”之后，而不是之前，导致本地的低权限用户可以绕过安全策略，创建并覆盖任意文件。

具体利用路径是：低权限用户创建一个指向本地文件的设备 URI（比如 file:/etc/sudoers），利用令牌校验缺陷覆盖 /etc/sudoers.d/ 下的文件，给自己加上 sudo 免密权限——普通用户直接 root。

我看到某安全研究员贴出的 PoC，寥寥几行代码，一杯咖啡的时间，一台生产服务器的控制权就换了主人。

而这一切的起点，只是因为系统默认安装了“一个打印服务”。

干了这么多年运维，我开始重新审视“安全”这两个字

说起来惭愧，我运维 Linux 服务器快十年了，一直对 Linux 的安全模型有一种近乎盲目的信任。

为什么？

因为 Linux 有用户权限隔离。因为 sudo 需要密码。因为 root 不能远程登录。因为 SELinux/AppArmor 开着。因为……

因为有太多“因为”，让我觉得 Linux 天生就是“安全的”，而 Windows 才需要“小心翼翼”。

但 CUPS 漏洞事件狠狠打了我的脸。

Linux 的安全模型建立在“非 root 用户无法提权”这个假设上。 一旦某个默认安装的服务存在漏洞，攻击者可以通过网络（CUPS 631 端口）获得代码执行权限，再用本地提权漏洞（CUPS 34990）拿到 root——整个攻击链，从发现到拿下服务器，不超过 5 分钟。

而且，由于 CUPS 太“不起眼”了，大多数安全扫描工具默认不会把它的网络暴露列为高危项。很多运维团队的基线检查里，根本没有“CUPS 631 端口是否应该暴露”这一项。

最危险的漏洞，往往藏在最不起眼的地方。

这句话我听过无数遍，但直到我真正看见 CUPS 进程以 root 身份蹲在我的 K8s master 节点上，我才第一次真正理解了它的意思。

干了这么多年运维，我对“默认安装”这件事彻底改变了看法

过去我有一个坏习惯：服务器装好之后，只关我认为“危险”的服务的端口，剩下的一概不管。

CUPS 教会我：每一个默认安装的进程，都是一个需要被审视的潜在攻击面。

CUPS 不打印，但你不能不管。

同样的逻辑，SSH 曾经也出过 0click 漏洞（虽然不是默认配置的问题，但同样让人警醒）。systemd-networkd、D-Bus、甚至 cron——任何一个网络可达或本地可达的进程，都值得定期审视。

我的生产服务器检查清单，从那晚开始多了三条：

1. 网络暴露审计：ss -tlnp 定期跑，631、9090、11211 这些“不应该对外”的端口，是否真的收口了？

2. 默认服务清理：不用就删，不跑就停。“默认安装”不是“必须运行”的代名词。

3. CVE 情报订阅：以前觉得 CVE 是“大厂商的事”，现在知道，小团队的疏忽，同样可以被攻击者利用。建立定期关注和更新的习惯，是运维人员必备的技能。

怎么判断自己是否中招，以及如何止损

先检查版本：

# 检查 CUPS 版本
cupsd --version
# 如果版本 ≤ 2.4.16，你需要处理
# Ubuntu/Debian:
sudo apt list --upgradable | grep cups
# Rocky/CentOS/RHEL:
sudo dnf check-update cups
sudo rpm -qa | grep cups

检查 631 端口是否暴露：

# 检查 cupsd 是否监听在非 localhost 接口
ss -tlnp | grep :631
# 如果看到 0.0.0.0:631 或 :::631，说明暴露了
# 如果只看到 127.0.0.1:631，相对安全

止损第一步（立即）：

# 方案一：停止并禁用 CUPS（推荐，服务器本来就不需要打印）
sudo systemctl stop cups
sudo systemctl disable cups
# 方案二：如果确实需要 CUPS，立即封锁 631 端口
sudo firewall-cmd --permanent --add-port=631/tcp
sudo firewall-cmd --reload
# 或者用 iptables/nftables
sudo iptables -A INPUT -p tcp --dport 631 -j DROP

止损第二步（检查）：

# 检查 cupsd 相关日志是否有异常请求
sudo grep -i "ipp\|printer\|cupsd" /var/log/cups/access_log | tail -100
# 检查系统是否有新创建的 sudoers 文件
sudo cat /etc/sudoers.d/* 2>/dev/null | grep -v "^#"
sudo ls -la /etc/sudoers.d/

止损第三步（修复）：

官方补丁截至发稿时仍未正式发布（CUPS 项目维护节奏较慢），建议：

# 持续关注官方 releases 页
# https://github.com/OpenPrinting/cups/releases
# 升级到最新版本（目前暂无 >2.4.16 的正式版）
# 一旦有新版本，立即通过包管理器升级：
# Ubuntu/Debian:
sudo apt update && sudo apt upgrade cups
# Rocky/CentOS:
sudo dnf update cups

长期加固：

# 1. 强制 AppArmor/SELinux 策略限制 cupsd
# Rocky Linux 9 默认使用 SELinux，执行：
sudo semanage port -a -t cups_port_t -p tcp 631
# 确保 cupsd 在 enforcing 模式下运行
getenforce  # 应该输出 Enforcing
# 2. 如果不用打印服务，直接卸载（最干净）
sudo dnf remove cups  # Rocky/CentOS
sudo apt remove cups  # Ubuntu/Debian
# 3. 建立定期 CVE 订阅机制
# 推荐关注 OpenPrinting 安全公告：https://openprinting.github.io/

写在最后

这篇文章写到最后，我回头看了一眼我最开始在用的那台 Rocky Linux 9 服务器。

CUPS 进程还在。以 root 身份。631 端口开着。

我停掉了它。又删掉了整个 cups 包。

屏幕上只剩下一个干净的进程列表，那些“我不知道它是干什么的”进程，少了一个。

运维这件事，有时候就是这样：安全不是装了多少防火墙、开了多少 SELinux 规则，而是你有没有勇气，对着每一个“默认存在”的东西问一句——它真的应该在那里吗？

CUPS 事件给我最大的改变，不是学会打某个补丁，而是彻底颠覆了一个根深蒂固的观念：Linux 服务器默认安全。

不。安全的服务器来自持续审视，而非默认假设。 对于更多关于服务器安全和网络配置的深度讨论，你可以在云栈社区找到同行。