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

Date: 11 August 2025
Severity: High (CVSS 7.7)
Affected software: WooCommerce Purchase Orders plugin for WordPress (versions ≤ 1.0.2)
Required privilege: Authenticated user with Subscriber role or higher
Type: Arbitrary file deletion / Injection (OWASP A1 classification)
CVE: CVE-2025-5391

This advisory is issued in the voice of Hong Kong security experts to inform site owners, hosting providers and developers about an actively exploitable vulnerability that allows authenticated low-privilege users to perform arbitrary file deletion on affected sites. Subscribers are commonly available on e-commerce sites (customer accounts, newsletter signups), which makes this a high-risk exposure: many accounts plus automated tooling = fast, broad impact.

What 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 mitigations and containment steps
• Long-term remediation and hardening guidance
• Incident response and recovery checklist
• Guidance for plugin authors and site operators

Note: exploit code or proof-of-concept details will not be published here. If your website is in production, follow containment and recovery steps rather than attempting to reproduce the bug.

Quick summary for site owners

• If your WordPress site uses the WooCommerce Purchase Orders plugin at version 1.0.2 or earlier and allows user registration or has Subscribers, the site is at risk of arbitrary file deletion by an authenticated attacker.
• No official vendor fix was available at the time of publication; treat this as actively exploitable.
• Immediate actions: disable or remove the affected plugin where feasible, tighten account creation and Subscriber privileges, deploy host-level or edge WAF rules to block the vulnerable endpoints/parameters, scan logs for deletion attempts and restore from clean backups if files were removed.
• Assume automation: attackers can and will scale authenticated attacks using many low-privilege accounts.

Technical overview (non-exploitative)

The core issue is insufficient input validation and weak authorization on a file-deletion action. The plugin exposes functionality that accepts a path or filename from an authenticated user. Server-side logic fails to:

• Restrict deletion targets to a safe, whitelisted directory.
• Perform robust path normalization and sanitisation (realpath checks, rejection of .. segments after normalization).
• Enforce strict capability checks beyond a low-level role such as Subscriber.

Combined, these failures allow a malicious Subscriber to craft requests that cause deletion of files outside the intended scope. Because the delete action executes under the PHP process, it is capable of removing WordPress core files, plugin/theme files, uploaded assets and other server-side resources.

Classification: arbitrary file deletion (file-system-modifying injection). The practical impact is significant: removal of core files can render a site inoperable and facilitate follow-on attacks (e.g., removing detection tools, logs or restoring destructive state).

Attack scenarios and impact

Realistic attacker goals and effects include:

• Site disruption: delete core files (index.php, wp-settings.php), plugins or themes to cause downtime.
• Covering tracks: delete logs or security plugin files to hinder detection.
• Ransom/destructive campaigns: threaten or enact destructive deletion to extort payment.
• Data loss: delete uploaded files (invoices, images, attachments) causing business interruption.
• Pivoting: remove integrity checks or security controls to enable further compromise.

Typical automated attack flow:

1. Create or reuse a Subscriber account.
2. Authenticate to the site.
3. Send crafted requests to the vulnerable endpoint to target file paths.
4. Repeat and scale across many accounts to maximize destructive effect.

Consequences include lost revenue, customer trust erosion, recovery cost and reputational damage.

Why this is urgent

• Low privilege required: Subscribers are common and often self-registered.
• Active exploitability and no immediate official patch at time of advisory.
• Simple to automate: authenticated endpoints are easy to script at scale.
• Deletion is immediately destructive and can erase backups or forensic evidence if they are writable by the webserver user.
• CVSS 7.7 categorises this as high severity — respond quickly.

Detection — what to look for

Collect evidence before making changes that may overwrite logs. Look for the following indicators:

1. Webserver access logs (Apache/Nginx)

• POST/GET requests to plugin-specific endpoints (URLs containing strings like /wc-purchase-orders/ or variations).
• Requests authenticated as Subscribers (valid cookies or session tokens associated with low-privilege accounts).
• Parameters containing ../, %2e%2e, long base64-encoded strings or filenames matching known WP/plugin filenames.

2. WordPress and PHP logs

• Entries showing file operations (unlink successes/failures).
• PHP warnings or fatal errors about missing files immediately after suspicious requests.

3. Server filesystem

• Missing core files (e.g., index.php, wp-settings.php).
• Deleted uploads under wp-content/uploads, or missing plugin/theme directories.
• Timestamps correlating deletion time to suspicious HTTP requests.

4. Integrity checks

• Checksum mismatches and failing file integrity reports.
• Alerts from monitoring tools about removed or changed files.

5. User behaviour

• New accounts created in bulk from same IP ranges or with similar naming patterns.
• Login events for Subscribers coinciding with file deletions.

If you observe these IoCs, preserve logs and consider isolating the site for forensic review depending on business needs.

Immediate mitigation steps (step-by-step)

If your site runs the affected plugin and you cannot immediately apply a vendor patch, perform the following steps in sequence. These are prioritised to reduce exposure quickly.

1. Take a snapshot / backup (preserve current state)

   Create an isolated server snapshot and download webserver and WordPress logs. Preserve forensic evidence. Use host snapshots where available rather than relying solely on WordPress backups.

2. Disable the plugin

   From WP Admin > Plugins, deactivate and remove the WooCommerce Purchase Orders plugin. If WP Admin is inaccessible, rename the plugin folder via SFTP/SSH (wp-content/plugins/wc-purchase-orders → wc-purchase-orders-disabled) to force deactivation.

3. Restrict account creation and Subscriber actions

   Temporarily disable user registration (Settings > General > Membership). Review and remove or downgrade suspicious Subscriber accounts. Consider forcing password resets if compromise is suspected.

4. Deploy edge or host-level blocking rules (virtual patching)

   Implement WAF/edge rules or host firewall rules to block access to known vulnerable endpoints and suspicious parameter patterns. Block or throttle requests containing path traversal fragments and restrict delete-like endpoints to admin-only access. If you have managed hosting, request assistance from your provider to apply edge rules quickly.

5. Harden filesystem protections

   Ensure the webserver process has the minimum required file permissions. Where possible, restrict the webserver user’s ability to remove critical files. Consider marking core directories read-only or immutable at the OS level if supported by your host (test first — this can affect upgrades and maintenance).

6. Scan for compromise

   Run malware and file-integrity scans. Look for newly created admin users, modified plugin files, or webshells. Compare current files to a verified good backup.

7. Restore from known-good backups

   If files were removed, restore core files and content from clean backups. Keep the snapshot taken earlier for forensic investigation before making restorative changes.

8. Rotate secrets

   If there is any indication of broader compromise, rotate database credentials, API keys and salts.

Perform these actions immediately — the longer the vulnerable plugin remains active and reachable, the greater the risk.

Example WAF mitigation rules (conceptual)

Below are vendor-neutral example patterns that can be applied in an edge WAF or host firewall to reduce risk. These are descriptive and not exploitative; adapt carefully and test to avoid false positives.

1. Block requests to plugin paths by non-admins

   Condition: REQUEST_URI matches ^/.*(wc-purchase-orders|purchase-orders).*$
   Condition: requester is authenticated but not an admin
   Action: Block (403)

2. Block path traversal attempts in delete parameters

   Condition: REQUEST_METHOD is POST or GET
   Condition: any parameter (filename, file, path, target) contains ../ or %2e%2e or begins with /etc/ or contains ../wp- or ../../
   Action: Block and log

3. Rate-limit authenticated Subscriber endpoints

   Condition: REQUEST_URI matches plugin endpoints
   Condition: requester role equals Subscriber
   Action: Throttle to low request rate or require additional verification (CAPTCHA)

4. Block dangerous calls from plugin paths at host level

   Condition: script path contains /wp-content/plugins/wc-purchase-orders/ and runtime calls unlink()
   Action: Block call and alert

How virtual patching, WAF and monitoring can protect you (vendor-neutral)

When an official patch is not immediately available, layered defensive controls can reduce exposure:

• Virtual patching: Create targeted firewall signatures that prevent exploit payloads from reaching the vulnerable code path. Focus signatures on the specific endpoints and suspicious input patterns while tuning to avoid false positives.
• Role-aware protections: Detect requests originating from non-admin sessions and restrict or throttle their ability to access destructive endpoints.
• Behavioral detection: Monitor for unusual patterns such as many delete-like requests from a single account or IP and block or escalate automatically.
• File-operation monitoring: Alert on mass deletions or deletion of high-value files (wp-config.php, wp-settings.php, core files).
• Host-level containment: Use OS-level controls to limit PHP process capabilities (where possible) and to detect/stop suspicious unlink() operations.

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

For site owners

• Remove or update the vulnerable plugin once an official vendor patch is released. Verify release notes and checksums before updating.
• If no patch is provided, consider switching to an actively maintained alternative plugin that performs the same function.
• Apply least privilege: limit roles and permissions. Avoid granting destructive capabilities to low-privileged accounts.
• Harden file permissions and implement file integrity monitoring with regular, tested offline backups.

For plugin developers

• Never allow deletion of arbitrary paths based solely on user input. Prefer whitelist approaches.
• When deleting files, validate the target path:
  • Use realpath() and ensure the resolved path begins with an allowed base directory.
  • Reject relative paths containing .. or %2e sequences after normalization.
  • Map IDs to filenames server-side; do not accept raw file system paths from clients.
• Enforce strict capability checks: destructive actions should be limited to high-capability roles or specific capabilities assigned to trusted roles.
• Use nonces, confirmations and rate limits for destructive operations.
• Log destructive actions with user ID and timestamp for auditing.

Detection rules for SIEM and logging

Suggested SIEM detections:

• Excessive POSTs to plugin endpoints from many Subscribers within short windows.
• Requests with parameters containing dot-dot sequences or base64-encoded path strings.
• Filesystem events where unlink() is invoked followed by missing core files (e.g., wp-load.php, wp-settings.php).
• Sudden drops in file counts under wp-content/uploads or the plugins directory.

Retain logs for at least 90 days where possible to support forensic analysis.

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

1. Isolate the environment: Place the site in maintenance mode or take it offline to prevent further damage.
2. Preserve evidence: Snapshot the server and download access, error and WordPress logs. Avoid modifying logs until snapshots are complete.
3. Identify scope: Determine which files were deleted, which accounts performed actions and whether backups exist.
4. Restore: Restore from a verified clean backup. Validate integrity post-restore and avoid restoring contaminated backups.
5. Clean up and harden: Remove the vulnerable plugin or ensure virtual patching is enforced. Harden permissions and monitoring.
6. Rotate credentials: If compromise is suspected beyond deletion, rotate DB passwords, API keys and salts.
7. Forensic review: Engage professional incident response resources if high-value data or critical systems were impacted.
8. Post-incident communication: Notify stakeholders and customers as required by policy or regulation with factual, transparent messaging.
9. Learn and update: Update playbooks and implement the remediation steps above.

Frequently asked questions (FAQ)

Q: Is a Subscriber able to delete any file on the server?

A: In vulnerable installations, yes — the bug can allow deletion of files reachable by the PHP process, depending on how the plugin constructs file paths and on server file permissions. The precise scope depends on server configuration and plugin path handling.

Q: Will disabling the plugin immediately stop the attack?

A: Deactivating or removing the plugin will prevent further exploitation through that plugin’s endpoints. If you cannot access WP Admin, rename the plugin folder on disk to force deactivation.

Q: Could backups be deleted as well?

A: If backups are stored on the same writable filesystem and are accessible to the webserver user, they could be targeted. Prefer off-server or immutable backups.

Q: Should I wait for an official patch?

A: Do not wait if the plugin is active and you cannot confirm a pending patch. Apply mitigations immediately: disable the plugin, deploy edge/host-level blocking, restrict account creation and restore from safe backups as needed.

Guidance for hosting providers and agencies

• Identify customers using the affected plugin and notify them immediately with clear remediation steps.
• Roll out WAF or edge rules at the network level to protect customers until patches are available.
• Offer migration or removal assistance for clients who cannot act quickly.
• Monitor for correlated attack patterns across your hosting network.

Recommendations checklist (quick reference)

• Take a full server snapshot and collect logs.
• Deactivate or remove the vulnerable plugin immediately.
• If removal is not possible, deploy edge/host 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 plan follow-up hardening.

Closing thoughts

This vulnerability demonstrates the danger of pairing file-system modifying actions with weak input validation and permissive authorization. Plugins extend WordPress functionality but can also introduce significant risk if destructive operations are accessible to low-privileged accounts. While awaiting an official vendor update, implement the protective steps above immediately.

If you need assistance implementing mitigations — from applying WAF/edge rules to incident response and recovery — engage experienced security professionals or your hosting provider. Prioritise containment, preservation of evidence and recovery from verified backups.

Stay vigilant, monitor logs closely, and treat this advisory as high priority.

— Hong Kong Security Research Team