Why did the PHPMailer library vulnerability have to be patched twice?

The open source PHPMailer library was found to have a serious remote code execution flaw. The vulnerability was patched, and then repatched, as the first attempt did not sufficiently mitigate the problem. How does this vulnerability work? Why didn't the original patch fix the issue?

Code libraries and frameworks greatly reduce the time it takes to build new applications. They save development teams from having to build common components from scratch for each new project.

Most web services are built using popular third-party frameworks and libraries. The big problem with this reuse of code is that, if a vulnerability is found in a popular library, it affects hundreds of thousands of applications, sites and services.

This situation occurs quite frequently, and arose again recently when Dawid Golunski discovered a remote code execution flaw in the open source transport class PHPMailer. Exploiting this vulnerability would give an attacker access to the targeted server in the context of the web server account; this could lead to a full compromise of the web application.

PHPMailer is used by many open source projects, such as WordPress, Drupal and Joomla, with an estimated nine million users worldwide. There are thousands of code snippets and examples on the internet showing how to send an email using PHPMailer from various forms, such as a contact or registration form, but most contain an insecure line of code that makes this vulnerability exploitable, as it allows anyone to forge the From and the Sender addresses.

PHPMailer uses the PHP mail function as its default method for sending an email. Although all email addresses used by PHPMailer are validated before being used, Golunski found a way of crafting a valid From email address that also contained an executable command. Although the From email address should be set by the developer, it is often set using data supplied by the user, which is extremely bad practice, as a user can submit any email address they choose. Also, if the Sender property is not set explicitly by the developer, the From address is used. This Sender value is added to the fifth parameter passed to the PHP mail function, which doesn't correctly filter any string literal escape characters it may contain. This allows an attacker to inject additional parameters containing commands that are executed when the mail is sent.

This vulnerability was tracked as CVE-2016-10033, and PHPMailer developers thought they had fixed the flaw when they released PHPMailer version 5.2.18. They added the escapeshellarg escaping function to sanitize the Sender address value before it is passed to the PHP mail function.

However, Golunski noticed that, when the escapeshellarg function was used in combination with the existing escaping function, escapeshellcmd, the Sender value was still not properly escaped. By adding an extra quote to the original attack code, it was still possible to escape out of the protection thought to be afforded by the patch. This new vulnerability was reported as CVE-2016-10045, and a patch was released in PHPMailer 5.2.20.

The PHPMailer team has posted on GitHub examples of how to correctly handle email addresses used in website forms. It requires emailing form data to and from valid addresses within a site's domain, explicitly set by the developer.

This is considered a highly critical flaw, and shows how important it is for developers and web administrators to stay up to date with the latest security threats and to subscribe to vendor alerts for any shared components, packages or libraries they use within their code.

Developers should certainly review any scripts that use the PHPMailer mail function, and also study how PHP's various escaping functions work, and the effect they have on different types of strings, as incorrectly escaped strings can also lead to SQL injection vulnerabilities.