Defend Against PHPMailer Vulnerability with 0day Protection


On December 25th 2016, a critical new vulnerability in PHPMailer was made public. The open source PHP library for email handling embeds email functionality in web applications. This recent vulnerability takes advantage of insufficient validation of email addresses that allows remote (malicious) code injection, to create a backdoor for attackers to take control of a server, access private information, and conduct other criminal activities.

In this post we analyze the vulnerability and its timeline, discuss common strategies used by hackers to further exploit vulnerabilities once they become public, and review mitigation options for the attack. If you use or are considering using PHPMailer in any of your web applications, you’ll want to understand this vulnerability and how to protect against it.

PHPMailer Vulnerability Details

The vulnerability is exploited by submitting a crafted email address to an application that uses the PHPMailer library. Detection is difficult as there is no single way for applications to use PHPMailer and therefore no “universal” attack vector. The crafted email address contains quote characters that are not properly escaped, and as a consequence, allows an attacker to inject additional command line arguments to the mail executable. Utilizing these arguments, the attacker can write a new publicly available file in the application directory and access it.

After the exploit was initially released the code was fixed and the email address field sanitized using the escapeshellarg() PHP function. Unfortunately, the fix was incomplete and on December 27th, only two days after the initial vulnerability release, a patch bypass was published. The bypass relies on a clash of the escaping performed by escapeshellarg() and the escaping performed by the PHP mail(). Thus, a specially-crafted email address can “trick” both functions.

The scenario of publishing follow-up patches due to an incomplete fix is not uncommon and trying to play catch up with them can be a pricey and lengthy process (Shellshock, for example).

After these vulnerabilities were published, other PHP email handler libraries were tested for the same vulnerability. On December 29th it was discovered that another major library, SwiftMailer, was vulnerable to code injection in exactly the same manner as PHPMailer (CVE-2016-10074). So, when passing a crafted request to applications using this library, it validates the email according to RFC 3696 and carries the code injection until it’s executed by the mail() PHP function.

Attacks in the Wild

Monitoring the traffic following the disclosure of the vulnerabilities yielded relevant attack traffic in the wild, starting a few hours from the time of publication. As expected, at least during the first 24 hours, we found that most of the payloads carried by these attacks were an exact clone of the POC code published by the author (see Vulnerability section), and originated from very few resources (Figure 1).


Figure 1 – Attack in the wild – Similar payload as POC

This is a common strategy used by attackers who wish to exploit a new vulnerability. Before or right after a security patch is published, they scan numerous web applications for the new vulnerability to find a new attack vector.

0day Vulnerability Mitigation

The Imperva application security team regularly investigates vulnerabilities that may affect web applications that potentially expose our customers to attacks. In response we create new virtual patches when needed.

The three CVE’s as part of this PHPMailer vulnerability—CVE-2016-10033, CVE-2016-10045, and CVE-2016-10074—made their way to known vulnerabilities repositories on December 26th, 28th, and 29th respectively. Then, a few hours later, the CVE’s popped up on our high-priority CVE radar.

Following the reconstruction of the attack (Figure 2) we discovered that it’s protected out-of-the-box based on one of our 0day detection mechanisms that include PHP key words that are essential to run malicious code. Specifically, the core mechanism that detected this attack seeks for PHP code injection to an HTTP web application, and if such traffic is detected, immediately blocks it.


Figure 2 – HTTP Malicious Payload + Blocked Response

Overall, less than four hours since they arrived to the Imperva research lab operating table, both vulnerabilities were analyzed, classified, and reported back to customers as protected out-of-the-box based on our 0day protection mechanism.

Protect Against Cyber-Attacks

Cyber-criminals attack around the clock, steal data, disrupt access, and compromise website credentials to commit further fraud.

Web application security solutions enable you to prevent breaches and downtime by protecting your data where it’s accessed – your web applications. An effective web application firewall (WAF) can dynamically learn your applications’ “normal” behavior, correlate that with crowd-sourced threat intelligence, and then update in real time to deliver 0day protection against vulnerabilities.

Learn more about Imperva SecureSphere Web Application Firewall and ThreatRadar web application threat intelligence.