PatchDayAlert
Subscribe →
Analysis · 8 min read · 1,537 words By Colten Anderson

The CUPS chain needed a print job. The DDoS didn't.

Three CVEs in CUPS produced 20 months of scanning probes and zero attributed RCE exploitation. The constraint that stopped mass exploitation is also the reason cups-browsed still needs to go.

The CUPS chain needed a print job. The DDoS didn't.

When Simone Margaritelli published his CUPS research on September 26, 2024, the initial reaction landed close to panic. Qualys called it a “critical unauthenticated RCE” affecting more than 75,000 publicly exposed systems. Rapid7 labeled it an emergency threat response. The word “Log4Shell” showed up in security team Slacks within hours.

Twenty months later, CVE-2024-47176 and its companions do not appear in CISA’s Known Exploited Vulnerabilities catalog. No threat actor has been attributed to exploitation. The only confirmed real-world impact was DDoS amplification, a different threat model entirely, and one that got considerably less coverage than the RCE narrative.

That gap is worth examining, because the constraint that prevented mass RCE is the same one that gets buried in the disclosure framing: the exploit needs a human to print something.

What the chain actually does

Three CVEs connect in sequence. (A fourth, CVE-2024-47177, was subsequently rejected by NVD as a duplicate. The underlying foomatic-rip command injection is real and is what Stage 4 actually executes; NVD now attributes it to CVE-2024-47076 and CVE-2024-47175 rather than a separate identifier.)

CVE-2024-47176 is the entry point. The cups-browsed daemon binds its IPP listener to 0.0.0.0:631/UDP (all interfaces, no authentication required) and accepts browse packets from any source. An attacker sends a crafted UDP packet pointing at an attacker-controlled IPP server. cups-browsed queues the fake “printer” for attribute fetching. This step requires nothing from the target except a reachable UDP port.

CVE-2024-47076 carries the payload forward. libcupsfilters’ cfGetPrinterAttributes5 function issues an HTTP POST to the attacker’s IPP server, receives the response, and passes the attacker-controlled attribute values downstream without validation. The outbound request also leaks the target’s kernel version and architecture in the User-Agent header: fingerprint data the attacker has before any payload runs.

CVE-2024-47175 is where the malicious content lands on disk. libppd’s ppdCreatePPDFromIPP2 writes those attacker-controlled attributes into a temporary PPD file via cupsFilePrintf() without sanitizing newlines. By embedding a newline in a string-valued attribute, the attacker breaks out of the intended field and plants arbitrary PPD directives, including a FoomaticRIPCommandLine entry and a cupsFilter2 directive routing print jobs through foomatic-rip. The fake printer now sits in the system’s device list, PPD file on disk.

Nothing executes at this point. The attacker waits.

When any user submits a print job to that printer, cups-filters’ foomatic-rip filter reads the PPD and executes the FoomaticRIPCommandLine value as a shell command. Execution runs as the lp user, unprivileged but with network socket access and sufficient utilities to pull a secondary payload. The design flaw that enables this, foomatic-rip executing PPD-embedded shell commands without restriction, has been documented since CVE-2011-2697. It was never removed.

The constraint the coverage missed

The print-job trigger is what separates this from Log4Shell, or BlueKeep, or any other unauthenticated-RCE-from-the-network headline.

Log4Shell detonated on a log call. A crafted string in an HTTP header or form field triggered the JNDI lookup and executed the payload without any human decision. The CUPS chain requires a user to print something to a printer they did not create. In a server environment (where most of those 75,000 exposed CUPS daemons live), that means waiting indefinitely for something that may never happen. On a desktop, it means timing the attack with user print activity or social-engineering the trigger.

Red Hat confirmed that RHEL systems are not vulnerable in their default configuration: cups-browsed is not running out of the box. Censys scanned TCP port 631 (which undercounts the UDP attack surface) and found 7,171 systems running the vulnerable cups-browsed versions, compared to Qualys’s 75,000 figure for “exposed CUPS services” broadly. Ubuntu desktop installs were more exposed, where cups-browsed is more likely to be active after printer configuration. Headless servers with cups-browsed not running were out of scope even if the package was installed.

The practical RCE attack surface was not 75,000 systems. It was the subset where cups-browsed was enabled, UDP 631 was reachable, and a user would print. Datadog Security Labs observed roughly ten distinct IP addresses sending opportunistic UDP probes within hours of disclosure, some attempting to install malicious printer definitions. Wiz corroborated scanning activity. Neither organization, nor any credible threat intel source in the 20 months since, has published evidence of post-exploitation payloads delivered via this chain in a real victim environment.

What actually showed up

Akamai’s SIRT published findings a month after disclosure. Their focus was not RCE.

A single malicious UDP packet to a vulnerable cups-browsed instance can trigger a cascade of outbound IPP/HTTP requests, roughly a 600x amplification factor under optimal conditions. Of approximately 198,000 internet-exposed CUPS devices Akamai scanned, around 58,000 were estimated to be recruitable as DDoS amplifiers, with hundreds exhibiting request loops that didn’t terminate on their own.

This is a quantified and tested threat. A 600x amplification ratio makes cups-browsed useful for DDoS operators: a botnet using those systems as reflectors can deliver meaningful attack bandwidth cheaply. Unlike the RCE chain, the DDoS path does not wait for a print job. A single UDP packet is sufficient.

Shadowserver flagged this in their Special Report published October 2, 2024, tagging exposed cups-browsed instances for both RCE and DDoS risk. Most of the coverage that followed repeated the RCE framing. The amplification story was quieter.

What this means for remediation

If cups-browsed is running on any server that doesn’t print, disable and stop it. That’s a two-second systemctl operation. The service has no purpose on a headless system, and its default binding behavior (0.0.0.0:631/UDP, accepting from any source) is an unnecessary attack surface under both threat models.

For hosts where cups-browsed is legitimately needed, patching clears the RCE chain. Ubuntu shipped five security notices (USN-7041-1 through USN-7045-1) on September 26, 2024; the fixed cups-browsed for Noble (24.04) is 2.0.0-0ubuntu10.1. Red Hat shipped RHSA-2024:7346 (RHEL 9) and RHSA-2024:7463 (RHEL 8) the same day. Debian issued DSA-5778-1; SUSE patched via SUSE-SU-2024:3523-1 on October 4. If the September 2024 CUPS updates haven’t landed, that’s the first item.

The CISA KEV absence does not mean you defer patching. KEV absence means no confirmed exploitation evidence has reached the federal remediation threshold, not that the code is safe to run unpatched. Disable or patch; Akamai tested the amplification capability and found 58,000 systems recruitable as reflectors. That risk doesn’t require a KEV listing to be worth closing.

The pattern this case fits

CUPS joins a short list of high-alarm vulnerabilities where a friction point (user interaction, environmental dependency, authentication state) narrowed the practical attack surface enough to prevent the worm-class behavior the initial framing implied. Several BlueKeep follow-ons fit the same pattern.

The more useful data point is what the outcome tells you about reading multi-CVE chains. A single-step RCE in a widely deployed service is a different threat than a four-step chain where the final link requires a user action. Both are real vulnerabilities. Both warrant patching. The urgency window and the threat model are not the same.

The gap between CVE-2024-47176’s EPSS score (approximately 87% at post-disclosure time per SentinelOne’s aggregator, reflecting broad exposure and immediate public PoC availability; note the figure varies by aggregator and model vintage) and the absence of confirmed exploitation is not a contradiction. EPSS captures what conditions exist for exploitation. It doesn’t model what the attacker needs a victim to do. The score correctly flags the entry-point flaw as widely reachable. The print-job requirement is what the model can’t see.

What to watch: CISA KEV additions for these CVEs remain possible if exploitation evidence surfaces. The more interesting gap is on the DDoS side: Akamai identified 58,000 recruitable systems and demonstrated 600x amplification, but no DDoS campaign has been attributed to cups-browsed. PatchDayAlert’s daily digest tracks cases like this one, where the initial threat framing and the exploitation record tell different stories.

Sources

Share

X LinkedIn Facebook Email
Tags #cups #linux #cve-2024-47176 #cve-2024-47076 #cve-2024-47175 #rce #ddos #patch-management

Related field notes

Get the free CVE triage cheat sheet

Subscribe and we'll email you the one-page triage flow for fresh CVEs. Plus the weekly digest.

Subscribe