logo

Port 631 – IPP (Internet Printing Protocol)

Service:

ippCUPS (cupsd)cups-browsed

Protocol:

TCP/UDP

Port:

631

Used for:

IPP print submission and management, plus the CUPS web administration interface, on Linux, macOS, and network printers

Port 631 is the default port for IPP (Internet Printing Protocol), the modern print protocol implemented by CUPS (the Common UNIX Printing System, daemon cupsd). It’s the print channel on almost every Linux and macOS host, on many appliances, and on the majority of network printers and MFPs. Because IPP runs over HTTP, port 631 is really a small web server that speaks printing — it carries print jobs, exposes the CUPS web administration interface, and answers status queries. It listens on 631/TCP for IPP and the admin UI, while the CUPS discovery helper cups-browsed listens on 631/UDP. That combination is exactly why port 631 went from “boring printer port” to headline news in September 2024, when a four-CVE chain in CUPS turned an exposed listener into unauthenticated remote code execution.

Where port 631 is open, its printing siblings are usually one scan away — check for LPD on port 515 and the raw/JetDirect channel on port 9100, which typically front the same device. They’re different protocols, so don’t conflate them, but a single printer often exposes all three at once.

Why It’s Open

IPP is the default answer for printing on modern systems, so an open 631 is usually legitimate — but frequently more exposed than the admin intended. On Linux and macOS, cupsd binds 631 to serve local printing and the admin interface; on many distributions the cups-browsed service is also running to auto-discover printers, and older builds bound it to INADDR_ANY on 631/UDP so it answered the whole network (and, when firewalls were sloppy, the whole internet). Network printers and multifunction devices ship an IPP listener on 631 alongside LPD (515) and raw printing (9100), because IPP is the standard, TLS-capable way for any OS to queue a job. Where 631 is reachable from untrusted networks, it’s normally a print server or appliance whose admin interface and discovery service were never locked down.

Common Risks

  • The 2024 CUPS RCE chain. The headline risk. On hosts running a vulnerable cups-browsed (≤ 2.0.1), an attacker on the network can advertise a malicious printer; the next print job to it runs an attacker-controlled command as the print user. It chains four issues — cups-browsed trusting any UDP packet (CVE-2024-47176), unsanitized IPP attributes in libcupsfilters (CVE-2024-47076) and libppd (CVE-2024-47175), and command execution via foomatic-rip (CVE-2024-47177). Covered in detail below.
  • DDoS amplification. The same cups-browsed flaw (CVE-2024-47176) is a potent reflector: a single ~30-byte UDP packet makes the host fire a much larger IPP request at a victim of the attacker’s choosing — Akamai measured amplification up to ~600× across tens of thousands of exposed hosts.
  • Exposed CUPS admin interface. Port 631/TCP serves the web admin UI. If it’s reachable and access controls are weak, an attacker can enumerate printers and jobs, add or modify printers, and read configuration — information disclosure that also sets up the RCE chain.
  • Unauthenticated printing and job/metadata disclosure. Misconfigured IPP endpoints accept jobs with no auth (spoofing, spool-flooding DoS) and leak queue contents — usernames, hostnames, document titles, and sometimes the spooled files.
  • Historic cupsd RCE. Older CUPS had genuinely serious pre-auth memory-corruption bugs reachable over IPP (e.g. CVE-2015-1158). Any legacy cupsd is worth fingerprinting.
  • Plaintext by default. IPP can run over TLS, but plenty of endpoints still speak cleartext on 631, so jobs and metadata are sniffable on the wire.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

logo-cta

Enumeration & Testing

Detect the service and grab the version

Terminal window
nmap -sV -p 631 <target>

Run the CUPS NSE scripts

Terminal window
# cups-info lists the printers managed by the service;
# cups-queue-info lists currently queued jobs, grouped by printer
nmap -p 631 --script cups-info,cups-queue-info <target>

Check for cups-browsed on UDP 631

Terminal window
# The 2024 chain and the DDoS amplification both start here
nmap -sU -p 631 <target>

Browse the CUPS web admin interface

Terminal window
# 631 is an HTTP(S) server — the admin UI, printer list, and job list are pages
curl -sk https://<target>:631/
curl -sk https://<target>:631/printers/
curl -sk https://<target>:631/jobs/

Query a printer with ipptool (ships with CUPS)

Terminal window
# Get-Printer-Attributes returns make/model, state, and supported operations
ipptool -tv ipp://<target>:631/ipp/print get-printer-attributes.test

Discover IPP printers on the segment

Terminal window
ippfind

For the 2024 chain, the public proof-of-concept (Simone Margaritelli / evilsocket) drives cups-browsed into fetching attacker-controlled IPP attributes and plants a malicious printer — validate it in a lab, and confirm both that cups-browsed is listening and that a print job actually reaches the injected queue before calling it exploitable.

Log every open port 631, every readable admin page, and every printer or job you can reach so the evidence lands in the pentest report instead of a scratch terminal.

What to Look For

Checkpoint What it means
631/TCP open, CUPS admin UI reachable Web admin exposed — add-printer abuse, printer/job disclosure
631/UDP open, cups-browsed responding CVE-2024-47176 — remote printer injection and DDoS amplification
cups-browsed ≤ 2.0.1 / unpatched cups-filters, libppd 2024 RCE chain — malicious printer + a print job → command execution as lp
Plaintext IPP, no TLS or auth Jobs and metadata interceptable; anonymous job submission
CUPS < 2.0.3 in the version string CVE-2015-1158 — crafted IPP request → memory corruption → RCE
Get-Printer-Attributes leaks make/model/queues Device and queue fingerprinting; pivot to 515 / 9100 on the same box

Known CVEs and Exploits

Port 631’s defining bugs are the September 2024 CUPS chain disclosed by Simone Margaritelli (evilsocket). Four CVEs combine so that an attacker on the network advertises a fake printer via cups-browsed, and the next print job to that printer executes an attacker-controlled command as the print user. The individual links:

  • CVE-2024-47176cups-browsed (≤ 2.0.1) binds INADDR_ANY:631/UDP and trusts any packet, so an attacker can make it send a Get-Printer-Attributes IPP request to an attacker-controlled URL. The entry point of the chain, and the DDoS amplification vector. NVD CVSS 3.1 5.3 (Medium).
  • CVE-2024-47076libcupsfilters: cfGetPrinterAttributes5 does not validate the IPP attributes returned by the (attacker-controlled) IPP server, feeding tainted data into the rest of CUPS. NVD CVSS 3.1 8.6 (High).
  • CVE-2024-47175libppd: ppdCreatePPDFromIPP2 writes those unsanitized IPP attributes straight into a generated PPD file. NVD CVSS 3.1 9.8 (Critical).
  • CVE-2024-47177cups-filters foomatic-rip: any value passed via the FoomaticRIPCommandLine PPD directive is executed as a command — the step that turns the poisoned PPD into code execution. Originally rated critical (~CVSS 9.0 by the CUPS/Red Hat CNA); NVD later rejected this ID (2025-05-12) as a duplicate of the three above, so treat it as the command-execution component of the same single flaw rather than a separate scored CVE. Advisory: GHSA-p9rh-jxmq-gq47.

Reality check: despite early “instant unauthenticated internet RCE” headlines, the chain needs cups-browsed to be running and listening and a print job to actually be sent to the malicious printer — so it’s most dangerous where 631/UDP is exposed and printing is routine. Even where RCE isn’t reachable, CVE-2024-47176 alone makes the host a usable DDoS reflector (Akamai: ~198k CUPS hosts exposed, ~58k abusable, up to ~600× amplification). Patch CUPS, cups-filters, libcupsfilters, and libppd, and disable cups-browsed if it isn’t needed.

Older CUPS issues worth checking against the version string:

  • CVE-2015-1158add_job in scheduler/ipp.c in cupsd before 2.0.3 performs incorrect free operations on multi-value job-originating-host-name attributes. A crafted IPP request corrupts memory and can lead to arbitrary code execution — a pre-auth, network-reachable bug (CVSS v2 10.0). Exploit-DB 37336.
  • CVE-2023-32324 — heap buffer overflow in format_log_line in OpenPrinting CUPS ≤ 2.4.2, reachable only when LogLevel is set to debug; a remote denial of service rather than code execution (NVD CVSS 3.1 5.5 Medium; GitHub CNA rates it 7.5). Minor, and often not applicable in production configs.

(The previous version of this page listed CVE-2020-10001 as “unauthenticated access to printer logs in CUPS” and CVE-2019-2224 as a CUPS DoS — both are mislabeled. CVE-2020-10001 is a macOS restricted-memory read, and CVE-2019-2224 is an Android print-spooler issue; neither is a CUPS/631 finding, so they’ve been removed.)

Mitigation

  • Disable or remove cups-browsed. This is the first move — it’s the entry point of the 2024 chain and the DDoS reflector. Stop and mask the service where it isn’t used, and stop cupsd too on hosts that don’t print.
  • Block 631/UDP and restrict 631/TCP. Firewall UDP 631 entirely, and limit TCP 631 (IPP and the admin UI) to localhost or a management range. Never expose printing to the internet.
  • Patch CUPS and its filters. Update cups, cups-filters, libcupsfilters, and libppd to versions that fix the 2024 chain, and never run cupsd older than 2.0.3 (CVE-2015-1158).
  • Enforce TLS and authentication. Require IPP over HTTPS and authentication for job submission and admin functions; disable anonymous printing.
  • Lock down the admin interface. Restrict who can reach /admin, use strong credentials, and audit the printer and job configuration for open queues.
  • Segment printers. Put printers and print servers on an isolated VLAN so an exposed 631 — and the 515 and 9100 listeners next to it — can’t be reached from general user networks. Lock all three printing ports down together.

Real-World Example

On 26 September 2024, security researcher Simone Margaritelli (evilsocket) disclosed the CUPS chain after weeks of teasing an “unauthenticated RCE affecting all GNU/Linux systems.” The internet braced for a Heartbleed-scale event. The reality was more nuanced but still serious: cups-browsed, enabled on many desktop and server distributions, listened on 631/UDP and would trust an attacker’s packet, fetch attacker-controlled IPP attributes, and register a malicious printer — and the moment someone printed to it, foomatic-rip executed the attacker’s command as the print user. It wasn’t instant internet-wide RCE (it needed cups-browsed running and an actual print job), but hundreds of thousands of hosts had 631 exposed, and researchers quickly showed the same flaw made those hosts into ~600× DDoS reflectors. It’s a textbook case of why a “printing port” deserves the same scrutiny as any remote service: 631 is a web server, a discovery daemon, and a print pipeline all at once, and every one of those parsed attacker-controlled input.

FAQ

What is port 631 used for?

Port 631 is the default port for the Internet Printing Protocol (IPP), used by CUPS (the Common UNIX Printing System) to submit and manage print jobs and to serve its web administration interface. IPP runs over HTTP, so 631 behaves like a small print-aware web server. CUPS uses 631/TCP for IPP and the admin UI, and cups-browsed uses 631/UDP for printer discovery.

Is port 631 dangerous?

It can be. An exposed 631 can leak printer and job data, accept unauthenticated jobs, and — on hosts running a vulnerable cups-browsed — be chained into remote code execution via the 2024 CUPS flaws, or abused as a high-amplification DDoS reflector. Treat an internet-facing port 631 as something to close, and any unpatched CUPS as something to update.

What service runs on port 631?

CUPS — specifically the cupsd daemon serving IPP and the admin interface on 631/TCP, and often the cups-browsed discovery helper on 631/UDP. On a network printer or MFP it’s the device’s built-in IPP listener.

What is the CUPS vulnerability on port 631?

The September 2024 chain: CVE-2024-47176 (cups-browsed trusts any UDP packet), CVE-2024-47076 (libcupsfilters) and CVE-2024-47175 (libppd) failing to sanitize attacker-supplied IPP attributes, and CVE-2024-47177 (foomatic-rip command execution). Together they let an attacker plant a malicious printer so that a print job runs arbitrary commands. Patch CUPS and disable cups-browsed where it isn’t needed.

What’s the difference between port 631, 515, and 9100?

All three are printing ports but different protocols: 631 is IPP (the modern, HTTP-based, TLS-capable protocol used by CUPS), 515 is LPD/LPR (the legacy Berkeley protocol), and 9100 is raw/JetDirect printing (a direct socket to the print engine). A single network printer often exposes all three at once.

How do I secure or close port 631?

Disable or remove cups-browsed, stop cupsd if the host doesn’t print, block UDP 631 and restrict TCP 631 to localhost or a management range, patch CUPS and its filter libraries, enforce IPP over TLS with authentication, and segment printers onto their own VLAN. Rescan with nmap -p 631 <target> to confirm the port is closed.

TL;DR

  • Service: IPP (Internet Printing Protocol) via CUPS — cupsd on 631/TCP, cups-browsed on 631/UDP (siblings: 515 LPD, 9100 raw/JetDirect)
  • Default port: 631/TCP and 631/UDP
  • Biggest risk: the 2024 CUPS RCE chain (CVE-2024-47076 / 47175 / 47176 / 47177) via cups-browsed, plus DDoS amplification and an exposed admin interface
  • Mitigation: disable cups-browsed, block UDP 631 and restrict TCP 631, patch CUPS/cups-filters/libppd, enforce TLS + auth, segment printers