Port 515 – LPD (Line Printer Daemon)

Port 515 is the default port for LPD (Line Printer Daemon), the Berkeley printing service that accepts print jobs from lpr clients and manages the spool queue on a Unix host or network printer. Defined in RFC 1179, the protocol is old, cleartext, and typically unauthenticated — access control is by hostname only. So an open port 515 is usually one of two things: a legacy Unix print server, or a network printer / print server that still speaks the old protocol. Either way it’s worth a look, because the daemons that implement it (lpd, LPRng, Solaris in.lpd, and CUPS’s cups-lpd compatibility shim) have a long history of remote pre-auth code execution.

Where port 515 is open, its printing siblings are often one scan away — check for IPP on port 631 and the raw/JetDirect channel on port 9100, which usually front the same device.

Why It’s Open

LPD predates the modern print stack and never fully went away. You’ll still find it on legacy Solaris, AIX, HP-UX, and older Linux servers where an inetd/xinetd entry nobody cleaned up keeps the daemon listening. It’s also baked into hardware: network printers and multifunction devices almost universally expose an LPD listener on 515 alongside IPP (631) and raw printing (9100), because lpr is the lowest-common-denominator way for any OS to queue a job. On Linux the modern implementation is usually CUPS’s cups-lpd shim run from a super-server; on the appliances it’s whatever the firmware bundled. Where 515 is open on a modern host, it’s normally an accident of a legacy compatibility option left switched on.

Common Risks

• Historic pre-auth RCE. The LPD daemons have a genuinely bad track record: LPRng’s use_syslog() format string (CVE-2000-0917) and the Solaris/BSD in.lpd “transfer job” overflows (CVE-2001-0353, CVE-2001-0670) all gave remote root with no authentication. Any legacy lpd/LPRng build is worth fingerprinting against these.
• Unauthenticated job submission. Classic LPD has no real login. Anyone who can reach 515 can queue jobs, which means print-job spoofing, spool flooding to exhaust disk/queue (DoS), and — on buggy daemons — directory-traversal file operations like the Solaris “Unlink data file” delete (CVE-2005-4797).
• Information disclosure. Querying the queue with lpq leaks job metadata — usernames, hostnames, filenames, and job sizes — and on some stacks the spooled documents themselves. Print jobs frequently contain sensitive data.
• Hostname-only access control. LPD trust is based on the client’s source host (/etc/hosts.lpd, hosts.equiv), which is trivial to spoof on a flat network.
• Cleartext everywhere. Jobs, control files, and queue data all cross the wire unencrypted and sniffable.
• A printer behind the port. An LPD listener usually fronts a physical printer whose 9100/PJL/PostScript interface can be driven with a tool like PRET — capturing or manipulating jobs, reading the device’s filesystem/NVRAM, or causing physical damage.

Want to save time on reporting?

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

Book a Demo

Enumeration & Testing

Detect the service and grab the banner

nmap -sV -p 515 <target>

There is no dedicated LPD vulnerability NSE script — version detection plus the native lpr/lpq clients do the enumeration. (The printer-specific NSE scripts like cups-info and cups-queue-info target IPP on 631, and hp-printer-info targets 9100.)

Read the print queue (unauthenticated)

lpq -h <target> -P <queue>

Raw RFC 1179 queue probe with netcat

# 0x03 = "send queue state (short)" for the named queue
printf '\x03default\n' | nc <target> 515

Submit a test job

lpr -H <target> -P <queue> testfile.txt

Metasploit modules

msfconsole -q

# LPRng use_syslog() format string → RCE (CVE-2000-0917)
use exploit/linux/misc/lprng_format_string
set RHOSTS <target>
run

# Solaris in.lpd command execution (CVE-2001-0353)
use exploit/solaris/lpd/sendmail_exec
set RHOSTS <target>
run

# Solaris lpd "Unlink data file" arbitrary delete (CVE-2005-4797)
use auxiliary/dos/solaris/lpd/cascade_delete
set RHOSTS <target>
run

Attack the printer behind the port with PRET

# PRET drives the device over raw 9100 (or USB), speaking PostScript/PJL/PCL
python pret.py <target> pjl

Log every open port 515, every readable queue, and every credential or job you can access so the evidence lands in the pentest report instead of a scratch terminal.

What to Look For

Known CVEs and Exploits

LPD’s worst bugs are old, but they were serious — several are pre-auth remote root, and they were mass-exploited in their day. Verify the daemon and version before assuming a finding applies.

• CVE-2000-0917 — Format string in the use_syslog() function of LPRng 3.6.24. An unauthenticated remote attacker executes arbitrary commands as root (CVSS v2 10.0). This is the SANS/CERT-era mass-exploited one — it shipped in Red Hat 7.0, which was pulled and re-released as “7.0-respin.” Metasploit exploit/linux/misc/lprng_format_string, Exploit-DB 16842.
• CVE-2001-0353 — Buffer overflow in Solaris in.lpd (Solaris 8 and earlier) via the “transfer job” routine, giving local and remote attackers root (CVSS v2 10.0). CERT CA-2001-15. Metasploit exploit/solaris/lpd/sendmail_exec (the Dino Dai Zovi technique), Exploit-DB 21097.
• CVE-2001-0670 — Buffer overflow in the BSD lpd/in.lpd across various BSD-based systems, triggered by an incomplete print job followed by a request to display the printer queue, allowing remote code execution (CVSS v2 7.5).
• CVE-2005-4797 — Directory traversal in the Solaris printd/lpd (Solaris 7–10): .. sequences in an “Unlink data file” command let a remote attacker delete arbitrary files (CVSS v2 5.0). Metasploit auxiliary/dos/solaris/lpd/cascade_delete.

Vendor lpd builds have their own history too — IBM AIX’s line printer daemon carried several remote overflows (CERT VU#466239 chk_fhost, VU#722143 send_status, VU#388183 kill_print). If you find LPD on any legacy Unix, fingerprint the exact daemon and version rather than trusting the port alone.

Mitigation

• Disable LPD if it isn’t used. This is the first move. On Linux, stop cups-lpd (remove the xinetd/socket entry); on Solaris/BSD, disable in.lpd. Prefer IPP/CUPS with authentication and TLS for modern printing.
• Patch the daemon. Never run LPRng ≤ 3.6.24 or the vulnerable Solaris/BSD in.lpd builds. Move to a maintained CUPS.
• Firewall port 515 so it’s reachable only from the specific print servers or client range that need it — never from the internet.
• Restrict allowed hosts with /etc/hosts.lpd (or the daemon’s equivalent) and treat hostname trust as weak, not a real control.
• Segment printers. Put printers and print servers on an isolated VLAN so an exposed 515 (and the 9100/631 next to it) can’t be reached from general user networks.
• Watch the sibling ports. If you close 515 but leave 9100 or 631 open, the printer is still exposed — lock all three down together.

Real-World Example

In the fall of 2000, CVE-2000-0917 turned into one of the era’s defining Linux compromises. LPRng — the LPD replacement that most Linux distributions had adopted — was missing format-string arguments in its use_syslog() calls, so a single crafted print request handed an unauthenticated remote attacker a root shell. Because Red Hat 7.0 shipped the vulnerable LPRng and left it enabled, the flaw was reachable out of the box; Red Hat ultimately pulled 7.0 and re-released it as the “7.0-respin.” Worm and mass-scanning activity against port 515 followed, and for months an exposed LPD listener was effectively an open root shell. It’s a clean example of why a “boring” printing port deserves the same scrutiny as any remote-login service — the daemon behind it runs as root and parses attacker-controlled input.

FAQ

What is port 515 used for?

Port 515 is the default TCP port for the Line Printer Daemon (LPD) protocol, defined in RFC 1179. It accepts print jobs from lpr clients and manages the spool queue on a Unix host, print server, or network printer. It’s a legacy service, largely superseded by IPP.

Is port 515 dangerous?

It can be. LPD is cleartext and usually unauthenticated, so an exposed 515 allows job spoofing, spool-flooding DoS, and queue/metadata disclosure — and the classic daemons (LPRng, Solaris/BSD in.lpd) had remote pre-auth root bugs. Treat an internet-facing port 515 as something to close, and any legacy lpd build as something to patch or retire.

What service runs on port 515?

The line printer daemon — lpd, LPRng, Solaris in.lpd, or CUPS’s cups-lpd compatibility service, depending on the system. On a printer or MFP it’s the device’s built-in LPD listener.

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

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

How do I secure or close port 515?

Disable the LPD daemon if nothing needs it (stop cups-lpd / in.lpd), move printing to IPP/CUPS with authentication, patch any legacy LPRng/in.lpd, firewall 515 to the print servers that require it, restrict allowed hosts, and put printers on a segmented network. Rescan with nmap -p 515 <target> to confirm the port is closed.

TL;DR

• Service: LPD (Line Printer Daemon) — lpd / LPRng / Solaris in.lpd / cups-lpd, RFC 1179
• Default port: 515/TCP (siblings: 631 IPP, 9100 raw/JetDirect)
• Biggest risk: cleartext, unauthenticated job submission plus historic pre-auth root RCE (CVE-2000-0917 LPRng, CVE-2001-0353/0670 in.lpd)
• Mitigation: disable LPD if unused (prefer IPP/CUPS with auth), patch the daemon, firewall 515 to print servers, restrict hosts, segment printers