On September 26, 2024, researcher Simone Margaritelli (evilsocket) published "Attacking UNIX systems via CUPS Part I," disclosing four vulnerabilities that, chained together, let an unauthenticated remote attacker execute arbitrary code on Linux, BSD, and other UNIX-like systems running cups-browsed. The entry point, CVE-2024-47176, is deceptively small: cups-browsed binds its UDP listener to INADDR_ANY:631, so it accepts packets from any source and trusts a crafted Get-Printer-Attributes IPP request enough to fetch printer attributes from an attacker-controlled URL. NVD scored that individual flaw only 5.3 (Medium) under CWE-1327, "Binding to an Unrestricted IP Address" — a score that, taken alone, wildly understates what happens once it's chained with CVE-2024-47076, CVE-2024-47175, and CVE-2024-47177. Fixed in cups-browsed versions after commit 1debe6b140c37e0aa928559add4abcc95ce54aa2, the chain became a rare case where four separately unremarkable CVSS scores combined into full remote code execution requiring zero authentication and zero user interaction. This post walks the chain link by link and covers what actually stops it.
What does CVE-2024-47176 actually let an attacker do?
CVE-2024-47176 lets an attacker redirect cups-browsed to treat an arbitrary, attacker-controlled URL as a legitimate IPP printer. Because the UDP listener trusts packets from any source (AV:N/AC:L/PR:N/UI:N in its CVSS vector, per the GitHub Security Advisory GHSA-rj88-6mr5-rcw8 assessment NVD cites), a single spoofed Get-Printer-Attributes packet aimed at UDP/631 is enough — no handshake, no credentials. Affected versions are cups-browsed ≤ 2.0.1 from the OpenPrinting project. On its own, this only gives the attacker the ability to make the target machine fetch attributes from a server they control; NVD's own description is explicit that this step alone does not yield code execution. It's the equivalent of tricking a mail client into trusting a spoofed sender — a foothold, not a payload, and that distinction is exactly why the chain is worth studying: patching one Medium CVE without the others leaves the door only partly closed.
How do CVE-2024-47076 and CVE-2024-47175 turn that foothold into malicious data on disk?
Once cups-browsed is pointed at the attacker's fake IPP server, two more flaws let that server hand back data the target trusts uncritically. CVE-2024-47076 sits in libcupsfilters: it fails to validate or sanitize IPP attributes returned by the "printer," so a malicious response's fields are accepted as-is. CVE-2024-47175 sits one layer downstream, in libppd, which takes those unsanitized attributes and writes them into a temporary PPD (PostScript Printer Description) file — the config format CUPS uses to describe a printer's capabilities to filters. Because the PPD generator doesn't validate what it's writing, the attacker can inject directives into that file, including a fabricated FoomaticRIPCommandLine field. At this point nothing has executed; the attacker has planted a malicious file on disk that CUPS itself will read the next time a print job is submitted to that "printer."
What makes CVE-2024-47177 the RCE trigger?
CVE-2024-47177 is the payoff: a flaw in cups-filters' foomatic-rip filter that lets attacker-controlled PPD fields specify arbitrary commands to run when a print job is processed. Foomatic is a long-standing bridge between CUPS and non-PostScript printer drivers, and foomatic-rip reads command-line instructions out of the PPD file to build the filter pipeline for a given print job. Because the PPD was poisoned via CVE-2024-47175, the attacker effectively controls that command line. Print anything — even trigger a test page — and the injected command executes with the privileges of the CUPS filter process. Combined with CVE-2024-47176's zero-auth network trigger, this closes the loop from "attacker sends one UDP packet" to "attacker's shell command runs on your box," with no credentials and no user clicking anything beyond a print job the target system may issue automatically.
Who was actually exposed, and how badly?
Exposure depended heavily on cups-browsed being installed and running, which many modern distributions do by default on desktop-oriented images but not on minimal server builds. Because the trigger travels over UDP/631, it's exploitable both from the local network — using DNS-SD/mDNS spoofing to advertise a fake printer — and, per Red Hat's and Qualys's write-ups on the disclosure, from the public internet on any host with cups-browsed's listener reachable from the WAN. Qualys and Akamai both reported internet-wide scanning for exposed UDP/631 endpoints within days of the September 26, 2024 disclosure. The saving grace was scope: distributions that ship CUPS for printing on servers, containers, and cloud images generally don't run cups-browsed at all, and several major distros shipped hardened defaults or backported fixes within the disclosure window.
What's the actual mitigation, beyond "patch it"?
The most reliable fix is removing the attack surface, not just patching: disable and uninstall cups-browsed on any host that doesn't need automatic network printer discovery, since the service exists purely to advertise and auto-configure IPP printers on a LAN. Where the service must stay, apply the upstream fixes to cups-browsed, libcupsfilters, libppd, and cups-filters from your distribution's patched packages, and firewall UDP/631 and TCP/631 from untrusted networks in the meantime. Red Hat's guidance additionally recommended disabling the cups-browsed.socket and cups-browsed.service units outright on RHEL systems where they were enabled by default. The broader lesson for vulnerability management programs is that a Medium-severity CVSS score on any single link in a chain is not the number to triage on — reachability and exposure context (is this port even listening, is this service even installed) matter more than the base score of any one CVE in isolation.
How Safeguard helps with chains like this
A vulnerability management workflow that only ranks findings by an individual CVE's CVSS score would have buried CVE-2024-47176 in a Medium-priority backlog while the real exposure — an internet-reachable UDP/631 listener chainable into RCE — went unaddressed. Safeguard's Vulnerabilities view is built for exactly this gap: it layers CISA KEV and exploitability signals, EPSS scoring, and reachability analysis on top of raw CVSS so a team can see whether a flagged component is actually running and exposed, not just present in a package manifest. For a chain like the CUPS RCE, that means surfacing whether cups-browsed is installed and network-reachable at all, rather than relying on a single CVE's base score to set priority. Where a system genuinely doesn't run the affected service, Safeguard's Mitigations workflow lets a team document that as a risk acceptance or false positive with an expiration date and audit trail, so the finding doesn't sit as unresolved noise — and doesn't get forgotten if that service ever gets turned back on.