SMTP smuggling is a novel vulnerability that allows e-mail spoofing by exploiting interpretation differences of the SMTP protocol in vulnerable server constellations. More specifically, different understandings of so called "end-of-data" sequences between outbound (sending) and inbound (receiving) SMTP servers may allow an attacker to smuggle - hence SMTP smuggling - spoofed e-mails (see Figure 1). Threat actors can abuse this to send malicious e-mails from arbitrary e-mail addresses, allowing targeted phishing attacks.
Affected software identified on the outbound side includes Exchange Online and GMX, which are hosting millions of domains. On the inbound side, over a million SMTP instances including Postfix, Sendmail, Cisco and others are affected. This allowed spoofing e-mails from millions of domains (e.g., microsoft.com, github.com, gmx.net) to millions of SMTP servers.
As a result of miscommunications in the vulnerability disclosure, millions of inbound SMTP servers are left vulnerable to SMTP smuggling. Further cases of SMTP smuggling vulnerabilities in outbound servers would again allow spoofing e-mails from affected domains.
Also due to a severe case of SMTP smuggling in Cisco Secure Email and missing vendor support, it is highly advised to change the vulnerable default configuration (see affected software).
Figure 1: SMTP smuggling overview
Official vendor statements can be found in CERT/CC's vulnerability note. However, keep in mind that there are "different views" on the vulnerability (e.g., Cisco).
|Cisco Secure Email (Cloud) Gateway
|On-premise and cloud versions of Cisco Secure Email Gateway using the default configuration are vulnerable to severe inbound SMTP smuggling, since end-of-data sequences like "<CR>.</CR>" are accepted. This allows spoofing e-mails from millions of domains. More information can be found in the original blog post.
|The option "CR and LF Handling" must be reconfigured to "Reject" or "Allow" (deprecated). However, due to known drawbacks, we are currently evaluating other workarounds. This issue will most likely not be addressed by Cisco in the near future.
|Postfix was identified to accept non RFC-compliant end-of-data sequences like "<LF>.<CR><LF>". This is not as severe of an issue like with Cisco Secure Email, however this still allows SMTP smuggling, if outbound servers (as identified with Exchange Online and GMX) do not filter such "<LF>.<CR><LF>" sequences. More information can be found in the original blog post.
|Detailed information can be found on the Postfix website.
Thanks to Wietse and Viktor for providing quick solutions!
|Sendmail and Postfix handle end-of-data sequences the same way. As with Postfix, pipelined SMTP commands by default get executed after a "fake" end-of-data sequence is processed.
|For now, Sendmail snapshot 188.8.131.52 can be used. More information can be found here.
|Some configurations of Exim are vulnerable to SMTP smuggling similar to Postfix and Sendmail.
|Upgrading to Exim version 4.97.1 or later should fix this issue. More information can be found on the Exim website
|SurgeMail is vulnerable to SMTP smuggling similar to Postfix and Sendmail.
|More information on fixing SurgeMail can be found on the SurgeMail website.
|Outbound Exchange Online servers allowed to send "<LF>.<CR><LF>" sequences to inbound/receiving servers due to insufficient filtering of message data. This behavior is a violation of RFC 5322 and, as of now, was only identified for Exchange Online and GMX (see below). This vulnerability allowed smuggling spoofed e-mails from millions of domains hosted at Exchange Online (e.g., microsoft.com, github.com, tesla.com, etc.) to millions of e-mail servers running Postfix, Sendmail, Exim and possibly more.
|Microsoft has already fixed this issue.
|As Exchange Online, GMX also allowed to send "<LF>.<CR><LF>" sequences to millions of inbound/receiving servers due to insufficient filtering of message data.
|GMX promptly fixed this issue.
|Please help us to identify more vulnerable SMTP software by using the provided tools. If you're vulnerable and using software that is not already in this list, please create an issue on GitHub.
Here is a list of software that was confirmed to be unaffected by SMTP smuggling.
However, keep in mind that constellations with multiple SMTP servers could again introduce SMTP smuggling issues.
|Vanilla qmail was confirmed to be unaffected by SMTP smuggling.
|Original blog post
|CERT/CC Vulnerability Note VU#302671
|SMTP smuggling and Exchange (DE)
|Talk at 37C3
The scanner is currently under review! In the meantime, check out the other available tools.
Want to make changes to this website? Great, contributions are highly appreciated! Please create issues and pull requests on GitHub.
New information, updates, tools and more coming soon!
company name SEC Consult Unternehmensberatung GmbH
business purpose IT-Dienstleistungen / Unternehmensberatung
VAT number ATU56165223
tax number 330 214 628
registration number FN 227896t
commerical court Handelsgericht Wien
address Wagramer Straße 19 / Stock 16 | 1220 Wien
phone +4318903043 0
membership of chamber of commerce Wirtschaftskammer Wien Fachgruppe: Unternehmensberatung und Informationstechnologie
applicable law Gewerbeordnung
management Wolfgang Baumgartner
data protection officer dpo-austria(at)atos.net