POP3's long history as a tiny C daemon parsing untrusted input before authentication makes the server implementation itself an attack surface, especially on the legacy hosts where POP3 still lives. The canonical target is qpopper, whose overflow lineage defined the class; Courier (and its courier-authlib) is the next most common, and current Dovecot's POP3 service shares the auxiliary-service and SASL surface described for its IMAP side. Pre-auth triggers (in the greeting, USER/APOP, or AUTH handling) are the prizes. Fingerprint the exact build first, because every one of these is version-gated.
Fingerprint the build#
nc <target> 110
+OK qpopper (version 4.0.5) at mail.corp.local starting.
nmap -p110,995 -sV <target> # resolves product/version
qpopper and Courier print their product and often their version in the greeting; Dovecot is terse, so rely on -sV and side services. An APOP token and an explicit version string in the greeting are both strong signals of an older, likely vulnerable, server.
qpopper#
qpopper (the Berkeley/Qualcomm POP3 daemon) is where the POP3 overflow lineage is clearest. Older releases contained stack buffer overflows reachable through over-long arguments to USER, PASS, and other commands, and format-string issues in logging of attacker-controlled input. The notable ones were post-auth (triggered after a valid login, which still matters for escalating from a low-value mailbox account to the daemon's privileges), while the command-parsing overflows in the dispatch loop could be reached with minimal or no authentication on the most affected builds. Because qpopper historically ran with elevated privileges to access maildrops, a successful overflow was a direct route to higher privilege on the host.
# fingerprint, then confirm which commands the version accepts pre-auth
nc <target> 110
+OK qpopper (version 4.0.5) ...
USER $(python3 -c 'print("A"*2000)') # legacy builds mishandle over-long args
Treat the over-long-argument probe as a version-gated test: on a vulnerable build it crashes or misbehaves, on a current one it is rejected cleanly with -ERR.
Courier#
Courier-POP3's exposure is mostly in authentication and the shared courier-authlib, where input-handling flaws produced crashes and, in older builds, memory corruption during the credential handling. As with Courier-IMAP, a Courier banner marks an aging host that is usually behind on its other services too, so it is worth treating the POP3 finding as a pivot indicator as much as a target in itself.
Dovecot POP3#
Dovecot serves POP3 from the same codebase as its IMAP service, so the auxiliary-service and SASL surface is shared: the parsing flaws in the stats service and TLS/SNI handling, and the submission proxy, all apply regardless of which retrieval protocol the client speaks. Dovecot's core POP3 command handling has been hardened, so on a current build the value is the same auxiliary-service DoS and, once you hold a credential, the Sieve/ManageSieve execution path (which acts on delivered mail independent of how it is later retrieved). See IMAP server exploitation for the Dovecot detail.
Lineage#
The arc mirrors IMAP's. 1990s/2000s POP3 daemons (qpopper above all, plus the various ipop3d/UW implementations) carried the classic pre- and post-auth buffer overflows and format strings of C network services parsing untrusted commands while running privileged. Courier sat in the middle, with its exposure concentrated in the auth layer. Modern Dovecot closed the core-protocol memory-corruption class, pushing the remaining surface out to auxiliary services and to post-auth mail scripting. So when you fingerprint an old qpopper or Courier, think pre/post-auth memory corruption and privilege gain; when you see current Dovecot, think auxiliary-service DoS and post-auth Sieve execution.