SURIQ
A Linux print system can be knocked out by a single fake printer. A flaw tracked as CVE-2026-64611 in libcupsfilters, the printing library behind CUPS on most Linux distributions, lets an attacker who can advertise a printer on the network drive the service into an endless loop that eats a processor core and never stops. It is a denial-of-service bug, not remote code execution, and it carries a severity of 7.5. The reason it still deserves a place on your list: it sits on the exact code path, automatic network printer discovery, that produced the CUPS remote-code-execution scare of 2024.
What the bug actually does
When a printer announces itself on a network, it advertises an IEEE-1284 device ID, a text string that names its make and model. The cfIEEE1284NormalizeMakeModel() function cleans that string up. According to the CVE record, when the model portion arrives empty, the routine never reaches its exit condition and spins forever, consuming CPU without end. The flaw is classified as CWE-835, a loop with an unreachable exit condition.
The severity vector tells you the shape of the risk exactly: reachable over the network, no privileges or user interaction required, and rated for availability impact only, with no confidentiality or integrity loss. An attacker cannot read data, change files, or run code through this bug. They can only exhaust a processor and take printing offline. Red Hat, which assigned the CVE, lists cups-filters across Enterprise Linux 7 through 10 and libcupsfilters on Enterprise Linux 10 as affected. The trigger is any host that parses an advertised device ID, which in practice means a machine running the CUPS discovery service.
Two denial-of-service bugs, one release
CVE-2026-64611 did not ship alone. The same libcupsfilters 2.1.0 release also fixes CVE-2026-64612, where the project's PNG image reader is built without an error-recovery handler, so a malformed PNG submitted as a print job aborts the CUPS image filter and kills that job. It needs no authentication. Two different inputs, the same outcome: the printing pipeline stops doing its work.
| CVE | What triggers it | Who can send it | Impact |
|---|---|---|---|
| CVE-2026-64611 | Printer advertisement with an empty model field | Anyone who can advertise a printer on a network the host discovers | Infinite loop, one CPU core pinned |
| CVE-2026-64612 | Malformed PNG sent as a print job | Unauthenticated print-job submitter | Image filter aborts, the print job dies |
This is the printer-discovery attack surface, again
The 2024 CUPS saga, which began with CVE-2024-47076 and its siblings, also started with the discovery service accepting a printer advertisement from the network and trusting the device attributes inside it. That chain reached remote code execution through a downstream filter. This year's bug is far less severe, a loop instead of a shell, but the entry point is identical: a service listening for printer announcements, parsing the make and model an unknown device claims to be.
The pattern is worth naming. The IEEE-1284 device-ID string keeps being the soft spot because it is attacker-controlled text that flows straight into parsers written on the assumption that a real, well-behaved printer is on the other end. Empty a field the code expected to be populated, and the assumption breaks. libcupsfilters is not unusual here. We have watched the same shape play out as a memory-exhaustion denial of service in OpenSSL's TLS handling and a crash in NGINX's config handling, where untrusted input reaches a routine that assumed a well-formed peer. The fix always closes the specific hole; the exposure is the listener itself.
Patch, then decide whether you should be listening at all
Treat any host running the CUPS discovery service as reachable by anyone on its network segment, and work through this in order.
- Patch. Update the
cups-filtersandlibcupsfilterspackages through your distribution. The upstream fix is in libcupsfilters 2.1.0, and vendors including Red Hat backport it as errata, so a normal package update applies the patch once your distribution publishes it. As with any denial-of-service patch gap, the window between disclosure and your update is the exposure. - Reduce the surface. Most servers never need to discover network printers. If a host is not a print server, disable and mask
cups-browsed, or stopcupsdentirely. This is the same move that blunted the 2024 remote-code-execution risk, and it removes this denial of service at the same time. - Filter the network. Block inbound printer-discovery traffic, including UDP port 631 and mDNS printer announcements, at the host or segment boundary for machines with no reason to receive them.
- Detect it. You will not get an alert that names the CVE. What you will see is
cups-browsedor acupsdworker stuck near 100 percent of one core with no print activity to explain it. Alert on sustained single-process CPU for the printing daemons, and treat an unexplained spike as worth a look, not a quiet restart.
Printing is the classic service that is installed by default, rarely used on servers, and almost never watched. Two denial-of-service bugs in one release is a small event on its own. The recurring lesson is the bigger one: the code that listens for network printer advertisements has been a reliable source of trouble, and the cheapest fix is to stop listening where you never needed to.