插件名称	WooCommerce Purchase Orders
漏洞类型	File deletion vulnerability
CVE 编号	CVE-2025-5391
急	高
CVE 发布日期	2025-08-11
源网址	CVE-2025-5391

Critical alert: WooCommerce Purchase Orders (≤ 1.0.2) — Authenticated Subscriber Arbitrary File Deletion (CVE-2025-5391)

日期： 11 August 2025
严重性： High (CVSS 7.7)
Affected software: WooCommerce Purchase Orders plugin for WordPress (versions ≤ 1.0.2)
所需权限： Authenticated user with Subscriber role or higher
类型： Arbitrary file deletion / Injection (OWASP A1 classification)
CVE: CVE-2025-5391

As the team behind WP-Firewall, we’re publishing this advisory to help site owners, developers and security teams understand the risk, detect attempted exploitation, and apply immediate mitigations. This vulnerability allows an authenticated low-privilege user (Subscriber) to cause arbitrary file deletion on affected sites. Because Subscribers are normally widely available on many e-commerce sites (customer accounts, newsletter signups, etc.), this is a high-risk situation: large numbers of accounts + scriptable attacks = fast, broad impact.

This post covers:

• What the vulnerability is and why it’s dangerous
• Likely exploitation scenarios and impact
• How to detect attacks and indicators of compromise (IoCs)
• Immediate steps to mitigate risk (no-official-patch-safe-first-aid)
• Recommended long-term remediation and hardening
• How WP-Firewall can protect your site now (virtual patching + rules)
• Incident response and recovery checklist
• Guidance for plugin authors and site operators

Note: we will not publish exploit code or proof-of-concept details. If your website is in production, follow the containment and recovery steps below instead of attempting to reproduce the bug.

---

Quick summary for site owners

• If you run WordPress with the WooCommerce Purchase Orders plugin at version 1.0.2 or earlier, and you allow user registration or have Subscribers on the site, your site is at risk of arbitrary file deletion by an authenticated attacker.
• No official fix is available at time of publication. Treat this as actively exploitable.
• Immediate recommended actions: remove/disable the affected plugin (if feasible), tighten account creation and Subscriber privileges, implement virtual patching or WAF rule(s) to block the vulnerable endpoint/parameters, check webserver and WordPress logs for deletion attempts, and restore from clean backups if files were removed.
• If you use WP-Firewall (free plan or managed), enable our emergency virtual patching rules we published for this vulnerability; these rules stop common attack patterns and protect sites from the exploit while a vendor patch is not yet available.

---

What happened? Technical overview (non-exploitative)

At its core the issue is improper validation and authorization on an action that deletes files. The plugin exposes functionality that accepts a path or filename from an authenticated user. The server-side logic does not sufficiently validate user input (insufficient sanitization and path normalization) and does not enforce strict capability checks beyond a low-level role (Subscriber). That combination allows a malicious subscriber to craft a request that causes the application to delete files outside of the expected scope — resulting in arbitrary file deletion.

Key technical elements:

• Endpoint accepts user-supplied path/filename parameters.
• The plugin does not restrict the deletion target to a safe directory (no robust use of realpath and strict directory-prefix checks).
• Role or capability checks are insufficient: a basic Subscriber is able to invoke the endpoint.
• Input normalization is incomplete; path traversal or manipulation can reach files the plugin’s author did not intend to allow.
• Because the delete action runs on the PHP process, it can remove WordPress core files, plugin files, theme files, upload assets, and other server-side resources.

This classifies as arbitrary file deletion (a file-system-modifying injection). The practical impact is large: deletion of key files can make a site inoperable or expose it to follow-on attacks (e.g., removing detection tools, deleting logs, removing index.php, etc.).

---

Attack scenarios and impact

Realistic attacker goals after successful exploitation include:

• Site disruption: delete WordPress core files (index.php, wp-settings.php), plugins, or theme files to break the site or cause downtime.
• Backdoor evasion: delete logs or security plugin files to cover traces.
• Ransom or extortion: threaten or perform destructive deletion and demand payment.
• Data destruction: remove uploaded files (images, invoices, attachments) to cause business interruption.
• Pivot for follow-on attacks: removing integrity checks and security plugins to make future access easier.

Because the required account level is Subscriber (or equivalent), attackers can automate the whole process:

1. Create a Subscriber account (or use an existing customer).
2. Authenticate.
3. Send specially-crafted requests to the vulnerable endpoint to delete targeted paths.
4. Repeat or scale across many accounts for persistent damage.

Potential impact on businesses: lost revenue, search engine ranking drops, customer trust erosion, incident recovery cost.

---

为什么这很紧急

• Low privilege needed: Subscribers are common and often self-registered.
• No official patch available (at the time of this advisory).
• Easy to automate: authenticated actions are routine for bots and attackers; once the endpoint is known, exploitation is straightforward to scale.
• Deletion is immediately destructive and may remove backups or forensic evidence if not protected.
• CVSS 7.7 indicates high severity — treat it as high priority.

---

Detection — what to look for

Monitor logs and systems for the following signs. Collect evidence for incident response before making changes that may destroy logs.

1. Webserver access logs (Apache/Nginx)
   • POST or GET requests to plugin-specific endpoints (look for URLs that include strings like /wc-purchase-orders/ or variations).
   • Requests from authenticated user sessions or with valid cookies where the username is a Subscriber.
   • Unexpected parameters containing ../ (dot-dot), %2e%2e, long base64-encoded strings, or filenames that map to known WP or plugin filenames.
2. WordPress debug logs / plugin logs
   • Entries indicating file operations (unlink, unlink failing/succeeding).
   • Unexpected PHP warnings or fatal errors referencing missing files.
3. Server filesystem
   • Missing core files (index.php, wp-config.php missing is unusual but possible).
   • Deleted uploads (wp-content/uploads) or plugin/theme files.
   • Timestamps showing deletion times correlating with suspicious requests.
4. Integrity checks
   • Failing file checksums, version mismatches, missing plugin/theme folders.
   • Monitoring tools alerting on removed files or changed file lists.
5. User behavior
   • New user accounts with similar naming patterns or from same IPs.
   • Login events for Subscribers at odd hours correlating with deletions.

If you find IOC activity, preserve logs and take the site offline or isolate it for forensic review depending on business needs.

---

Immediate mitigation steps (step-by-step)

If your site uses the affected plugin version and cannot immediately patch (no official release exists yet), perform the following emergency steps in sequence. These are prioritized to reduce risk quickly.

1. Take a snapshot / backup (preserve current state)
   • Create an isolated server snapshot and download copies of webserver logs and WordPress logs. This preserves forensic evidence.
   • If your hosting provider offers a snapshot option, use it rather than relying on a WordPress backup that might be incomplete.
2. Disable the plugin (recommended if feasible)
   • From WP Admin > Plugins, deactivate and remove the WooCommerce Purchase Orders plugin.
   • If you can’t access WP Admin, rename the plugin folder via SFTP/SSH (wp-content/plugins/wc-purchase-orders → wc-purchase-orders-disabled).
3. Restrict account creation and Subscriber actions
   • Temporarily disable user registration (Settings > General > Membership).
   • Remove or downgrade unnecessary Subscriber accounts that you suspect as malicious.
   • Force password resets for users if you detect compromise.
4. Virtual patch / WAF blocking (immediate protective barrier)
   • Deploy WAF rules that block access to the plugin’s endpoints from non-admin roles and block suspicious parameter values.
   • If you run WP-Firewall, enable the emergency ruleset that blocks requests matching the vulnerable patterns (we provide tuned signatures that target typical exploit payloads and endpoint routes). See the WP-Firewall section below for how we protect affected sites.
5. Harden filesystem protections
   • Restrict PHP process permissions: ensure the webserver user cannot remove critical files (set strict file permissions where practical).
   • Consider a read-only deployment for core files when urgent: mark core directories as immutable via OS controls if your host supports it (use with caution and after testing).
6. Scan for compromise
   • Run a full malware scan and file integrity scan. Check for newly created admin users, modified plugin files, or webshells.
   • Compare current files against a known-good backup.
7. Restore missing files from backups if necessary
   • If core files are missing and you have clean backups, restore to a clean point. Keep the snapshot taken earlier to support forensics.
8. Rotate secrets
   • If there’s evidence of compromise beyond deletion, rotate keys, API credentials, and database passwords.

Do these steps immediately — the longer the vulnerable plugin remains active and reachable, the higher the risk.

---

Example WAF mitigation rules (conceptual)

Below are example patterns you can use in a WAF to block likely exploit attempts. These are intentionally descriptive and safe — do not use them as a drop-in exploit reproduction. Consult your firewall documentation before deploying any rules.

1. Block requests to known plugin paths by non-admins
   Condition: REQUEST_URI matches ^/.*(wc-purchase-orders|purchase-orders).*$
   Condition: requesting user is authenticated but not an admin (or role cookie indicates Subscriber)
   Action: Block / return 403
2. Block requests that contain traversal attempts in delete parameters
   Condition: REQUEST_METHOD is POST or GET
   Condition: a parameter (filename, file, path, target) contains ../ 或者 %2e%2e or begins with /etc/ or contains ../wp- 或者 ../../
   Action: Block and log
3. Rate-limit authenticated Subscriber endpoints
   Condition: REQUEST_URI matches plugin endpoints
   Condition: requester role equals Subscriber
   Action: Throttle to a low request rate or require additional verification (e.g., CAPTCHA)
4. Block dangerous PHP functions when invoked from plugin paths (host-level/containment)
   Condition: script path contains /wp-content/plugins/wc-purchase-orders/ and PHP invoked unlink, unlink functions (detected via runtime hooks)
   Action: Block call and alert

If you run WP-Firewall, our emergency virtual patch translates the above into rules that are tuned to avoid false positives and deployed instantly across protected sites.

---

How WP-Firewall protects you (virtual patching + detection)

As a managed WordPress firewall vendor we approach this class of vulnerabilities with layered protection:

1. Virtual patching (rule-level)
   As soon as a credible indicator appears, we create targeted WAF signatures that prevent the exploit patterns from reaching the vulnerable code path. This stops attackers from executing the delete action even if the plugin remains installed and active.
   Our signatures focus on the endpoint routes used by the plugin, suspicious input patterns (path traversal, suspicious file names) and role-based anomalies. Rules are tuned to minimize false positives.
2. Role-aware blocking
   We can detect requests originating from non-admin user sessions (Subscriber) and restrict or throttle behavior to prevent abuse.
3. Behavior detection
   If an account begins issuing suspicious delete-like requests, we can raise an alarm and block further activity automatically.
4. File-operation monitoring
   We monitor filesystem changes and can alert on mass deletions or deletion of high-value files (core files, wp-config.php, etc.) in real time.
5. Cleanup and response support
   For Pro customers we offer automated steps for rollback and post-incident hardening and assistance with forensic log collection.

If you want immediate protection without waiting for an official plugin update, our free plan includes managed firewall and WAF features that will block common attack patterns for this vulnerability. See the section below for more details and how to sign up.

---

Long-term remediation guidance (for site owners & plugin developers)

对于网站所有者：

• Remove or update the vulnerable plugin once an official vendor patch is released. Verify vendor release notes and checksum before updating.
• If a patch never arrives, consider switching to an alternative maintained plugin that provides the same functionality.
• Implement least privilege: limit user roles; avoid granting write/delete capabilities to low-privileged accounts.
• Harden file permissions and use file integrity tooling. Keep regular, tested backups offline.

For plugin developers:

• Never allow deletion of arbitrary paths based solely on user input. Use whitelist approaches where possible.
• When deleting files, validate the target path:
  • 使用 realpath() and verify the target path begins with an allowed base directory.
  • Reject relative paths containing ../ 或者 %2e sequences after normalization.
  • Ensure only strict, expected filenames are removable (map IDs to filenames server-side, do not accept raw file paths).
• Apply capability checks: only users with the correct WordPress capability should be allowed to perform destructive actions — for example, delete operations should be limited to manage_options or specific custom capabilities assigned to trusted roles.
• Rate-limit destructive operations and implement nonce verification and admin-initiated confirmations.
• Log destructive actions with user ID and timestamp for auditing.

---

Detection rules for SIEM and logging

If you use centralized logging or a SIEM, add these detection rules:

• Excessive POSTs to plugin-specific endpoints from many different Subscribers within short time windows.
• POSTs or GETs with parameters containing dot-dot sequences or base64-encoded path strings.
• File system events where unlink() is called followed by missing core files (e.g., removal of wp-load.php, wp-settings.php).
• Sudden changes in file counts under wp-content/uploads or the plugins directory.

Keep logs for at least 90 days where possible for forensic analysis.

---

If your site was already attacked — incident response & recovery checklist

1. Isolate the environment
   • If possible, place the site in maintenance mode or take it offline to prevent further damage and to limit exposure.
2. Preserve evidence
   • Make snapshots of the server and download logs (access, error, WP, plugin).
   • Avoid making changes that would overwrite logs until snapshots are complete.
3. Identify scope
   • Determine which files were deleted, which user accounts performed the action, and whether backups exist.
4. Restore
   • Restore affected files from a verified clean backup. Validate integrity after restore.
   • Do not restore from a backup that might be contaminated; verify backup integrity first.
5. Clean up and harden
   • Remove the vulnerable plugin or ensure virtual patching is active.
   • Rotate secrets and credentials (DB password, salts, API keys) if compromise beyond deletion is suspected.
6. Forensic review
   • Work with security professionals for deeper investigation if high-value data or business-critical systems are impacted.
7. Post-incident communication
   • Notify stakeholders and customers where required by policy or regulation. Keep communications factual and transparent.
8. Learn and update
   • Implement the long-term remediation steps above and update incident response playbooks with lessons learned.

---

Frequently asked questions (FAQ)

问： Is a Subscriber able to delete any file on the server?
A： In vulnerable installations, yes — the bug allows deletion of files reachable by the PHP process, depending on file path handling and server permissions. The exact files that can be deleted depend on how the plugin constructs paths and the webserver user permissions.

问： Will disabling the plugin immediately stop the attack?
A： Deactivating or removing the plugin will stop further exploitation via that plugin’s endpoints. If you cannot access WP Admin, rename the plugin folder via filesystem access.

问： Could backups be deleted as well?
A： If backups are stored on the same filesystem and are writable by the webserver user, they could be targeted. Prefer off-server or immutable backups.

问： Should I wait for an official patch?
A： No. If the plugin is active and you cannot confirm a pending patch, use the mitigations above (disable plugin, virtual patch/WAF, restrict accounts, restore from safe backups).

---

For hosting providers and agencies

If you manage multiple sites or client sites:

• Identify customers using the affected plugin and notify them immediately (support ticket + recommended actions).
• Roll out WAF rules at the network/edge level for all customers until the plugin is patched.
• Offer migration or removal assistance for clients who cannot take immediate action.
• Monitor for correlated attack patterns across your network.

---

Title: Protect your site today — join WP-Firewall’s free Basic plan

If you want immediate protection for this kind of risk without waiting for plugin updates, consider our WP-Firewall Basic (Free) plan. It includes a managed firewall, WAF, unlimited bandwidth protection, a malware scanner and mitigations for OWASP Top 10 risks — all essential tools to prevent attacks like the one described here. Sign up for the free plan and enable emergency rules now: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Why the free plan helps:

• Managed WAF signatures deployed quickly to block known exploit patterns.
• Malware scanning to find signs of compromise.
• OWASP Top 10 protections to reduce exposure to other common attacks.
• Unlimited bandwidth protection so mitigation doesn’t impact your traffic.

You can upgrade later for automated malware removal, IP blacklist/whitelist controls and virtual patching if you want hands-off protection and deeper mitigation.

---

Recommendations checklist (quick reference)

• Take a full server snapshot and collect logs.
• Deactivate or remove the vulnerable plugin immediately.
• If you cannot remove it, deploy WAF rules to block plugin endpoints and suspicious parameters.
• Disable user registration and review Subscriber accounts for suspicious activity.
• Run file integrity and malware scans; restore missing files from verified backups.
• Rotate credentials and secrets if compromise is suspected.
• Monitor logs for further suspicious activity and prepare for follow-up hardening.

---

Closing thoughts

This vulnerability shows how dangerous file-system modifying actions can be when paired with weak input validation and permissive authorization. Plugins add value to WordPress, but they also introduce risk — particularly when destructive actions can be triggered by low-privilege accounts. While we wait for an official plugin update, take the protective steps above immediately.

If you need help implementing any of the mitigations in this advisory — from WAF deployments to virtual patching and incident response — the WP-Firewall team is available to assist. Our free Basic plan provides immediate managed WAF and scanning to reduce your exposure right now; the link to sign up is: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Stay safe, monitor your logs, and treat this as high priority. If you’re a developer of the affected plugin: ensure your next release includes strict path validation, capability checks and server-side whitelisting for any destructive operations.

— WP-Firewall Security Team