WP ERP 1.17.8 stops an emailed attachment becoming PHP in uploads

What the release fixes

WP ERP bundles an IMAP connector for its CRM module. With the feature switched on, a scheduled job logs into a configured mailbox, reads what is waiting there, and saves any attachments to disk so they show up against the contact who sent them.

Up to and including 1.17.7, the function that wrote those attachments trusted the filename the email carried. It did not check the extension, and it did not normalise the path before writing. Between 1.17.7 and 1.17.8 that function gained a filename sanitiser and a check that the resolved path still sits inside the attachment directory. The change is visible in the plugin’s own trac changeset, linked below.

One point worth stating plainly, because the published advisory gets it wrong: the advisory lists 1.17.8 as affected. It is not. The fix is in 1.17.8, and 1.17.9 does not touch the function again.

How the bug works

The mailbox is the untrusted input, and email is the one input a site cannot put behind a login.

The connector matches incoming mail against a pattern in the References header to decide which conversation a message belongs to. An attacker who knows the pattern can forge a header that satisfies it, which is enough to get their message picked up and processed rather than ignored.

The attachment then carries the payload, and the payload is the filename. A name like ../helper.php does two things at once. The extension is one the web server may execute, and the leading traversal walks out of the folder the plugin meant to write into. That folder ships with an .htaccess that stops Apache serving what is inside it. One directory up, in wp-content/uploads itself, that protection does not apply.

So the file lands as PHP inside uploads. On any server configured to run PHP in that directory, requesting the file executes it, and the attacker has code execution as the web server user without ever authenticating to WordPress.

Segurium Research reports what the released code changed. We read the public source of both releases and did not touch a live site running either. No working exploit appears here.

Who is exposed

Sites running WP ERP below 1.17.8 with both the CRM module and the IMAP Email Connect feature enabled and pointed at a mailbox. The plugin reports around 5,000 active installs on wordpress.org, and the feature is off by default, so the exposed population is a fraction of that.

Two conditions decide whether the bug reaches code execution rather than stopping at a stray file. The connector has to be running against a mailbox an outsider can send mail to, which in practice is most of them. And the server has to execute PHP inside wp-content/uploads. Plenty of hosts block that, and plenty do not.

A site that meets the first condition but not the second still ends up with an attacker-controlled file written outside the directory the plugin intended. Treat that as a compromise waiting for a configuration change.

What to do

Update to 1.17.8 or later. If the CRM module or the IMAP connector is not something the site actually uses, turn the feature off as well. An unused integration that reads untrusted mail is worth removing even after the patch.

Then look for what may already have landed. Search wp-content/uploads for files ending in .php. A normal uploads directory has none, so anything found there deserves an explanation before it is deleted. Check the modification dates against when the connector was last active.

Confirm whether your server executes PHP under uploads. Ask your host, or test it with a file that only prints a harmless string and remove it afterwards. If the answer is yes, that is worth fixing on its own merits: it converts a whole category of file-write bugs into remote code execution, and this is not the last plugin that will ship one.

A dropped PHP file in wp-content/uploads is one of the clearest signatures a WordPress malware scanner has to work with, so a scan is a reasonable second opinion after the manual look.