CUPS Overflows — A Critical Linux Printing Vulnerability Nobody Saw Coming

This morning, security researcher Simone Margaritelli (evilsocket) publicly disclosed a chain of vulnerabilities in CUPS — the Common Unix Printing System — that can be exploited for remote code execution on Linux systems. The vulnerabilities, tracked as CVE-2024-47176, CVE-2024-47076, CVE-2024-47175, and CVE-2024-47177, affect the cups-browsed service and can be triggered without authentication on systems where the service is running and reachable.

After decades in this industry, you’d think I’d stop being surprised by critical vulnerabilities in forgotten infrastructure. And yet, here we are with the printing subsystem.

The Vulnerability Chain

#

The attack is elegant in its simplicity, which is exactly what makes it dangerous. Here’s how it works:

1. CVE-2024-47176: cups-browsed listens on UDP port 631 and trusts any packet it receives to be a legitimate printer advertisement. There is no authentication, no validation of the source.

2. CVE-2024-47076: The libcupsfilters library doesn’t sanitize the attributes returned by an attacker-controlled IPP server, allowing crafted values to flow through the system.

3. CVE-2024-47175: libppd writes these unsanitized attributes into temporary PPD (PostScript Printer Description) files without validation.

4. CVE-2024-47177: The cups-filters package allows arbitrary commands to be executed through the FoomaticRIPCommandLine directive in PPD files.

Chain them together: send a malicious UDP packet to port 631, advertise a fake printer with crafted attributes, and when a user tries to print to that printer, arbitrary commands execute as the lp user. On many systems, that’s enough to pivot to root.

The attack does require a user to initiate a print job to the fake printer, which limits the severity somewhat compared to a fully unauthenticated RCE. But the fact that the initial stage — injecting a fake printer — is completely unauthenticated and requires only a single UDP packet is concerning.

Why This Matters

#

Let’s be honest: printing on Linux has been a pain point for as long as Linux has existed. CUPS has been the de facto standard since Apple adopted it for macOS in 2002 (and subsequently acquired the project), and it’s been bundled in virtually every Linux distribution since.

But here’s the thing about infrastructure that “just works” (or, more accurately, “works well enough”): nobody looks at it. CUPS hasn’t received the kind of security scrutiny that high-profile components like OpenSSL, the kernel, or systemd regularly undergo. The cups-browsed service, in particular, seems to have been designed in an era when network trust was the default — an era that should have ended two decades ago.

The vulnerability highlights a pattern I’ve seen repeatedly in my career: the most dangerous code isn’t the code that gets the most attention. It’s the quiet, boring infrastructure code that’s been running unchanged for years, written with assumptions about trust and network topology that are no longer valid.

Immediate Mitigation

#

If you’re running Linux systems — particularly servers that don’t need printing capabilities — the fix is straightforward:

# Stop and disable cups-browsed
sudo systemctl stop cups-browsed
sudo systemctl disable cups-browsed

# Or block UDP port 631
sudo ufw deny 631/udp

For systems that do need printing, you can configure cups-browsed to restrict which sources it trusts by editing /etc/cups/cups-browsed.conf and setting BrowseRemoteProtocols to none.

The broader question is whether cups-browsed should be running at all on most systems. Printer auto-discovery over the network is a convenience feature, not a necessity. In most enterprise environments, printers are configured explicitly through management tools, making cups-browsed unnecessary attack surface.

Distribution maintainers are likely to reconsider whether cups-browsed should be enabled by default. Several major distributions have it running out of the box, which means millions of Linux systems are potentially vulnerable right now.

The Forgotten Infrastructure Problem

#

This incident reminds me of Heartbleed in 2014, ShellShock later that year, and the Log4j crisis in 2021. In each case, a critical vulnerability was found in software that was ubiquitous, underfunded, and under-scrutinized. OpenSSL was maintained by two people when Heartbleed hit. Bash hadn’t been seriously audited in decades when ShellShock was discovered. Log4j was a logging library that nobody thought about until it was everywhere and exploitable.

CUPS fits the same pattern. It’s everywhere, it’s old, and until today, nobody was particularly worried about its security posture.

The open source community has gotten better at funding critical infrastructure since the Core Infrastructure Initiative (now the Open Source Security Foundation) was established in response to Heartbleed. But CUPS apparently wasn’t on anyone’s radar as critical infrastructure, despite being installed on virtually every Linux system and macOS machine in the world.

My Take

#

The immediate risk is manageable. Disable cups-browsed if you don’t need it. Patch when your distribution provides updates. Audit your network for systems with UDP 631 exposed to the internet.

The deeper lesson is one we keep having to relearn: your attack surface includes every service running on every system, including the ones you forgot about. Especially the ones you forgot about. Security isn’t just about hardening your application code and your databases — it’s about knowing what’s running on your systems and why.

I’ve already started an audit of what services are running by default on our infrastructure. I’d suggest you do the same. The next CUPS-style vulnerability might be in a service you’ve never even thought about.

This post is part of my Security in Practice series, covering real-world security events and their implications for working engineers.