Blog Detail

CVE-2026-18080: Critical RCE in WordPress ERP Plugin — Public PoC, No KEV Listing Yet

An unauthenticated file-upload flaw in the ERP: Complete HR, Accounting & CRM Suite plugin for WordPress (≤ 1.17.8) lets attackers drop PHP into wp-content/uploads via a crafted IMAP email. A public PoC is circulating, but CVE-2026-18080 is not on CISA KEV as of this writing. Here's how to validate exposure and shut it down.

Trusteed Team

Trusteed Editorial

Written On

Sep 18, 2026

TL;DR

CVE-2026-18080 is a critical (CVSS 3.1 base 9.8) unrestricted file type upload in the ERP: Complete HR, Accounting & CRM Suite Built for WooCommerce plugin for WordPress, affecting all versions up to and including 1.17.8. The flaw lives in the plugin's save_attachments() function, which processes inbound IMAP email attachments for the CRM Email Connect feature. Because the plugin neither validates file extensions nor normalizes attachment filenames, an unauthenticated attacker can send a crafted email to the site's configured inbound mailbox and cause a PHP file to be written into wp-content/uploads/ — outside the .htaccess-protected crm-attachments directory. On hosts where PHP executes in the uploads directory, that is remote code execution.

Two facts should drive your response:

A public proof-of-concept is circulating (GitHub reference in the Watchstack feed). Weaponization is no longer theoretical.
CVE-2026-18080 is not listed in CISA's Known Exploited Vulnerabilities (KEV) catalog as of this writing. Some source feeds have surfaced KEV-style metadata for this CVE; the public KEV catalog does not currently carry it. Treat the absence of a KEV listing as a prioritization signal, not a reason to deprioritize. A CVSS 9.8 unauthenticated RCE with a public PoC belongs at the top of your emergent queue regardless of KEV status.

If you run this plugin with the CRM module and IMAP Email Connect enabled, assume you are exposed until you prove otherwise. Patch to a version newer than 1.17.8, or disable the feature set immediately.

What is CVE-2026-18080?

CVE-2026-18080 is an unrestricted file upload vulnerability (CWE-434) compounded by a path traversal weakness (CWE-22) in the WordPress plugin ERP: Complete HR, Accounting & CRM Suite Built for WooCommerce, developed by weDevs. The vulnerable code path is save_attachments(), reached through the plugin's CRM Email Connect feature, which polls a configured inbound IMAP mailbox on a WordPress cron schedule.

The plugin trusts attachment filenames verbatim. It does not enforce an extension allow-list, and it does not canonicalize or normalize the filename before writing the file to disk. An attacker who can deliver an email to the monitored mailbox — with a forged References header matching the pattern the plugin expects for CRM threading — can attach a file named something like ../helper.php. When the cron-driven IMAP sync processes that message, the traversal sequence escapes the intended crm-attachments directory and lands the file in wp-content/uploads/.

The crm-attachments folder is normally protected by an .htaccess rule that blocks PHP execution. wp-content/uploads/ frequently is not. Where PHP executes there, the attacker's file runs with the privileges of the web server process.

Key attributes:

CVE: CVE-2026-18080
Severity: Critical — CVSS 3.1 base 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
Weakness: CWE-434 (Unrestricted Upload of File with Dangerous Type), CWE-22 (Path Traversal)
Affected versions: All versions ≤ 1.17.8
Authentication required: None (unauthenticated)
Attack vector: Network — crafted email to the site's inbound IMAP mailbox
Public PoC: Yes (GitHub reference circulating)
CISA KEV: Not listed as of this writing
EPSS: ~0.00672 (≈ 50th percentile) — low mass-scan signal, but PoC availability changes the calculus

Why this matters right now

Three things make this CVE an emergent-threat priority rather than a routine plugin patch.

First, it is unauthenticated. Most WordPress file-upload bugs require at least a subscriber-level account or an authenticated AJAX nonce. This one requires only the ability to send an email to a mailbox the site already polls. That collapses the attacker's prerequisite set to two unknowns: the mailbox address and the References header pattern.

Second, a public PoC exists. The Watchstack feed flags a GitHub repository (Polosss/By-Poloss..-..CVE-2026-18080) as a public exploit reference. Public PoCs compress the time between disclosure and opportunistic exploitation. Even when a PoC is partial or environment-specific, it gives low-skill actors a starting point and gives everyone else a reason to assume attempts are underway.

Third, the impact is full site compromise. Arbitrary PHP write into the webroot, followed by execution, means web shells, credential theft from wp-config.php, database access, persistence in themes and plugins, and lateral movement into connected WooCommerce payment flows and CRM data. This plugin handles HR records, accounting data, and customer PII — a compromise is a data-breach event, not just a defacement.

CISA KEV status: not listed (as of this writing)

This is the section defenders keep asking about, so let's be precise.

CVE-2026-18080 does not appear in the CISA Known Exploited Vulnerabilities catalog as of this writing. Some aggregated feeds and enrichment pipelines have surfaced KEV-style metadata for this CVE (including an "added 2026-08-26" style date). The authoritative public KEV catalog does not currently carry this entry. If that changes, the remediation clock for federal agencies — and the prioritization signal for everyone else — changes with it.

What does KEV absence mean for you?

It means CISA has not confirmed in-the-wild exploitation at catalog level.
It does not mean the vulnerability is unexploited. KEV lags real-world activity; public PoCs frequently precede KEV additions.
It does not lower the CVSS 9.8 severity or the unauthenticated RCE impact.
It does not change your exposure if you run the affected plugin with CRM Email Connect enabled.

Treat KEV as one input among several. A public PoC plus unauthenticated RCE plus a plugin that touches HR, accounting, and CRM data is enough to justify emergency-change remediation on its own.

Technical deep dive

The vulnerable code path

The plugin's CRM Email Connect feature is designed to pull customer emails into the CRM. It connects to an inbound IMAP mailbox on a cron schedule, iterates over messages, matches them against an expected References header pattern (used for email threading), and persists attachments via save_attachments().

Two controls are missing in that pipeline:

No file extension validation. The plugin does not enforce an allow-list of safe extensions (e.g., .pdf, .png, .docx). Any filename is accepted.
No path normalization. The filename is used as-is when constructing the destination path. Traversal sequences (../) are not stripped or canonicalized.

How the write escapes the protected directory

Attachments are intended to land in the plugin's crm-attachments directory, which is protected by an .htaccess rule that blocks PHP execution. Because the filename is trusted verbatim, an attachment named ../helper.php resolves to a path outside that directory — typically wp-content/uploads/helper.php. The .htaccess protection on crm-attachments is bypassed entirely because the file never lands there.

Why RCE depends on host configuration

Writing a .php file into wp-content/uploads/ is only exploitable if the web server executes PHP in that directory. Many hardened WordPress hosts disable PHP execution in uploads via .htaccess (php_flag engine off), Nginx location blocks, or equivalent. Others do not. This is the difference between an arbitrary file write and full remote code execution — and it is the single most important configuration fact to verify on your own estate.

Prerequisites for exploitation

The plugin is installed and the version is ≤ 1.17.8.
The CRM module is active.
The IMAP Email Connect feature is enabled and configured with a reachable mailbox.
The attacker can deliver mail to that mailbox.
PHP execution is permitted in wp-content/uploads/ (for the RCE outcome).

If any of the first four are false, the attack path is closed. If the fifth is false, the impact is limited to arbitrary file write — still serious, but not code execution.

Exposure validation: how to check if you're affected

Work through this checklist in order. Each step narrows the population of at-risk hosts.

1. Inventory the plugin.

Check wp-content/plugins/ for the ERP plugin directory (commonly erp).
Confirm the installed version. Anything ≤ 1.17.8 is in scope.
If you manage many sites, query your asset inventory or run a plugin-version scan across the fleet. Do not rely on a single site check.

2. Confirm the CRM module is active.

In the WordPress admin, review the plugin's module settings. The CRM module must be enabled for the Email Connect path to be reachable.

3. Confirm IMAP Email Connect is configured.

Look for an inbound mailbox configuration in the CRM settings.
If no mailbox is configured, the cron job has nothing to poll and the attack path is closed. If one is configured, note the address — you will need it for log review.

4. Check whether PHP executes in uploads.

On Apache, look for .htaccess rules in wp-content/uploads/ that disable the PHP engine.
On Nginx, review the server block for a location directive that denies or blocks *.php under uploads.
If neither exists, assume PHP execution is possible and treat the RCE outcome as live.

5. Review for prior exploitation.

Search wp-content/uploads/ for unexpected .php files, especially at the top level and outside known plugin subdirectories.
Review web server access logs for requests to wp-content/uploads/*.php from external IPs.
Review mail server logs for messages to the CRM mailbox with forged References headers or attachments containing ../ in the filename.
Check for unexpected admin users, modified theme functions.php, and suspicious wp_options entries.

If steps 1–4 all indicate exposure and step 5 turns up anything anomalous, move to incident response rather than in-place cleanup.

Indicators of compromise

File system

Newly created .php files in wp-content/uploads/, particularly at the directory root or in unexpected subdirectories.
Filenames resembling helper.php, index.php, or random strings, with modification timestamps correlating to WordPress cron intervals.
Modified theme files (functions.php) or plugin files outside of legitimate update windows.

Logs

Web server access logs showing GET or POST requests to wp-content/uploads/*.php from external IPs.
IMAP sync cron log entries referencing attachment filenames containing ../ sequences.
PHP error logs showing file writes outside expected directories.
Mail server logs showing messages with malformed or forged References headers and traversal-style attachment names.

Network

Outbound connections from the web server process to unexpected external IPs or domains following cron execution.
Unusual DNS lookups or reverse-shell-style traffic originating from the web host.

Process

Unexpected child processes spawned by PHP-FPM or the web server worker (e.g., bash, curl, wget, python3) following WordPress cron activity.

WordPress-specific

Unexpected admin users or role changes.
New wp_options entries referencing external domains.
Cron events firing the plugin's IMAP sync more frequently than configured, or at odd hours.

Patch and mitigation paths

Primary remediation: update the plugin

Update ERP: Complete HR, Accounting & CRM Suite Built for WooCommerce to a version newer than 1.17.8. The fix is available through the WordPress plugin repository changeset. Validate the update in staging before rolling to production, and confirm the plugin version post-update.

If you cannot patch immediately

Apply compensating controls in this order:

Disable CRM Email Connect. This closes the attack path entirely. If the CRM module is not business-critical, deactivate the plugin until you can patch.
Disable PHP execution in wp-content/uploads/. On Apache, add php_flag engine off (or equivalent) to the uploads .htaccess. On Nginx, add a location block that returns 403 for *.php under uploads. This eliminates the RCE outcome even if a file write occurs.
Restrict the inbound mailbox. Limit accepted senders to trusted addresses and monitor for anomalous attachments.
Add a WAF rule. Block external requests to wp-content/uploads/*.php.
Harden file permissions. Ensure the web user cannot write outside designated directories.

Post-exploitation hygiene

If you suspect or confirm exploitation, rotate:

WordPress salts and keys
All admin credentials
Database passwords
API keys stored in plugin configuration

Then rebuild from a known-good state rather than attempting surgical cleanup. Cron-driven writes can re-drop payloads after naive deletion.

Detection and hunting guidance

Hunting for this CVE is mostly about correlating three data sources: mail logs, web server logs, and file integrity monitoring on the uploads directory.

Mail side: Look for inbound messages to the CRM mailbox with References headers that do not match legitimate CRM threading, and attachments whose filenames contain ../ or unusual extensions. Even if your plugin version is patched, this pattern is worth alerting on.
Web side: Alert on any external request to wp-content/uploads/*.php. Legitimate WordPress operations rarely serve PHP from uploads.
File side: Alert on writes to wp-content/uploads/ by the PHP-FPM or web server user, especially writes originating from a mail-parsing code path.
Process side: Alert on shell or network-utility child processes spawned by the web server user.

If you have EDR coverage on the WordPress host, tune for the process and file-write signals. If you do not, this CVE is a good argument for adding file integrity monitoring to your WordPress estate.

CTEM perspective: where this fits in your program

Continuous threat exposure management (CTEM) treats this CVE as a scoping, validation, and mobilization problem rather than a one-off patch ticket.

Scoping. How many sites in your estate run this plugin? How many have the CRM module and IMAP Email Connect enabled? How many allow PHP execution in uploads? Those three questions define your true exposure surface — and the third is the one most teams have never measured.

Validation. A public PoC means you can validate exposure safely in a controlled environment. Confirm whether the attack path is reachable on a representative host before you assume your configuration blocks it.

Mobilization. Patch where you can. Where you cannot, disable the feature. Where you cannot do either, enforce PHP-off in uploads and add WAF coverage. Track the KEV catalog for a status change and re-prioritize if it appears.

Communication. Because this plugin touches HR, accounting, and CRM data, loop in legal, privacy, and compliance stakeholders early if you find evidence of exploitation. Regulatory notification clocks may apply.

Timeline and context

Disclosure: August 26, 2026 (per public advisory metadata).
CVSS assignment: Wordfence, CVSS 3.1 base 9.8.
Public PoC: GitHub reference circulating (Watchstack feed).
CISA KEV: Not listed as of this writing. Some feeds have surfaced KEV-style metadata; the public catalog does not currently carry the entry.
EPSS: ~0.00672 (≈ 50th percentile). Low mass-scan signal, but PoC availability and unauthenticated RCE impact dominate prioritization.

Community coverage has centered on the KEV-style framing and the CVSS 9.8 rating, with security media highlighting the IMAP-driven, unauthenticated nature of the attack as unusual for a WordPress upload bug. The recurring theme in practitioner discussion is that PHP execution in wp-content/uploads/ is a host-configuration problem that turns medium-severity upload bugs into critical RCE — and that this plugin's data sensitivity raises the stakes.

FAQ

Is CVE-2026-18080 on CISA KEV? Not as of this writing. Some aggregated feeds have surfaced KEV-style metadata, but the authoritative public KEV catalog does not currently list this CVE. Monitor the catalog for changes.

Does a public PoC exist? Yes. The Watchstack feed references a public GitHub PoC (Polosss/By-Poloss..-..CVE-2026-18080). Treat public PoC availability as a signal that opportunistic exploitation is plausible.

What versions are affected? All versions of the ERP: Complete HR, Accounting & CRM Suite Built for WooCommerce plugin up to and including 1.17.8.

Is authentication required to exploit this? No. The attack is unauthenticated. The attacker only needs to deliver a crafted email to the site's configured inbound IMAP mailbox.

What are the prerequisites? The CRM module must be active, IMAP Email Connect must be enabled and configured with a reachable mailbox, and — for the RCE outcome — PHP must execute in wp-content/uploads/.

What is the CVSS score? 9.8 (Critical), vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.

What is the fastest mitigation if I can't patch right now? Disable the CRM Email Connect feature. If that is not possible, disable PHP execution in wp-content/uploads/ and add a WAF rule blocking external requests to wp-content/uploads/*.php.

How do I know if I've been exploited? Look for unexpected .php files in wp-content/uploads/, external requests to those files in web server logs, forged References headers or traversal-style attachment names in mail logs, and unexpected child processes spawned by the web server user.

What should I do if I find evidence of exploitation? Treat the host as compromised. Isolate it, rotate all credentials and salts, and rebuild from a known-good state. Cron-driven writes can re-drop payloads after naive cleanup.

Will this be added to KEV? Unknown. KEV additions follow CISA's own confirmation of in-the-wild exploitation. Continue monitoring the catalog and re-prioritize if the entry appears.

Additional resources

Trusteed publishes emergent-threat analysis for defenders. We do not publish weaponized exploit recipes. Validate exposure in controlled environments, patch where you can, and disable features where you cannot.