The 2024 CUPS vulnerabilities: what we checked on our Linux servers

About four weeks have passed since the public disclosure of the CUPS vulnerabilities at the end of September 2024, long enough for our servers to go through the same treatment as every other service we run: a quiet evening with an inventory, a checklist, and no changes until the inventory was finished. This post is that walk-through, written as we performed it, because the interesting part of a disclosed vulnerability is rarely the exploit. It is the question of why the affected service was there at all.

What was actually disclosed

On 2024-09-26 the CVE entries for three vulnerabilities in the CUPS printing stack were published: CVE-2024-47076 in libcupsfilters, CVE-2024-47175 in libppd, and CVE-2024-47176 in cups-browsed. In short, they form a chain. The browsing daemon cups-browsed listens on UDP port 631 and, as the entry for CVE-2024-47176 describes it, trusts any packet from any source. Combined with the other two findings, a crafted sequence can end in arbitrary commands executed remotely on a machine, without authentication, once a malicious printer manages to push itself onto the system.

Two details made this worth taking seriously beyond the usual advisory reading. First, the vulnerable components are not exotic: cups-browsed ships by default on many desktop distributions and survives on servers inherited from desktop installs. Second, the published vendor advisories describe patched versions and explicitly point out which deployments are not affected at all, which is exactly the kind of statement an inventory should verify instead of assuming.

Is the port even exposed on our machines

The first check on every server was the same one-liner: does anything listen on UDP 631, and from where is it reachable. ss -0ulpn answers that in five seconds. On a well-kept fleet the honest result was boring: most hosts showed nothing. A handful of machines, mostly older boxes that had begun life as workstations or that had once hosted a printing stack for convenience, showed a listener, and two of those listeners were reachable beyond the host itself because an old firewall template only filtered TCP.

That second finding is the one we keep coming back to. A service nobody ordered sat on a network path with a rule that nobody remembered writing. The CVE disclosure was the reason we noticed; the reason it was dangerous had nothing to do with printing.

Is a print service needed at all

The second question followed the first on every machine: does anything here print. On servers the honest answer is almost always no. Print queues, where they existed, had been installed as part of a base image years earlier, or during a debugging session that produced a document someone then read on the same terminal anyway.

Where no print service was needed, we stopped and disabled the relevant units: cups.service and cups-browsed.service, plus the sockets that activate them. Masking the browsing daemon is enough on systems where CUPS must stay installed for a local application but nothing should discover or advertise printers. Where a printer is genuinely required, for example on a management host, the fix is narrower: updated packages, the listener bound to loopback or the exact management network, and a firewall rule that says which hosts may talk to it instead of a default allow.

The checklist we applied

For what it is worth, this is the working checklist as it left our notes, in the order we ran it:

• Inventory: which machines run cups or cups-browsed at all, from systemctl list-units and dpkg -l or the local package equivalent.
• Exposure: does UDP 631 answer external traffic, per host and per zone. The listening socket alone is not the risk; reachability is.
• Upstream status: is the installed package at or above the patched version named in the advisories for the three 2024 CVE entries, or does the distribution backport the fix.
• Need: can the print stack be removed entirely. On most servers the answer was yes, and removal plus a config note beat every other mitigation.
• Necessity case: where printing stays, bind the services to loopback or a management network, allow exactly the hosts that need them, and re-check after the next upgrade, because package updates love to re-enable sockets you disabled.

What the episode is actually about

The core point of this whole exercise has little to do with printers. Many servers carry services nobody ever ordered, and they sit there quietly because they came in a base image, a forgotten role, or a copy-pasted bootstrap. A disclosure like the 2024 CUPS chain is a loud reason to go looking, but the habit of asking what is listening, from where, and whether anyone needs it is worth running on a schedule rather than on demand.

If you want a second opinion on exposure checks or hardening for your own fleet, the blog on this site collects the practitioner pieces behind this one, and the contact page is the fastest way to reach us.

Sources

• NVD entry CVE-2024-47076 (libcupsfilters), https://nvd.nist.gov/vuln/detail/CVE-2024-47076 (accessed 2026-11-03)
• NVD entry CVE-2024-47175 (libppd), https://nvd.nist.gov/vuln/detail/CVE-2024-47175 (accessed 2026-11-03)
• NVD entry CVE-2024-47176 (cups-browsed, RCE chain), https://nvd.nist.gov/vuln/detail/CVE-2024-47176 (accessed 2026-11-03)
• OpenPrinting advisory for cups-browsed (GHSA-rj88-6mr5-rcw8), https://github.com/OpenPrinting/cups-browsed/security/advisories/GHSA-rj88-6mr5-rcw8 (accessed 2026-11-03)