Practical operation of CUPS RCE vulnerability
Reproduction of the chain
Elastic Security Labs used PoC "cupshax" for testing. PoC creates a fake IPP service via mDNS/ZeroConf, announces a fake printer. When connecting a vulnerable cups-browsed returns IPP attributes with malicious directives.
Example of a malicious PPD fragment (from the publication opennet.ru):
Code:
*FoomaticRIPCommandLine: "echo 1 > /tmp/I_AM_VULNERABLE"
*cupsFilter2: "application/pdf application/vnd.cups-postscript 0 foomatic-rip"
Directive cupsFilter2 CUPS indicates to call foomatic-rip when processing PDF. FoomaticRIPCommandLine contains a command for execution. In a real attack echo 1 > /tmp/I_AM_VULNERABLE replaced by reverse shell or bootloader.
When testing, Elastic recorded:
• Commands are executed on behalf of the user and group lp- default account for printing on Linux with CUPS
• Interactive reverse shells are not directly supported - y lpno login shell, but with additional techniques (Elastic calls it "creative tactics") you can get the opposite shell
• In telemetry, the parent process is foomatic-rip, generating shell. Abnormal behavior and reliable compromise indicator
• The files created by the exploit belong to lp- recording in /tmp/Trivially Detectable
Restrictions: When CUPS RCE vulnerability does not work
Initial CVSS 9.9 assessment (appropriated before deviation CVE-2024-47177) looked frightening. Real exploitability is below. Red Hat revised the score to 6.1 (Important). JFrog assigned a Medium genital. Here is why:
According to JFrog, Debian 12, RHEL 8, Ubuntu 16.04/24.04/24.04 Desktop is listened to only on loopback. Ubuntu Server does not put CUPS by default.
For internal pentest, the situation is different: if cups-browsed is configured for auto-discovery in the corporate network and employees regularly print - the chain works. Administrators that include BrowseRemoteProtocols cups For convenience, create exactly the conditions that the attacker needs. CrowdStrike Falcon and SentinelOne detect an abnormal shell start from foo-rip at the EDR-agent level, but only if the agent is installed on the print server. And print servers often remain without EDR-coating - I see it at every second project.
Detecting the operation of CUPS print spooler
Elastic Security Labs has released OOTB detection rules available from the Prebuilt Security Detection Rules versions 8.12.23+, 8.13.18+, 8.14.12+, 8.15.6+:
• cupsd or foomatic-rip shell execution - start shell from the process of cupsd or foomatic-rip
• Printer user (lp) shell execution - shell on behalf of the user lp
• Network connection by CUPS foomatic-rip child - outgoing network connections from docking docking processes foo-rip (mailload indicator)
• File creation by CUPS fooactive-rip child - file creation by child-processes foomatic-rip
For MaxPatrol SIEM, KUMA, Splunk - baseline indicators for custom correlation rules: parent process foomatic-rip Generates bash, sh or dash; user lp creates executable files or files in atypical ways (/dev/shm/. home directories) in combination with parental process foomatic-rip -> shell; outgoing network connection from the foomatic-rip subsidiary process. Incoming UDP-package on port 631 from the external address is an avert reason in any stateful firewall.
If cups-browsed is not needed for work - disconnection remains the most effective measure:
Bash:
sudo systemctl stop cups-browsed
sudo systemctl disable cups-browsed
sudo ufw deny in 631/udp
Margaritylli also recommends blocking the DNS-SD: if UDP 631 is unavailable, the attacker can use zeroconf/mDNS spoofing on a local network.
This CUPS RCE vulnerability chain is not a one-time incident. In 2026 appeared CVE-2026-34990 (NVD CVSS 4.0: 5.0 Medium, CWE-287; Red Hat CVSS 3.1: 5.2, CWE-73 - local non-viligal user can force cupsd authenticated to the attacker's IPP service) and CVE-2026-34980 (NVD CVSS 4.0: 6.1 Medium, AV:A, CWE-20; Red Hat CVSS 3.1: 6.4, CWE-78 - newline injection in the page-border attribute allows an unauthenticized client on the same network to implement a directive in PPD shared PostScript queues). According to CISA-APD, for both there is a PoC, the SSVC-Track solution (follow, cook patch). Red Hat has marked CVE-2026-34980 as Affected for RHEL 10, and CVE-2026-34990 - like Fix deferred. Red Hat uses its own CVSS ratings: 5.2 (CWE-73) for CVE-2026-34990 and 6.4 (CWE-78) for CVE-2026-34980, which is different from NVD (CWE-287 and CWE-20, respectively).
Every year, CUPS find a new way to execute commands, and the root cause does not change: foomatic-rip causes shell design, design attributes are considered trusted, the PPD design describes the executable filters. As long as this architecture is living - CVE-2024-47177 And his heirs will appear. In the internal engagements, I check cups-browsed in the first 15 minutes - it's a low-hanging fruit with high-impact result if the conditions match. But most defense commands do not enter one line systemctl disable cups-browseduntil the incident happens. Print servers have been sitting for years without EDR, no updates, with BrowseRemoteProtocols cups in config - and administrators are sincerely surprised when because of the "printer" leaks the lateral movement into the productive segment. The problem is not technical. Print spooler is not perceived as a attack surface - neither customers nor SOC analysts. If you have CUPS in infrastructure and cups-browsed running - disable it today. Not tomorrow, not after agreeing on change request. Today.
Reproduction of the chain
Elastic Security Labs used PoC "cupshax" for testing. PoC creates a fake IPP service via mDNS/ZeroConf, announces a fake printer. When connecting a vulnerable cups-browsed returns IPP attributes with malicious directives.
Example of a malicious PPD fragment (from the publication opennet.ru):
Code:
*FoomaticRIPCommandLine: "echo 1 > /tmp/I_AM_VULNERABLE"
*cupsFilter2: "application/pdf application/vnd.cups-postscript 0 foomatic-rip"
Directive cupsFilter2 CUPS indicates to call foomatic-rip when processing PDF. FoomaticRIPCommandLine contains a command for execution. In a real attack echo 1 > /tmp/I_AM_VULNERABLE replaced by reverse shell or bootloader.
When testing, Elastic recorded:
• Commands are executed on behalf of the user and group lp- default account for printing on Linux with CUPS
• Interactive reverse shells are not directly supported - y lpno login shell, but with additional techniques (Elastic calls it "creative tactics") you can get the opposite shell
• In telemetry, the parent process is foomatic-rip, generating shell. Abnormal behavior and reliable compromise indicator
• The files created by the exploit belong to lp- recording in /tmp/Trivially Detectable
Restrictions: When CUPS RCE vulnerability does not work
Initial CVSS 9.9 assessment (appropriated before deviation CVE-2024-47177) looked frightening. Real exploitability is below. Red Hat revised the score to 6.1 (Important). JFrog assigned a Medium genital. Here is why:
According to JFrog, Debian 12, RHEL 8, Ubuntu 16.04/24.04/24.04 Desktop is listened to only on loopback. Ubuntu Server does not put CUPS by default.
For internal pentest, the situation is different: if cups-browsed is configured for auto-discovery in the corporate network and employees regularly print - the chain works. Administrators that include BrowseRemoteProtocols cups For convenience, create exactly the conditions that the attacker needs. CrowdStrike Falcon and SentinelOne detect an abnormal shell start from foo-rip at the EDR-agent level, but only if the agent is installed on the print server. And print servers often remain without EDR-coating - I see it at every second project.
Detecting the operation of CUPS print spooler
Elastic Security Labs has released OOTB detection rules available from the Prebuilt Security Detection Rules versions 8.12.23+, 8.13.18+, 8.14.12+, 8.15.6+:
• cupsd or foomatic-rip shell execution - start shell from the process of cupsd or foomatic-rip
• Printer user (lp) shell execution - shell on behalf of the user lp
• Network connection by CUPS foomatic-rip child - outgoing network connections from docking docking processes foo-rip (mailload indicator)
• File creation by CUPS fooactive-rip child - file creation by child-processes foomatic-rip
For MaxPatrol SIEM, KUMA, Splunk - baseline indicators for custom correlation rules: parent process foomatic-rip Generates bash, sh or dash; user lp creates executable files or files in atypical ways (/dev/shm/. home directories) in combination with parental process foomatic-rip -> shell; outgoing network connection from the foomatic-rip subsidiary process. Incoming UDP-package on port 631 from the external address is an avert reason in any stateful firewall.
If cups-browsed is not needed for work - disconnection remains the most effective measure:
Bash:
sudo systemctl stop cups-browsed
sudo systemctl disable cups-browsed
sudo ufw deny in 631/udp
Margaritylli also recommends blocking the DNS-SD: if UDP 631 is unavailable, the attacker can use zeroconf/mDNS spoofing on a local network.
This CUPS RCE vulnerability chain is not a one-time incident. In 2026 appeared CVE-2026-34990 (NVD CVSS 4.0: 5.0 Medium, CWE-287; Red Hat CVSS 3.1: 5.2, CWE-73 - local non-viligal user can force cupsd authenticated to the attacker's IPP service) and CVE-2026-34980 (NVD CVSS 4.0: 6.1 Medium, AV:A, CWE-20; Red Hat CVSS 3.1: 6.4, CWE-78 - newline injection in the page-border attribute allows an unauthenticized client on the same network to implement a directive in PPD shared PostScript queues). According to CISA-APD, for both there is a PoC, the SSVC-Track solution (follow, cook patch). Red Hat has marked CVE-2026-34980 as Affected for RHEL 10, and CVE-2026-34990 - like Fix deferred. Red Hat uses its own CVSS ratings: 5.2 (CWE-73) for CVE-2026-34990 and 6.4 (CWE-78) for CVE-2026-34980, which is different from NVD (CWE-287 and CWE-20, respectively).
Every year, CUPS find a new way to execute commands, and the root cause does not change: foomatic-rip causes shell design, design attributes are considered trusted, the PPD design describes the executable filters. As long as this architecture is living - CVE-2024-47177 And his heirs will appear. In the internal engagements, I check cups-browsed in the first 15 minutes - it's a low-hanging fruit with high-impact result if the conditions match. But most defense commands do not enter one line systemctl disable cups-browseduntil the incident happens. Print servers have been sitting for years without EDR, no updates, with BrowseRemoteProtocols cups in config - and administrators are sincerely surprised when because of the "printer" leaks the lateral movement into the productive segment. The problem is not technical. Print spooler is not perceived as a attack surface - neither customers nor SOC analysts. If you have CUPS in infrastructure and cups-browsed running - disable it today. Not tomorrow, not after agreeing on change request. Today.
