Page MenuHomePhorge

Monitor PHPMailer security
Open, NormalPublic


See prior work at

Basically, there are a bunch of security alerts that come up with PHPMailer, which we include as code.

In T12046, epriestley analysed the 2016 exploits and concluded that we're not vulnerable, but that the situation gets any worse we should just dump PHPMailer and write our own.

This is the public Security disclosure document of PHPMailer, and we should be tracking it to see if it got worse:

As of now, it lists the following items since 2016 (I checked those that I already cleared):

  • CVE-2017-5223 (unfiltered user input)
  • CVE-2017-11503
  • CVE-2018-19296 and CVE-2020-36326 (UNC paths)
  • CVE-2020-13625 (Attachments)
  • CVE-2021-34551 (UNC paths)
  • CVE-2021-3603

Related Objects

Mentioned In

Event Timeline

avivey triaged this task as Normal priority.Mar 15 2024, 18:44
avivey created this task.

First pass, these one do not apply to us (and some of them do not apply to anyone at all):


This one requires the attacker to be able to inject code into the server code-base, before they can use PHPMailer to activate that code.

I've changed my mind about "high count of CVEs", they give these out like candy.


"No specific vulnerability has been found relating to this... could allow file attachments to bypass attachment filters..."

We don't do attachments (Maybe there's an option in Differential?) and we definitely not allow user-provided input for these things.

One of the example files provided in the docs is skipping some validations. We lucked out here by not including the documentation.

This one requires passing user-provided input as a filename to the "setLanguage" method; We don't call that method.

CVE-2017-5223, CVE-2018-19296 and CVE-2020-36326:

When passing un-filtered user input to various methods, PHPMailer might execute it or load more files.
We don't pass any such input (Unless there's a way to do that via importing ICS?)