Plugin Name	Woocommerce Custom Product Addons Pro
Type of Vulnerability	Remote Code Execution
CVE Number	CVE-2026-4001
Urgency	High
CVE Publish Date	2026-03-28
Source URL	CVE-2026-4001

Remote Code Execution in WooCommerce Custom Product Addons Pro (CVE-2026-4001): What WordPress Site Owners Need to Know — and Do Right Now

Updated: 24 March 2026
Affects: WooCommerce Custom Product Addons Pro <= 5.4.1
Patched: 5.4.2
CVE: CVE-2026-4001
Risk: Unauthenticated Remote Code Execution (RCE) — highest practical severity

If you run a WooCommerce store that uses the Custom Product Addons Pro plugin, this advisory is for you. A critical flaw in versions up to and including 5.4.1 allows an unauthenticated attacker to submit a specially crafted “custom pricing” formula that is processed in a way that can lead to remote code execution on the server. In plain language: an attacker can execute arbitrary commands on your web host, without needing an account on your site.

This is the kind of vulnerability that gets weaponized quickly in large automated campaigns. Read this post carefully — it’s written from the perspective of WP-Firewall security engineers and site responders. We’ll explain what happened, why it’s so dangerous, how to confirm exposure, immediate containment steps you must apply, recommended forensic checks, and robust mitigations including WAF rules and long‑term hardening. We’ll also show how our free plan can help you protect sites that can’t be patched right away.

---

Executive summary (quick actionable steps)

• If your site uses Custom Product Addons Pro and the plugin version is ≤ 5.4.1, update to 5.4.2 immediately.
• If you cannot apply the update immediately, take the plugin offline (deactivate) or block exploit traffic at the edge (WAF, proxy, host-level firewall).
• Scan for indicators of compromise (unexpected admin users, modified PHP files, new scheduled tasks, outbound connections), and preserve logs for incident response.
• Implement short-term virtual patching rules to block exploit vectors (examples below).
• Rotate credentials (WP admins, SSH, database) after you have confirmed the environment is clean or restored from a trusted backup.
• Enroll the site in automated WAF / malware scanning protection if possible while you patch.

---

Why this vulnerability is so serious

Remote Code Execution is the worst-case class of web application vulnerability. Unlike an information disclosure or privilege escalation that requires an authenticated user, the vulnerability described by CVE-2026-4001 is unauthenticated: any remote actor can submit a malicious payload. Once exploited, RCE typically allows attackers to:

• Install backdoors and webshells for persistent access.
• Add rogue administrator accounts and tamper with content.
• Exfiltrate databases and stored customer data (including payment metadata).
• Deploy cryptocurrency miners, spam engines, or ransomware.
• Use your infrastructure as a pivot point to attack other networks.

Because many WooCommerce stores handle payments and customer PII, exploitation can quickly lead to regulatory exposure, financial loss, site downtime, and reputational damage.

---

Technical summary (non-exhaustive, safe-to-publish)

• Root cause: The plugin accepts user-supplied “custom pricing” formulas or expressions that are evaluated server-side without sufficient sanitization or context validation. In affected versions, an attacker can craft input that results in server-side evaluation of code or unsafe function calls.
• Trigger path: The vulnerability is reached through plugin code that processes custom pricing inputs (usually supplied via a product form or AJAX endpoint). The processing flow performs an evaluation or transformation step that can be abused to execute arbitrary code.
• Authentication: None required. The vulnerable entry points are reachable from unauthenticated requests on many installations.
• Impact: Remote code execution on the web server process (PHP), with the same permissions as the web server user. On many shared or misconfigured hosts this is enough to drop backdoors, access writable areas, or escalate further.

I’m intentionally not publishing proof‑of‑concept exploit code here. Publishing exploit code in a public blog post risks accelerating mass exploitation. Instead, I’ll provide safe technical indicators and defensive signatures you can use to block and detect attacks.

---

Who is affected?

• Any site running the WooCommerce Custom Product Addons Pro plugin at version 5.4.1 or earlier.
• Stores where the plugin is active and the site accepts custom pricing inputs (product pages, AJAX endpoints servicing product add-ons).
• Hosts with permissive PHP configurations or weak isolation boundaries are more at risk of post-exploit lateral movement.

If you’re not sure whether your store uses the plugin: check the WordPress admin Plugins page and the filesystem under wp-content/plugins/ for the plugin directory name. If you find it and the plugin version is ≤ 5.4.1, treat the system as vulnerable until patched.

---

Immediate actions (ordered by priority)

1. Check plugin version now
      – Log into WordPress (or via SFTP) and confirm the installed plugin version. If version ≤ 5.4.1, proceed immediately to step 2.
2. Apply the vendor update (best option)
      – Update the plugin to 5.4.2 (or later) as soon as possible. This is the definitive fix.
3. If you cannot patch now, apply emergency mitigation
      – Deactivate the plugin via the WordPress Plugins screen or rename the plugin folder via SFTP (e.g., append .disabled to the plugin directory name).
      – If deactivating breaks your checkout flow and you need the plugin, implement virtual patching at your web application firewall or host edge to block exploit patterns (examples follow).
4. Block suspicious traffic immediately
      – Use server / host firewall to restrict or block incoming POST/GET requests that include unusual payloads in the custom pricing form fields or known parameter names. If you have a WAF, enable rules to block suspicious evaluation patterns.
5. Preserve logs & take a backup
      – Before making forensic changes, ensure web server logs, PHP-FPM logs, and access logs are preserved and backed up for investigation.
6. Scan for signs of compromise
      – Run a thorough malware and file integrity scan.
      – Look for new admin accounts, unauthorized scheduled tasks (cron/cwp), modified core files, or suspicious PHP files uploaded in wp-content/uploads or other writable directories.
7. Rotate credentials after cleanup
      – Rotate all administrator passwords, API keys, database credentials, and any SSH keys if you find evidence of compromise. If you must rotate passwords before full cleanup, still proceed — but be prepared to rotate again after a confirmed remediation.

---

Suggested virtual patch / WAF rules (examples)

If you cannot patch immediately, virtual patching provides an effective short-term barrier. Below are safe, conservative rule examples you can use to block attempted exploitation — tune them to avoid false positives.

Important: test any rule in a staging environment or in “log-only” mode first to measure false positives.

• Block requests where user-supplied formula parameters contain patterns that indicate code evaluation:
  • Block if request body or query contains eval(, assert(, system(, shell_exec(, passthru(, exec(, popen(, proc_open(, or create_function(.
  • Block if parameter contains base64_decode( followed by eval or create_function.
• Block suspicious serialization or encoded payloads:
  • Block requests where a parameter value contains long base64 strings (e.g., > 200 chars) combined with execution indicators.
• Block suspicious characters in pricing fields:
  • Block requests to product add-on endpoints where numeric “price” fields contain alphabetic characters like ;, |, &, $, <, > — these are unusual in numeric pricing fields and often used for injection.
• Block access patterns to plugin-specific endpoints (if known):
  • If the vulnerable plugin exposes a specific AJAX action or endpoint, block or allow-list access to that endpoint so only known good referers or internal networks can call it.
• Rate-limiting and IP reputation:
  • Apply strict rate limits to POST requests on product endpoints. Block IPs that attempt repeated suspicious inputs.

Example signature (pseudocode; adapt to your WAF syntax):

• If REQUEST_METHOD == “POST” and (REQUEST_BODY contains eval( OR REQUEST_BODY contains base64_decode() then BLOCK
• If REQUEST_URI matches /wp-admin/admin-ajax.php and REQUEST_BODY contains custom_price and REQUEST_BODY contains non-digit characters beyond standard symbols, then LOG and BLOCK if repeated.

Note: these example patterns are intentionally generic. Coordinate with your host or WAF documentation to convert them into the correct rule syntax (ModSecurity, Nginx, Cloud WAF console, etc.).

---

Detection: what to look for (indicators of compromise)

If you suspect your site was attacked, search for the following indicators. Keep in mind that attackers often try to clean up evidence, so absence of obvious artifacts does not prove you are clean.

• Web server access logs:
  • POST requests to product pages, admin-ajax.php, or plugin endpoints containing long encoded strings or suspicious symbols in pricing-related parameters.
  • Requests with unusual User-Agent strings or blank user agents.
  • Burst of similar POST requests from the same IP range attempting pricing/formula submissions.
• File system:
  • New or modified PHP files in wp-content/uploads, wp-includes, wp-content/plugins, or other writable directories.
  • Files with suspicious names: single-letter .php files, files pretending to be images but containing PHP, or files with odd timestamps.
  • Modifications to wp-config.php, .htaccess, or theme functions.php.
• Database:
  • New user accounts with administrator role.
  • Suspicious options in wp_options (rogue scheduled events or unexpected serialized blobs).
  • Any unexpected changes to orders or product data.
• Processes and network:
  • Unexpected cron jobs or scheduled tasks that call external URLs.
  • Outbound network connections from the server to unknown IP addresses, especially on unusual ports.
• Behavioral:
  • Sudden SEO spam or content changes.
  • New pages redirecting visitors to malicious domains.
  • Disabled or locked admin accounts.

If you find indicators, act fast: isolate the server, make a disk image if possible, and engage an incident response process.

---

Forensic checklist (step-by-step)

1. Preserve evidence
      – Copy and archive relevant logs (access, error, PHP-FPM, database logs). Work from copies; do not change originals.
2. Snapshot the site
      – Take a file system snapshot or make an offsite backup before remediation steps that modify the environment.
3. Identify the entry point
      – Correlate timestamps of suspicious requests with file changes and new accounts to isolate how an attacker gained access.
4. Hunt for persistence
      – Search for webshell patterns (functions like system, exec, popen used in conjunction with request parameters), eval wrappers, and obfuscated PHP (base64_decode, gzinflate, str_rot13, etc.).
      – Look for scheduled tasks (WP-Cron or system cron) that run PHP scripts from uploads or caches.
5. Clean, restore, or rebuild
      – If backup is clean and recent, restore from backup after patching and hardening.
      – If compromised and no clean backup available, rebuild the site, reinstall WordPress and plugins from trusted sources, and restore content only after verifying it’s clean.
6. Rotate secrets
      – After cleaning, rotate all credentials — WP admin accounts, database user, any API tokens, and SSH keys.
7. Post‑incident monitoring
      – Monitor logs intensively for at least two weeks after remediation for signs of re-infection.

---

Hardening recommendations to reduce future risk

• Keep plugins and themes updated and apply security updates promptly.
• Limit plugin install and update privileges to trusted admins only.
• Use a staged environment to test plugin updates before deploying to production.
• Implement least privilege for WordPress users: don’t give admin rights unless necessary.
• Use file integrity monitoring (FIM) to detect unauthorized file changes.
• Run regular malware scans and security audits.
• Implement WAF protections including virtual patching and behavior-based rules.
• Disable features you don’t use — if the plugin’s custom pricing feature isn’t in use, consider disabling or replacing the plugin.
• Use a strong password policy and enable MFA for administrative accounts.
• Keep full, tested backups stored offsite and verify restore procedures regularly.

---

How a managed WAF/Firewall helps in incidents like this

A managed WordPress application firewall provides multiple benefits in situations like CVE-2026-4001:

• Rapid virtual patching: WAF rules can be deployed to block the exploitation vector in minutes, reducing risk while you schedule or test plugin updates.
• Behavioral protection: rate limiting and anomaly detection can disrupt automated mass scanning and exploitation campaigns.
• Malware scanning and cleanup: integrated scanners identify webshells and suspicious artifacts; higher-tier services can automatically remove some classes of malware.
• Monitoring and alerting: near-real-time alerts on suspicious activity let you act faster.
• Expert analysis: an experienced security team can tune rules to reduce false positives while maintaining protection.

If you manage multiple WordPress sites, a centralized WAF greatly reduces the operational burden of responding to emergent high-severity vulnerabilities.

---

Log patterns and sample detections you can use (safe, non-exploit)

Below are detection heuristics that you can search for in logs. They are intended to flag potentially malicious attempts to use formula or evaluation fields.

• Access log search (examples):
  • POST requests containing custom AND price AND either base64 OR eval OR system in the request body.
  • Sequences of repeated POSTs to the same URL with slightly varied payloads from one IP within a short timeframe.
• File system heuristic:
  • Files with PHP content in the uploads directory:
    grep -R "<?php" wp-content/uploads
  • New files modified after the initial compromise timestamp.
• Database heuristic:
  • Search usermeta for accounts with administrator capabilities created at the same time suspicious activity began.
  • Audit recent entries in wp_options for unfamiliar scheduled events.
• Behavior:
  • Outgoing connections to known bad hosts or unusual endpoints.
  • Spikes in CPU usage on the host (indicating cryptominer or heavy tasks).

These patterns are high-signal but not exhaustive. Combine multiple indicators to reduce false positives.

---

Practical example: safe virtual-patching rules to block evaluation-like payloads

Implement these as conservative filters in your WAF or server-level rules. Replace with correct syntax for whatever firewall or rule engine you use.

• Rule A (block eval-like tokens in POST bodies)
    – Condition: REQUEST_METHOD == POST AND REQUEST_BODY contains any of: eval(, assert(, create_function(, preg_replace(/e, base64_decode(, gzinflate(.
    – Action: Block or Challenge (CAPTCHA) for initial blocking.
• Rule B (rate-limit POSTs to product endpoints)
    – Condition: More than X POST requests to product-related URIs from a single IP within Y seconds.
    – Action: Temporarily block or throttle.
• Rule C (numeric field validation)
    – Condition: Numeric price or discount fields contain alphabetic characters or suspicious punctuation (;, |, &).

  – Action: Reject request with 400.

Note: If your forms legitimately accept formulas (rare in pricing fields), apply a whitelist approach: only allow tightly constrained characters and patterns that correspond to your legitimate expression language.

---

Recovery and remediation playbook (concise procedure)

1. Patch plugin to 5.4.2 or later.
2. Take the site offline if signs of compromise are present; place a maintenance page.
3. Preserve logs and evidence for forensics.
4. Scan codebase and uploads for webshells; remove identified malicious files.
5. Restore from a verified clean backup if necessary.
6. Rotate all sensitive credentials.
7. Deploy WAF rules and monitor traffic.
8. Re-enable the site and monitor for re-infection.

If you run many sites, prioritize those that store payment data, have large user counts, or are mission-critical.

---

Why you should act decisively, even if your site seems small

Attackers do not always discriminate by site popularity. Automated scanners and exploit kits target any vulnerable install they can reach. Smaller stores are attractive because they often have weaker monitoring and recovery processes. An unauthenticated RCE is an open door: once inside, attackers can quickly set up persistence and use your server to target other sites, launch spam campaigns, or monetize access by selling it.

Every hour you delay increases the window of exposure.

---

How WP-Firewall helps (a short guide to available protections)

At WP-Firewall we provide layered protection designed for WordPress and WooCommerce environments. Key features that defend against the types of attack used against CVE-2026-4001 include:

• Managed web application firewall (WAF) with virtual patching for emerging zero-day threats.
• Malware scanning to find webshells and backdoors.
• Managed detection and response: alerts and guidance when suspicious behavior is detected.
• Auto-mitigation rules tuned for WordPress plugin attack patterns (without impacting legitimate traffic).
• Security hardening guidance and incident response support.

If you cannot immediately apply the plugin update, enabling a managed WAF that can deploy virtual patches is one of the fastest ways to reduce risk across many sites while you schedule maintenance windows.

---

Secure Your Store Now — Start with WP-Firewall’s Free Plan

If you need immediate, low-friction protection while you schedule patching or incident response, WP-Firewall’s Basic (Free) plan covers essential defenses for WordPress and WooCommerce sites. The free plan includes a managed firewall, unlimited bandwidth, WAF protections, a malware scanner, and mitigation for OWASP Top 10 risks — everything you need to reduce exposure quickly.

Try the free plan and protect your store today: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(If you need automated cleanup, whitelist/blacklist controls, or virtual patching with reporting across multiple sites, consider upgrading to Standard or Pro tiers for additional automation and managed response.)

---

Frequently asked questions

Q: If I patch, do I still need to scan my site?
A: Yes. If you were vulnerable before patching, it’s important to verify that attackers did not exploit the flaw prior to the update. Patch prevents future exploitation but does not remove already installed backdoors.

Q: Can I just deactivate the plugin and re-enable later?
A: Deactivation removes the vulnerable code from execution, which is a valid mitigation. But if a compromise already occurred, deactivation alone does not remove backdoors or other artifacts. Perform a full scan and remediation.

Q: What if updating breaks my site?
A: If update testing in staging shows compatibility issues, roll back to your pre-update state and apply protective WAF rules and stricter input validation while you resolve compatibility. Ideally, run the update in a maintenance window after backups.

Q: What log or evidence should I preserve for an investigator?
A: Preserve access logs, error logs, PHP-FPM logs, database logs around the timeframe of the suspected exploit, and any modified file metadata. Disk images are highly useful for detailed forensic work.

---

Closing: a practical checklist you can follow now

1. Verify the plugin version now.
2. If vulnerable: update to 5.4.2 immediately.
3. If you cannot update: deactivate plugin or enable WAF virtual patching.
4. Preserve logs and take backups before changing anything.
5. Scan for and remove any malware/backdoors.
6. Rotate all administrative and infrastructure credentials after cleanup.
7. Implement monitoring, FIM, and periodic malware scans to reduce future risk.

---

If you want help implementing any of the above — from setting tactical WAF rules to conducting a comprehensive forensic sweep — our WP-Firewall response engineers are available to assist. We routinely help store owners close urgent gaps, enact virtual patches, and verify sites are clean after high-severity vulnerabilities.

Stay safe and act fast: the cost of delay is often far greater than the effort to patch and harden today.