CVE-2024-47175

What it actually does

The flaw is an input-validation failure in OpenPrinting libppd. The ppdCreatePPDFromIPP2 function can copy attacker-controlled IPP printer attributes into a generated PPD file without sufficient sanitization. In vulnerable CUPS/libppd configurations, especially when combined with related CUPS issues such as attacker-controlled printer discovery and Foomatic processing, malicious IPP attributes can become executable printer configuration directives. This can lead to command execution in the context of the printing components, commonly the CUPS or printing service account, when the malicious printer configuration is used.

Why it matters to the business

A vulnerable system that accepts or discovers untrusted printers can be turned from a printing service into an execution path for attacker-supplied commands. Operationally, this can allow compromise of Linux/Unix workstations or servers that run CUPS components, theft or manipulation of print data, lateral movement from user endpoints, and disruption of printing services. Although this issue is not currently listed in CISA KEV and is not marked as ransomware-associated, it has weaponized exploit maturity and a high EPSS score of 0.63811, so organizations should treat exposed CUPS/libppd deployments as high priority, particularly where printer discovery or legacy PPD/Foomatic support is enabled.

How an attack unfolds

An attacker first positions a malicious IPP printer or printer-discovery response where a vulnerable host can reach or discover it. In common exploit chains, a related CUPS discovery weakness can cause the victim to query an attacker-controlled IPP endpoint. The attacker responds with crafted IPP attributes that libppd uses to generate a PPD file. Because the attributes are not properly sanitized, attacker-controlled content can be written into PPD directives that are later interpreted by downstream print processing components such as Foomatic. When the victim system interacts with the malicious printer configuration, such as by adding the printer or processing a print job, the malicious configuration can trigger command execution under the printing service context. The attacker may then establish persistence, collect local data, move laterally, or use the host as a foothold.

How to fix it

Upgrade OpenPrinting libppd to a version that includes the fix for this issue. For the Git-tracked affected product, update to commit d681747ebf12602cb426725eb8ce2753211e2477 or a downstream vendor package that explicitly includes that fix. Because this issue is commonly exploited as part of a CUPS chain, also update related CUPS, cups-browsed, cups-filters, libcupsfilters, and Foomatic packages from the operating system vendor. If printing is not required, disable and remove CUPS-related services. If printing is required, disable cups-browsed where automatic printer discovery is unnecessary, restrict access to IPP/printing services to trusted networks, block unsolicited inbound UDP/TCP 631 from untrusted networks, and avoid accepting printers from untrusted discovery sources. Remove unexpected printer queues and regenerate PPD files after patching.

How to confirm the fix worked

Confirm that the installed libppd package or source tree contains the fix corresponding to commit d681747ebf12602cb426725eb8ce2753211e2477 or a vendor advisory that backports it. Verify that all related CUPS packages are updated, not only libppd. Check that cups-browsed is disabled where not needed and that firewall policy blocks untrusted access to IPP on TCP/631 and UDP/631. Enumerate configured printers and PPD files to ensure no unexpected queues or suspicious PPD directives remain. Review /etc/cups/ppd/ for recently created or modified files, and validate that no PPD contains suspicious Foomatic command directives or shell metacharacters. Confirm the CUPS services restart cleanly after upgrade and that normal printing still functions with trusted printers.

Typical attack path

1. Identify hosts running vulnerable CUPS/libppd components with printer discovery, IPP, legacy PPD, or Foomatic support enabled.
2. Expose or advertise an attacker-controlled IPP printer to the target network or cause the target to query a malicious IPP endpoint.
3. Return crafted IPP printer attributes that are accepted by the vulnerable libppd code path.
4. Cause libppd to generate a PPD file containing attacker-controlled directives.
5. Wait for the malicious printer configuration to be used by CUPS/Foomatic during printer setup, enumeration, or a print job.
6. Achieve command execution in the context of the printing service or associated user.
7. Perform post-exploitation actions such as payload staging, persistence, credential access, discovery, or lateral movement.

How to detect it

To determine whether this was already exploited, review host and print-service telemetry rather than relying on a single IOC. Examine CUPS logs such as /var/log/cups/error_log, /var/log/cups/access_log, and /var/log/cups/page_log for unexpected printer creation, connections to unfamiliar IPP endpoints, unusual printer attributes, or print jobs submitted to newly created queues. Review system logs such as /var/log/syslog, /var/log/messages, and journald for cups-browsed, cupsd, foomatic-rip, and printer-discovery activity around the time suspicious queues appeared. Inspect /etc/cups/printers.conf and /etc/cups/ppd/*.ppd for recently added printers, unexpected remote device URIs, PPD files containing Foomatic command directives, shell metacharacters, encoded commands, download utilities, or paths such as /tmp, /var/tmp, /dev/shm, or user-writable directories. Use process telemetry or EDR to identify child processes spawned by cupsd, cups-browsed, foomatic-rip, lp, lpr, or backend helpers, especially shells, curl, wget, Python, Perl, nc, socat, or chmod. Review network logs for inbound UDP/631 discovery traffic, outbound IPP requests to unknown hosts, and connections to external or user-subnet systems presenting as printers. If available, correlate suspicious activity with the public exploit window after 2024-09-26 and with any endpoints that had automatic printer discovery enabled.

• /var/log/cups/error_log
• /var/log/cups/access_log
• /var/log/cups/page_log
• /etc/cups/printers.conf
• /etc/cups/ppd/*.ppd
• /var/spool/cups/
• cups-browsed
• cupsd
• foomatic-rip
• ppdCreatePPDFromIPP2
• FoomaticRIPCommandLine
• *FoomaticRIPCommandLine:
• cupsFilter2
• application/vnd.cups-postscript
• application/vnd.cups-pdf
• ipp://
• ipps://
• socket://
• udp/631
• tcp/631
• Get-Printer-Attributes
• Create-Printer-Subscriptions
• BrowsePoll
• BrowseRemoteProtocols
• DeviceURI ipp://
• DeviceURI ipps://
• /tmp/
• /var/tmp/
• /dev/shm/
• ;curl
• ;wget
• |sh
• /bin/sh
• /bin/bash
• python -c
• perl -e
• nc -e
• socat exec

What your security team should do

• Prioritize patching because exploit maturity is weaponized and EPSS is high, even though the issue is not currently in CISA KEV.
• Inventory Linux/Unix endpoints and servers running CUPS, libppd, cups-browsed, cups-filters, libcupsfilters, or Foomatic components.
• Patch libppd to the fixed Git commit d681747ebf12602cb426725eb8ce2753211e2477 or an equivalent vendor-backported package, and patch the rest of the CUPS chain at the same time.
• Disable cups-browsed and automatic printer discovery unless explicitly required.
• Restrict IPP traffic on TCP/631 and UDP/631 to trusted print infrastructure; block exposure from untrusted user networks and the internet.
• Hunt for unexpected printer queues, recently modified PPD files, and suspicious Foomatic directives before and after remediation.
• Remove untrusted printer definitions and regenerate PPD files from known-good sources after patching.
• Add SIEM detections for suspicious CUPS/Foomatic activity, unexpected outbound IPP connections, and shell execution spawned from print-related processes.