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

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. A public proof-of-concept is circulating, and CVE-2026-18080 is not listed in CISA's Known Exploited Vulnerabilities (KEV) catalog as of this writing.

What this is

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 it matters

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 matters here, 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.

How it works

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:

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

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.

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.

Detection and response

The hypothesis to test is whether your estate runs the affected plugin with the CRM module and IMAP Email Connect enabled, and whether PHP executes in wp-content/uploads/ — because that combination is what turns an upload bug into RCE.

Evidence that confirms or rejects exposure:

• Plugin inventory: the ERP plugin directory (commonly erp) present in wp-content/plugins/, with an installed version ≤ 1.17.8.
• Feature state: the CRM module active and an inbound IMAP mailbox configured in the CRM settings. If no mailbox is configured, the cron job has nothing to poll and the attack path is closed.
• Host configuration: on Apache, .htaccess rules in wp-content/uploads/ that disable the PHP engine; on Nginx, 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.
• Prior exploitation: unexpected .php files in wp-content/uploads/, especially at the top level and outside known plugin subdirectories; web server access logs showing GET or POST requests to wp-content/uploads/*.php from external IPs; mail server logs showing messages to the CRM mailbox with forged References headers or attachments containing ../ in the filename; unexpected admin users, modified theme functions.php, and suspicious wp_options entries.
• Process and network: unexpected child processes spawned by PHP-FPM or the web server worker (e.g., bash, curl, wget, python3) following WordPress cron activity, and outbound connections from the web server process to unexpected external IPs or domains.

Hunting for this CVE is mostly about correlating three data sources: mail logs, web server logs, and file integrity monitoring on the uploads directory. On the 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. On the web side, alert on any external request to wp-content/uploads/*.php; legitimate WordPress operations rarely serve PHP from uploads. On the 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. On the 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.

What to do

1. Inventory the plugin. Check wp-content/plugins/ for the ERP plugin directory (commonly erp) and 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 rather than relying 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 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.
5. 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.
6. If you cannot patch immediately, 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.
7. 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.
8. Restrict the inbound mailbox. Limit accepted senders to trusted addresses and monitor for anomalous attachments.
9. Add a WAF rule. Block external requests to wp-content/uploads/*.php.
10. Harden file permissions. Ensure the web user cannot write outside designated directories.
11. Review for prior exploitation. Search wp-content/uploads/ for unexpected .php files, review web server access logs for requests to wp-content/uploads/*.php from external IPs, review mail server logs for forged References headers or traversal-style attachment names, and check for unexpected admin users, modified theme functions.php, and suspicious wp_options entries.
12. If you suspect or confirm exploitation, treat the host as compromised. Isolate it, rotate WordPress salts and keys, all admin credentials, database passwords, and 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. Because this plugin touches HR, accounting, and CRM data, loop in legal, privacy, and compliance stakeholders early — regulatory notification clocks may apply.

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.

Where this fits in a program

Treat this CVE as a scoping, validation, and mobilization problem rather than a one-off patch ticket. Scoping means answering how many sites run this plugin, how many have the CRM module and IMAP Email Connect enabled, and how many allow PHP execution in uploads — the third is the one most teams have never measured. Validation means confirming the attack path is reachable on a representative host before assuming your configuration blocks it, so a scanner hit is not treated as proof. Trusteed frames this as attack surface inventory plus validation, with API surface testing and deeper web application testing where the estate extends beyond WordPress.

Sources

• GitHub Advisory (GHSA-xp5r-phw6-jcr2)
• Wordfence Advisory
• Plugin Changeset
• Public PoC (GitHub)
• Wordfence Weekly Report (Aug 24–30, 2026)
• ENISA EUVD
• CISA Known Exploited Vulnerabilities Catalog
• NVD entry for CVE-2026-18080
• EPSS score lookup

---