CUPS 2.4.15 Fixes 'Slow Client' DoS Threat That Can Paralyze Print Servers

A single client transmitting at a glacial pace—no faster than one byte per second—can bring an entire CUPS-powered printing infrastructure to its knees, blocking all other print jobs and queries. The OpenPrinting project has released CUPS 2.4.15 to plug this denial-of-service hole, tracked as CVE-2025-58436, and the fix is now trickling down through major Linux distributions.

The Attack: A Trickle That Stops Everything

The vulnerability is a classic “slow client” or slow-Loris-style resource exhaustion. CUPS, the de facto printing system on Linux and Unix, uses a single-threaded scheduling model for handling incoming IPP (Internet Printing Protocol) connections. When a client connects and sends data extremely slowly—for example, a proof-of-concept script shows a loop sending one byte every second—the daemon (cupsd) gets stuck waiting for a full line or meaningful input. Instead of timing out and moving on, it blocks other clients from being served.

Researchers demonstrated the issue by running two commands side by side: one that sends a single character repeatedly with a one-second delay to port 631, and another that polls the printer status with lpstat -p. On an unpatched system, the status query stalls or takes many seconds longer, proving the daemon is effectively paralyzed. The attack requires no authentication; simply opening a TCP connection and dribbling data is enough to cause the denial of service.

The flaw was assigned CWE-400 (Uncontrolled Resource Consumption) and a medium severity rating, with the primary impact being availability. Because the attack vector is local or adjacent—cupsd listens only on localhost in default configurations—remote exploitation is only possible if the print server is misconfigured to accept connections from untrusted networks.

The Fix: Timeouts and Cleaner Handshakes

The CUPS maintainers fixed the issue in version 2.4.15 without a massive architectural overhaul, which would have introduced unacceptable regression risks. Instead, they implemented a set of targeted changes:

• Bounded waits: The daemon now enforces timeouts when waiting for a full input line from a client. If a client doesn’t send enough data within a reasonable window, the connection is dropped, freeing the scheduler for other clients.
• TLS handshake adjustments: Previously, the server waited indefinitely for a complete TLS Client Hello. The fix ensures that handshake paths don’t monopolize the scheduling thread.
• Optional upgrade removal: The patch removed support for the optional RFC 2817 protocol upgrade mechanism because it conflicted with the new handshake timing guards.
• Read buffering improvements: Some reads were changed from “read whole line” semantics to buffered reads with timeout checks, reducing the window during which a slow client can lock the server.

These changes were applied to the stable 2.4.x branch and are available in the upstream 2.4.15 source code. Distributions are picking up the patch at different speeds. For example, Debian unstable already contains the fixed package (cups 2.4.15-1), and SUSE has issued a dedicated security update.

What It Means for You

Home Users and Single-User Desktops

If CUPS is installed on your personal machine and you haven’t tampered with its default configuration, the risk is low. cupsd binds only to localhost, meaning an attacker would need local access or a separate compromised process on your machine to exploit the flaw. Still, you should apply the update when your distribution offers it to prevent any possibility of disruption.

Enterprise Print Servers and Mixed Environments

Organizations that rely on centralized CUPS servers to handle printing for Windows, macOS, or Linux clients face a more significant threat. If that print server is reachable from any network segment that isn’t fully trusted—such as a guest Wi-Fi network, a multi-tenant cloud environment, or a misconfigured firewall—an attacker can remotely disable printing for the entire organization.

Windows shops are not directly vulnerable, because Windows does not run CUPS natively, but many enterprises deploy Linux-based print servers to serve Windows clients via IPP or Samba. When those servers are knocked offline, Windows users lose their ability to print. A single malicious laptop on the local network can therefore become a pain point for hundreds of users.

Cloud and Containerized Workloads

Environments that expose printing services to the internet or share a print server among multiple tenants (e.g., in Kubernetes clusters with IPP front-ends) are at elevated risk. Publicly reachable port 631 effectively invites attackers to test the slow-client payload. If you operate such a service, patching is urgent.

How We Got Here

CUPS has been the backbone of Linux printing since 1999, and its architecture was designed for a different era. The daemon’s request handling is primarily single-threaded, a simplification that worked well when networks were smaller and print volumes predictable. Over the years, security researchers have uncovered various vulnerabilities in CUPS, but the slow-client pattern is a recurring theme in server software. The maintainers deliberately avoided a multithreaded redesign for this fix to preserve stability and minimize regressions.

The discovery of CVE-2025-58436 was coordinated with OpenPrinting, and the fix was merged into the CUPS source shortly before the public advisory. The vulnerability was given a medium CVSS score, but that rating can be misleading: in practice, a single well-placed attack can cause significant operational disruption.

What to Do Now: A Practical Checklist

1. Patch Immediately

The most effective defense is to install the update. Check your distribution’s package manager for cups version 2.4.15 or a backported fix.

After updating, restart the service:

sudo systemctl restart cups.service
sudo systemctl status cups.service

2. Enforce Network Controls (If Patching Is Delayed)

If you can’t upgrade immediately, restrict access to TCP port 631 to only trusted subnets and management hosts. Use host firewall rules:

# Example: Allow only from 192.168.1.0/24
sudo iptables -A INPUT -p tcp --dport 631 -s 192.168.1.0/24 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 631 -j DROP

Also check your CUPS configuration file (/etc/cups/cupsd.conf). Ensure the Listen directive does not expose the service to untrusted interfaces; the default is Listen localhost:631. If you require remote printing, use Allow directives to limit access.

3. Monitor and Detect

Before or after patching, keep an eye out for suspicious connections. Look for long-lived, low-throughput TCP sessions to port 631 in network flow logs. On the server, monitor cupsd access logs for connections that send data sporadically. A simple check: regularly run lpstat -p from a different host; if it suddenly becomes slow or times out, investigate for an ongoing slow-client attack.

4. Coordinate with Windows Teams

If you manage print servers that serve Windows clients, inform your helpdesk and system administrators about the patch cycle. Schedule a maintenance window, update the servers, and test printing from a Windows machine immediately afterward to catch any regressions (e.g., due to the RFC 2817 upgrade removal if you previously relied on it).

Outlook

CVE-2025-58436 is a timely wake-up call: infrastructure services that we seldom think about—like print servers—can become single points of failure when neglected. While the fix is straightforward, the underlying architectural limitations of CUPS mean that further resource-exhaustion bugs may surface in the future. The OpenPrinting project continues to maintain CUPS responsibly, but administrators would be wise to treat print servers with the same security rigor they apply to web servers, regularly updating them and isolating them from untrusted networks.

For now, the remedy is simple: upgrade to CUPS 2.4.15 or your distribution’s equivalent, and make sure your print server isn’t offering an open invitation to the slowest denial-of-service attack in the book.