Port 110 – POP3 (Post Office Protocol version 3)

Port 110 is the default port for POP3 (Post Office Protocol version 3), the protocol a mail client uses to pull messages off a server and, by default, delete them from the mailbox afterwards. On plain port 110 the whole exchange — the USER name, the PASS password, and every message body fetched with RETR — crosses the network in cleartext. The encrypted equivalent, POP3S on port 995, wraps the same protocol in TLS from the first byte, which is why an answering port 110 is worth a close look on any mail host.

Why It’s Open

POP3 is the old way to read mail, and old mail setups don’t get retired — they get left running. You’ll find port 110 on shared hosting and cPanel/Plesk boxes, small-business mail servers, ISP mailboxes that customers still hit from a decade-old Outlook profile, and appliances that email their own alerts. The daemon is usually Dovecot or Courier on Linux, Cyrus on larger sites, or whatever the hosting panel bundled. Where 110 is answering, its siblings usually are too — check for POP3S on 995, and for the IMAP pair on 143 and 993, since a host running one mail-retrieval protocol almost always runs the other. The SMTP side sits on port 25.

Common Risks

• Cleartext credentials. With USER/PASS auth and no TLS, the login and the mail itself are readable by anyone on the path — a coffee-shop network, a compromised switch, a tapped uplink. One captured session is a working mailbox login.
• STARTTLS that isn’t enforced. POP3 can upgrade to TLS mid-session with the STLS command, but if the server offers it without requiring it, an active attacker strips STLS from the greeting and the client falls back to plaintext — the downgrade the user never sees.
• Brute-force with no brakes. Most POP3 daemons ship without login throttling. Cleartext auth plus a leaked password list makes credential stuffing against 110 fast and quiet.
• Full mailbox exposure on one hit. POP3 has no folder model — a successful login means RETR over every message in the inbox. Account takeover here is total, not partial.
• Weak legacy auth. APOP and CRAM-MD5 were the old answer to cleartext passwords; both are broken enough that they buy little today, and their presence signals an unmaintained server.
• Banner and daemon disclosure. The +OK greeting often names the software and version outright (+OK Dovecot ready.), handing you the exact CVE list to check.

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 110 <target>

Run the POP3 NSE scripts

nmap -p 110 --script=pop3-capabilities,pop3-ntlm-info,banner <target>

Raw banner grab with netcat

nc -nv <target> 110

Walk a session by hand

nc -nv <target> 110
USER victim
PASS secret
STAT
LIST
RETR 1
QUIT

STAT returns the message count and mailbox size, LIST enumerates messages, and RETR 1 pulls the first one — all in cleartext if you skipped TLS.

Read the advertised capabilities

nc -nv <target> 110
CAPA

Look for STLS (is an upgrade even offered?) and the SASL line (which auth mechanisms are exposed — PLAIN, LOGIN, NTLM, CRAM-MD5).

Test the STARTTLS upgrade

openssl s_client -connect <target>:110 -starttls pop3

Brute-force with Hydra

hydra -L users.txt -P passwords.txt -f pop3://<target>

Metasploit modules

msfconsole -q
use auxiliary/scanner/pop3/pop3_version
set RHOSTS <target>
run

use auxiliary/scanner/pop3/pop3_login
set RHOSTS <target>
set USER_FILE users.txt
set PASS_FILE passwords.txt
set STOP_ON_SUCCESS true
run

Record every open port 110, the daemon banner, and any credential that works as you go, so the evidence lands in the pentest report instead of a terminal you’ll close by mistake.

What to Look For

Known CVEs and Exploits

• CVE-2019-11500 — Dovecot before 2.2.36.4 and 2.3.x before 2.3.7.2 mishandle \0 bytes in quoted strings in the protocol parsers, leading to an out-of-bounds write and remote code execution. Pre-auth and rated CVSS 9.8 — the most serious modern bug to hit a POP3/IMAP stack.
• CVE-2020-12673 — Dovecot before 2.3.11.3. A malformed NTLM SASL request triggers an out-of-bounds read that crashes the auth service, taking POP3 and IMAP logins down with it. No credentials needed.
• CVE-2003-0264 — The classic Seattle Lab Mail (SLMail) 5.5 overflow: an over-long password to the POP3 server smashes the stack for unauthenticated code execution. Still a training staple, weaponised as Metasploit’s exploit/windows/pop3/seattlelab_pass and archived on Exploit-DB 638.
• CVE-2011-1926 — Cyrus IMAP before 2.4.7 buffers I/O across the STLS/STARTTLS boundary, so a man-in-the-middle can inject a cleartext command that runs inside the encrypted session. The archetype for why STARTTLS on 110 is riskier than implicit TLS on 995.

Mitigation

• Prefer implicit TLS on 995. Move clients to POP3S (port 995), where the session is encrypted from the first byte and there’s no plaintext phase to strip. Retire plaintext 110 wherever the clients allow it.
• If 110 must stay, forbid plaintext auth before TLS. In Dovecot that’s disable_plaintext_auth = yes, which refuses USER/PASS until STLS has run — no silent downgrade.
• Drop the weak mechanisms. Turn off APOP and cleartext CRAM-MD5; keep auth behind TLS instead of leaning on broken challenge-response.
• Throttle logins. Put fail2ban or the daemon’s own rate limiting on repeated -ERR responses so brute-force and stuffing stall.
• Patch the daemon. Run Dovecot 2.3.11.3 or later, keep Courier/Cyrus current, and never expose an unmaintained POP3 server.
• Firewall port 110 to the networks that genuinely need it — or close it and standardise on 995 and IMAP over 993.

Real-World Example

In 2021 the “NO STARTTLS” study (Poddebniak, Ising, Böck, and Schinzel, USENIX Security) ran the first structured audit of STARTTLS across SMTP, POP3, and IMAP and turned up more than 40 vulnerabilities — plaintext command injection, buffered-command carryover across the TLS boundary, and naive STLS stripping. Their internet-wide scan found roughly 320,000 mail servers exposed to command injection, and named clients from Thunderbird to Apple Mail to Mutt. The takeaway landed in RFC 8314: stop trusting the opportunistic upgrade and use implicit TLS on the dedicated ports — 995 for POP3, 993 for IMAP — which is exactly the migration an exposed port 110 should be flagged for.

FAQ

What is port 110 used for?

Port 110 is the default POP3 port. A mail client connects to it to authenticate, download messages from the server with RETR, and usually delete them from the mailbox afterwards. On plain port 110 none of that is encrypted, which is why modern setups use POP3S on port 995 instead.

Is port 110 dangerous?

On an untrusted network, yes. Standard POP3 sends the username, password, and every email in cleartext, and most servers don’t throttle login attempts — so credentials can be sniffed off the wire or guessed at speed. Treat an internet-facing port 110 as something to encrypt, restrict, or replace with 995.

What’s the difference between port 110 and port 995?

Both carry POP3. Port 110 is the plaintext version (encryption is optional, via the STLS upgrade, and often not enforced). Port 995 is POP3S — the identical protocol wrapped in TLS from the start, with no unencrypted phase for an attacker to strip or inject into. For anything sensitive, 995 is the safe default.

How do I close or secure port 110?

Move mail clients to POP3S on 995, and if port 110 has to stay open, require STLS before authentication (disable_plaintext_auth = yes in Dovecot), rate-limit failed logins, patch the daemon, and firewall the port to trusted networks. If nothing needs plaintext POP3, stop the service and rescan with nmap -p 110 <target> to confirm it’s closed.

TL;DR

• Service: POP3 (Post Office Protocol version 3), email retrieval
• Default port: 110/TCP (encrypted POP3S on 995/TCP)
• Biggest risk: cleartext credentials and mail, plus unthrottled brute-force
• Mitigation: move to POP3S on 995, enforce STLS, throttle logins, patch the daemon