Port 143 – IMAP (Internet Message Access Protocol)

Port 143 is the default port for IMAP (Internet Message Access Protocol), the protocol a mail client uses to read and manage messages that stay stored on the server — folders, flags, search, and all — instead of downloading and deleting them the way POP3 on port 110 does. On plain port 143 the login and, unless the session is upgraded to TLS with STARTTLS, every message the client fetches cross the network in cleartext. The encrypted equivalent, IMAPS on port 993, wraps the same protocol in TLS from the first byte, which is why an answering port 143 is always worth a close look on a mail host.

Why It’s Open

IMAP is how most mailboxes are actually read, and the plaintext port that carries it rarely gets turned off. You’ll find port 143 on shared hosting and cPanel/Plesk boxes, small-business and ISP mail servers, self-hosted Dovecot, Cyrus, Zimbra, and iRedMail stacks, and appliances that expose a mailbox for their own alerts. The daemon is usually Dovecot or Cyrus on Linux, UW-IMAP on older UNIX, or whatever the hosting panel bundled. Many servers keep 143 open only to offer a STARTTLS upgrade to clients that ask for it, even when they’d rather you used 993 — which means the plaintext phase is still there to be attacked. Where 143 is answering, its siblings usually are too: check for IMAPS on 993, the POP3 pair on 110 and 995, and the SMTP send side on 25 and 587.

Common Risks

• Cleartext credentials and mail. With a LOGIN before any TLS, the username, password, and every message pulled with FETCH are readable by anyone on the path — a shared network, a compromised switch, a tapped uplink. One captured session is a working mailbox login.
• STARTTLS that isn’t enforced. IMAP can upgrade to TLS mid-session with STARTTLS, but if the server offers it without requiring it, an active attacker strips the capability from the greeting and the client falls back to plaintext — the downgrade the user never sees. Buggy STARTTLS handling can be worse still, letting a cleartext command be injected into the encrypted session (the CVE-2011-1926 class).
• Brute-force and password spraying that bypass MFA. Most IMAP daemons ship without login throttling, and legacy IMAP basic auth often sidesteps multi-factor entirely — a third-party client speaking IMAP never sees the MFA prompt. That combination made IMAP the dominant initial-access vector for cloud mailbox takeover.
• Total mailbox exposure on one hit. Unlike POP3, IMAP keeps everything server-side, so a single successful login exposes every folder, the full search index, and the entire message history — which an attacker can silently read, export, and then persist in by adding forwarding or delegation rules.
• Auth-mechanism downgrade. A server that advertises AUTH=PLAIN or AUTH=LOGIN over a pre-TLS session hands passive capture the credentials on a plate.
• Banner and capability disclosure. The greeting and the CAPABILITY response often name 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 143 <target>

Run the IMAP NSE scripts

nmap -p 143 --script=imap-capabilities,imap-ntlm-info,banner <target>

Raw banner and capability probe with netcat

nc -nv <target> 143
# once connected:
a1 CAPABILITY
a2 LOGOUT

Look for LOGINDISABLED (is cleartext login refused before TLS?), STARTTLS (is an upgrade even offered?), and the AUTH= mechanisms exposed on the plaintext port.

Walk a session by hand

nc -nv <target> 143
a1 LOGIN victim secret
a2 LIST "" "*"
a3 SELECT INBOX
a4 FETCH 1 BODY[]
a5 LOGOUT

LIST enumerates every folder, SELECT INBOX opens one, and FETCH 1 BODY[] pulls the first message — all in cleartext if you skipped the TLS upgrade.

Test the STARTTLS upgrade

openssl s_client -connect <target>:143 -starttls imap -crlf
# then, inside TLS:
a1 CAPABILITY
a2 LOGIN user@example.com password
a3 LOGOUT

Brute-force with Hydra

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

Metasploit modules

msfconsole -q
use auxiliary/scanner/imap/imap_version
set RHOSTS <target>
run

# stand up a rogue IMAP server to capture plaintext logins
use auxiliary/server/capture/imap
run

Record every open port 143, the daemon banner, the advertised capabilities, and any credential that works, 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 the NUL byte when scanning quoted strings in the IMAP (and ManageSieve) protocol parsers, causing an out-of-bounds heap write. It is reachable pre-login and rated CVSS 9.8 — the most serious modern bug to hit an IMAP/POP3 stack, with skilled exploitation leading to information disclosure or remote code execution.
• CVE-2011-1926 — Cyrus IMAP before 2.4.7 doesn’t properly restrict I/O buffering across the STARTTLS boundary, so a man-in-the-middle can send a cleartext command that is processed inside the encrypted session. The archetype for why STARTTLS on 143 is riskier than implicit TLS on 993.
• CVE-2018-19518 — Argument injection in the UW-IMAP toolkit 2007f as used by PHP’s imap_open(). On Debian/Ubuntu, where rsh links to ssh, an IMAP server name containing a -oProxyCommand argument runs arbitrary OS commands. CVSS 7.5, weaponised as Metasploit’s exploit/linux/http/php_imap_open_rce and Exploit-DB 45914.
• CVE-2017-14461 — Dovecot up to 2.2.33.2. A specially crafted email triggers an out-of-bounds read in the parser, leaking adjacent memory (information disclosure) or crashing the service. CVSS 7.1.
• CVE-2024-23184 — Dovecot up to 2.3.21. A message with a very large number of address headers (From, To, Cc, Bcc, …) makes parsing pathologically CPU-intensive — 500k header lines took roughly 18 minutes — so a crafted email becomes a denial-of-service. CVSS 5.0.

Mitigation

• Prefer implicit TLS on 993. Move clients to IMAPS (port 993), where the session is encrypted from the first byte and there is no plaintext phase to strip or inject into. Retire plaintext 143 wherever the clients allow it.
• If 143 must stay, forbid plaintext auth before TLS. In Dovecot that’s disable_plaintext_auth = yes with ssl = required, which refuses LOGIN until STARTTLS has run — no silent downgrade.
• Kill legacy basic auth and enforce MFA. Disable app-password / legacy IMAP auth and require OAuth2 with multi-factor at the mail gateway. Microsoft deprecated Basic Authentication for IMAP in Exchange Online in October 2022 for exactly this reason — legacy IMAP was the MFA-bypass path.
• Throttle logins. Put fail2ban or the daemon’s own rate limiting (Dovecot’s auth_failure_delay / auth_penalty) on repeated failures so brute-force and spraying stall.
• Patch the daemon. Run Dovecot 2.3.7.2 or later (CVE-2019-11500) and keep Cyrus current; never expose an unmaintained IMAP server.
• Watch for persistence, not just logins. Alert on new mail forwarding or delegation rules and on geographic anomalies in successful IMAP logins — a mailbox compromise usually reveals itself that way within hours.
• Firewall port 143 to the networks that genuinely need it, or close it and standardise on 993.

Real-World Example

In 2019 Proofpoint published a six-month study of IMAP-based password-spraying against major cloud tenants. Roughly 60% of Microsoft Office 365 and G Suite tenants were targeted, and about a quarter suffered at least one successful breach, with attackers hitting a 44% success rate. The reason IMAP was the weapon of choice is the plaintext-protocol legacy this page is about: legacy IMAP auth doesn’t support modern authentication, so a third-party client speaking IMAP could brute-force credentials without ever triggering the multi-factor prompt, and the slow, distributed guessing looked like ordinary isolated login failures. Once in, attackers set forwarding and delegation rules to keep reading the mailbox. The industry fix was the same migration an exposed port 143 should be flagged for: turn off legacy/basic IMAP auth, force modern auth with MFA, and use implicit TLS on 993 rather than trusting an opportunistic upgrade on 143.

FAQ

What is port 143 used for?

Port 143 is the default IMAP port. A mail client connects to it to authenticate and then read, search, and manage messages that stay stored on the server in folders — unlike POP3 on port 110, which downloads and deletes. On plain port 143 that traffic is unencrypted unless the client upgrades the session with STARTTLS, which is why modern setups use IMAPS on port 993 instead.

Is port 143 secure?

Not on its own. Standard IMAP on 143 starts in cleartext, so the login and mail are sniffable unless STARTTLS is both offered and enforced — and because the upgrade is opportunistic, an active attacker can strip it. Most servers also don’t throttle logins, which makes brute-force and password spraying practical. Treat an internet-facing port 143 as something to encrypt, restrict, or replace with 993.

What’s the difference between port 143 and port 993?

Both carry IMAP. Port 143 is the plaintext version — encryption is optional, via the STARTTLS upgrade, and often not enforced. Port 993 is IMAPS: the identical protocol wrapped in TLS from the first byte, with no unencrypted phase for an attacker to strip or inject into. For anything sensitive, 993 is the safe default.

How do I secure or close port 143?

Move mail clients to IMAPS on 993, and if port 143 has to stay open, require STARTTLS before authentication (disable_plaintext_auth = yes in Dovecot), disable legacy basic auth in favour of OAuth2 with MFA, rate-limit failed logins, patch the daemon, and firewall the port to trusted networks. If nothing needs plaintext IMAP, stop the service and rescan with nmap -p 143 <target> to confirm it’s closed.

TL;DR

• Service: IMAP (Internet Message Access Protocol), server-side mailbox access
• Default port: 143/TCP (encrypted IMAPS on 993/TCP)
• Biggest risk: cleartext credentials and mail, plus MFA-bypassing brute-force and password spraying
• Mitigation: move to IMAPS on 993, enforce STARTTLS, kill legacy basic auth, require MFA, throttle logins, patch the daemon