PHPMailer RCE [CVE-2016-10033 and CVE-2016-10045]
Open, LowPublic

epriestley lowered the priority of this task from High to Low.Dec 26 2016, 4:51 PM

This appears to be the fix:

So I think there a couple of attacks here, which probably look something like this:

  • Somehow configuring the sendmail binary to be curl | sh.
  • Somehow configuring the Sender to be `curl | sh` or similar.

I believe we are vulnerable to neither:

  • We do not allow user or administrator configuration of the sendmail binary.
  • We never configure a Sender.
  • Empirically, our mail arrives without a "Sender" (see also T1837).
  • We disable the implicit assignment of the Sender by passing the appropriate flag:
public function setFrom($email, $name = '') {
  $this->mailer->SetFrom($email, $name, $crazy_side_effects = false);
  return $this;

I'll keep an eye on this, but I think no immediate action is necessary because we don't expose any way to get at these vulnerabilities.

Rather than patching PHPMailer, I'd prefer to remove it completely by replacing it with first-party code: the code is sketchy from both a quality and security point of view, and RCE in a ~2,000 line mail adapter is absurd. See also D2147.

So my tentative plan is:

  • leave it as-is for now;
  • monitor further disclosures about this vulnerability, in case I am misunderstanding the attack;
  • replace PHPMailer with a first-party replacement when we have an opportunity.

updated advisory;
I don't think this changes the plan you suggest, just linking for completeness.

eadler renamed this task from PHPMailer RCE [CVE-2016-10033] to PHPMailer RCE [CVE-2016-10033 and CVE-2016-10045].Dec 28 2016, 7:24 AM

From a cursory read of CVE-2016-10045, it seems like PHP may be written in such a way that mail() can not be invoked safely. Silly PHP!

libcurl supports SMTP (see and can be used instead, provided that the relevant functions are exposed to PHP. This avoids needing to shell out to an external executable.

aubort added a subscriber: aubort.Jan 5 2017, 8:42 AM