REDHAT-BUG-2545835: Low severity OpenPrinting CUPS vulnerability
CUPS (Common UNIX Printing System) scheduler accepts IPP Create-Printer-Subscription requests with a notify-recipient-uri attribute. In scheduler/ipp.c, createprintersubscription validates only the URI scheme (notifier type) and does not validate the recipient address portion of mailto: URIs.
When a subscribed event fires, the mailto notifier in notifier/mailto.c passes the recipient string verbatim as a command-line argument to the configured sendmail binary (pipesendmail / execvp) without rejecting leading "-" characters or inserting a "--" separator. A notify-recipient-uri such as mailto:-tC/path/to/crafted.cf is therefore interpreted by traditional sendmail as option arguments (argument injection, CWE-88).
Combined with anonymous Create-Printer-Subscription under default cupsd policy and the ability to stage attacker-controlled files in the CUPS spool via Print-Job, this can chain to arbitrary command execution as the CUPS filter user (lp) when cupsd is network-reachable and a traditional sendmail implementation that honors -C is installed and configured in mailto.conf.
Upstream advisory: GHSA-r4wf-366f-f6g3 (OpenPrinting/cups). Upstream affected version cited: 2.4.7. Upstream fixes on master (1244ed9) and 2.4.x (611d1bd) validate notification email addresses and harden sendmail invocation.
PSIRT ticket: PSIRTSUPT-24443
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
CUPSto a version that resolves this vulnerability.Patch GHSA-r4wf-366f-f6g3
Event History
Frequently Asked Questions
Which systems are realistically exposed to code execution through this issue?
Exposure requires a network-reachable CUPS scheduler, anonymous Create-Printer-Subscription permitted by the cupsd policy, and a traditional sendmail implementation configured in mailto.conf that honors the -C option. The attacker must also be able to stage controlled files in the CUPS spool through Print-Job.
Does the default CUPS policy matter for exploitation?
Yes. The described attack chain relies on anonymous Create-Printer-Subscription access under the default cupsd policy. Restricting anonymous subscription creation can break that part of the chain.
What can be done if an update cannot be applied immediately?
Limit network reachability to cupsd, disable or restrict anonymous Create-Printer-Subscription requests, and avoid configuring a traditional sendmail implementation that honors -C for mailto notifications. Restricting Print-Job access also prevents the stated method of staging attacker-controlled spool files.
What privileges would successful exploitation provide?
The described chain can result in arbitrary command execution as the CUPS filter user, lp.