CUPS CVE-2024-47176: Network RCE via IPP

CUPS CVE-2024-47176 is part of a four-CVE cluster (CVE-2024-47076, CVE-2024-47175, CVE-2024-47176, CVE-2024-47177) disclosed by Simone Margaritelli on September 26, 2024. The bug lives in the cups-browsed daemon which, when running, listens on UDP port 631 and accepts unsolicited IPP packets that announce remote printers. An attacker can add a malicious printer whose PPD file triggers command execution when the victim prints. Red Hat scored the cluster at CVSS 9.9, though the real-world severity is lower because exploitation requires the victim to initiate a print job. The bug is significant anyway because of the breadth of affected systems.

What is the vulnerability in CVE-2024-47176 specifically?

CVE-2024-47176 specifically is that the cups-browsed daemon binds to UDP port 631 on all interfaces and accepts any incoming IPP packet that looks like a printer announcement, without validation of the source network or the announced printer's URL. Any attacker who can send UDP packets to the target (from the LAN, from the internet if the port is exposed, or from another tenant in a shared environment) can cause the target to add a new printer definition that points at an attacker-controlled URL.

On its own, adding a printer is not RCE. The RCE comes from the full chain across the four CVEs:

• CVE-2024-47176: cups-browsed accepts the packet and fetches attacker-controlled printer data
• CVE-2024-47076: libcupsfilters does not sanitize IPP attributes
• CVE-2024-47175: libppd fails to sanitize PPD file contents written to disk
• CVE-2024-47177: cups-filters foomatic-rip allows arbitrary command execution via the FoomaticRIPCommandLine PPD directive

Put together, the attacker's announced printer includes a PPD with a malicious FoomaticRIPCommandLine, and when the victim prints anything to that printer, foomatic-rip executes the attacker's command as the lp user.

How is the exploitation chain actually used in practice?

The exploitation chain is used by sending a spoofed IPP announcement packet to UDP 631 on the target, waiting for the target system to register the printer, and then waiting for any user or automated process to print to it. The attacker does not control the timing of step three, which is why this CVE cluster is noisier than a straight pre-auth RCE. For targets with active desktop users and default print behavior, exploitation is still reliable.

A minimal proof of concept:

1. Send a crafted UDP packet to the target's port 631 containing an IPP Browse announcement for a printer named "HP_LaserJet_Lobby" with a URL pointing to the attacker's HTTP server
2. cups-browsed registers the printer, fetches the PPD file from the attacker's URL, and adds it to the system
3. User prints a document; the print system selects the new printer (either by default or by name collision)
4. foomatic-rip processes the job using the attacker's PPD, which contains *FoomaticRIPCommandLine: "sh -c '<attacker command>'"
5. Attacker's command runs as the lp user

For environments where users rarely print, attackers can pair this with targeted phishing ("Your document is ready for printing at the Lobby HP") to induce a print action.

The chain also works for server-side attacks where a scheduled job generates PDFs via the print system. Document processing pipelines that use CUPS as an intermediate rendering step can trigger the chain without user interaction.

Which Linux distributions and systems are affected?

Distributions affected include most major Linux desktops and any server that has cups-browsed installed and running. Package availability varies:

• Ubuntu Desktop: cups-browsed installed and enabled by default on many versions
• Fedora Workstation: installed and enabled
• Debian: installed if CUPS is, not always enabled
• Red Hat Enterprise Linux: cups-browsed is part of cups-filters, which is installed when CUPS is
• Alpine, Arch, Gentoo: installed on demand, less likely enabled by default

Server environments are less commonly affected because cups-browsed is typically a desktop feature, but shops that built imaging templates from desktop bases and deployed them as servers can carry the daemon along. The bigger surprise is embedded devices and appliances built on Linux: network printers themselves, multifunction devices, point-of-sale systems, and industrial controllers that include a Linux distribution with CUPS components often run the vulnerable code.

Patch availability:

• Upstream CUPS-filters and cups-browsed patches shipped late September 2024
• Distribution backports followed within days to weeks
• Embedded device firmware updates lag significantly, sometimes by months

What detection signals indicate exploitation attempts?

Detection signals include network traffic on UDP 631, new printer registrations, and process lineage under lp or cups. Network signals:

• Inbound UDP to port 631 from non-local source addresses
• Outbound HTTP from systems to unfamiliar destinations immediately after UDP 631 traffic (PPD fetch)
• Any UDP 631 traffic across network segments that should not share a print service

System signals:

• New entries in /etc/cups/printers.conf or new files in /etc/cups/ppd/ created outside normal printer install workflows
• Systemd journal entries from cups-browsed registering printers whose URLs do not match known print servers
• Process lineage showing foomatic-rip or cups-browsed as parent of sh, bash, curl, or wget

Post-exploitation signals as the lp user:

• Outbound connections to attacker-controlled infrastructure from an unexpected user context
• New cron entries or systemd units owned by lp
• Attempts to escalate privileges through kernel exploits or SUID binaries

The lp user typically has limited privileges, but the foothold is real and attackers use it as a staging point. On systems where lp has write access to interesting paths (shared printer queues, log directories), persistence without privilege escalation is trivial.

What mitigation options exist before full patches roll out?

Mitigation options before patches roll out are to disable or firewall cups-browsed and to block the PPD execution path. Immediate mitigations:

1. systemctl disable --now cups-browsed on every system that does not actively need network printer discovery
2. Firewall inbound UDP 631 at host firewalls (iptables, firewalld, UFW) to block unsolicited announcements
3. Edit /etc/cups/cups-browsed.conf to set BrowseRemoteProtocols none which disables network printer discovery entirely

For desktop users who need network printing, configure static printer entries through the print dialog rather than relying on discovery. Enterprise environments frequently already do this through print servers and Group Policy equivalents, so disabling cups-browsed rarely breaks legitimate workflows.

For server fleets, the mitigation is usually trivial: servers do not print, and the cups-browsed daemon has no reason to run. Audit inventory, disable the service, and uninstall cups-filters where feasible.

Patching to the fixed packages closes the chain at the CUPS level. Distribution-specific package versions:

• cups-filters 2.0.1 or later
• cups-browsed 2.0.1 or later
• libppd 2.1b1 or later

On Debian-family systems, apt upgrade against a current repository brings in the fixes. On Red Hat family, dnf update does the same. Embedded devices require vendor-supplied firmware updates, which is where organizations should push their device vendors for TPRM documentation.

What are the supply chain and TPRM implications?

The supply chain implications reach into every Linux-based appliance or device that ships a CUPS-compatible print stack. Multifunction printers, industrial controllers, point-of-sale systems, thin clients, and embedded kiosks frequently include the affected libraries. Vendor SBOMs often miss these components because the build system includes them transitively through a distribution meta-package rather than as an explicit dependency.

TPRM questions to raise with device and appliance vendors:

• Does your firmware include cups-filters, cups-browsed, or libppd?
• What version ships, and how is it updated?
• Is UDP 631 open on any interface by default?
• What is your patch timeline for CVE-2024-47176 and siblings?

Embedded device patching has historically been slow and uneven. Shops with significant device fleets should assume that some devices will remain exposed for months and plan network-level mitigations (segmented VLANs, firewall rules on distribution switches) as durable controls rather than temporary workarounds.

How Safeguard.sh Helps

Safeguard.sh identifies every Linux system and embedded device running vulnerable cups-browsed, cups-filters, libppd, or libcupsfilters through 100-level binary-aware dependency scanning that reaches into container images, firmware bundles, and appliance disk images where manifest-only SCA tools miss transitive components. Reachability analysis removes 60 to 80 percent of noise by distinguishing systems where cups-browsed is actually running and listening on UDP 631 from those that merely install the package. Griffin AI autonomously generates disable-service pull requests for infrastructure-as-code repositories, firewall rules for network segmentation, and container self-healing rebuilds affected images against patched bases. SBOM generation and ingest cover embedded firmware alongside host OS packages, and the TPRM workflow flags device vendors whose products ship vulnerable CUPS components.