Urgent: Arbitrary File Deletion in “WooCommerce Support Ticket System” Plugin (< 18.5) — What WordPress Site Owners Must Do Right Now

On 20 March 2026 a public advisory disclosed an unauthenticated arbitrary file deletion vulnerability in the WooCommerce Support Ticket System plugin (versions prior to 18.5). Tracked as CVE-2026-32522 (CVSS 8.6), this issue allows remote attackers to delete files on the web server without authentication. From my experience working with Hong Kong enterprises and SME hosting providers, this is a high‑urgency problem — automated scanners will find vulnerable sites quickly and mass-exploit campaigns are likely.

Below I outline what the vulnerability is, realistic attack scenarios, how to detect exploitation, and practical mitigations you can apply immediately — both short-term containment and longer-term hardening. This guidance is written from a Hong Kong security expert perspective and intentionally omits exploit code or step‑by‑step attacker instructions.

High-level summary (TL;DR)

• Vulnerability: Arbitrary file deletion (unauthenticated).
• Affected versions: plugin versions < 18.5.
• Patched version: 18.5 (upgrade immediately).
• Risk: High (CVSS 8.6). Attackers can delete core files, plugin/theme assets, uploads, or other web‑accessible files — potentially taking sites offline or removing forensic trails.
• Immediate actions:
  1. Update the plugin to 18.5 or later on all sites.
  2. If update not possible immediately, disable the plugin until patched.
  3. Apply WAF-based virtual patching or server-level access controls to block exploit attempts (rule strategies are below).
  4. Inspect logs and backups; prepare incident response if you find suspicious deletions.
• If your site is managed by an agency or host, escalate to them now.

What “arbitrary file deletion” means in this context

Arbitrary file deletion means the application can be induced to delete files chosen by the attacker. In WordPress plugins this typically happens when:

• A server-side delete function (e.g., unlink()) accepts a filename/path from HTTP input.
• The delete action has no authentication or capability checks (unauthenticated endpoint).
• Input is not validated or canonicalised, permitting directory traversal or absolute paths.
• The code does not enforce that the target is inside an approved directory.

Because this vulnerability is unauthenticated, the window for mass exploitation is large — attackers do not need valid WordPress credentials.

Likely root cause (concise technical view)

Based on the advisory characteristics, the root cause is almost certainly a public endpoint or AJAX action that performs file deletion using a filename/path parameter supplied via HTTP (GET/POST). Typical weaknesses:

• An action exposed via admin-ajax.php or a custom public endpoint that calls a delete routine.
• Parameters like file, filename, path or an encoded identifier are accepted from the client.
• No authentication/authorization checks and no path canonicalisation to ensure the file is within an allowed directory.
• No whitelist of allowed targets or allowed extensions.

What attackers can do (realistic scenarios)

• Delete wp-config.php or other core PHP files to render the site inoperable.
• Remove plugin or theme files to disable security controls or remove functionality.
• Erase logs or forensic artifacts to hinder detection and investigation.
• Wipe media/uploads or backups stored in the webroot, causing data loss.
• Combine deletion with later backdoor uploads, ransomware or extortion attempts.

Automated scanning at scale makes this sort of unauthenticated deletion especially dangerous — attackers will scan for plugin footprints and send deletion requests in bulk.

Who is at risk

Any WordPress site with the WooCommerce Support Ticket System plugin version < 18.5 is at risk. This includes agency-managed sites and multi-site hosting environments. Sites with limited or no off‑site backups are particularly exposed.

Immediate actions (first 60–120 minutes)

1. Update the plugin to 18.5 or later (recommended). This is the permanent fix; prioritise production and staging environments.
2. If you cannot update immediately: deactivate the plugin. From wp-admin or via WP‑CLI: wp plugin deactivate <plugin-slug>.
3. Apply WAF/virtual patching or server-level restrictions. Block access to vulnerable endpoints and patterns (details in the WAF section below).
4. Take a fresh full backup now. Files + database snapshot before any remediation step is essential for investigation and recovery.
5. Search logs for suspicious activity. Check web server, WAF and application logs for requests targeting the plugin, admin-ajax.php actions, or parameters with directory traversal tokens.
6. Contact your hosting provider or developer. If you do not control the environment, escalate immediately and provide the CVE identifier.

Detection: what to look for in logs and telemetry

Search Apache/Nginx/Cloudfront/WAF logs for patterns such as:

• Requests to plugin paths:
  • /wp-content/plugins/woocommerce-support-ticket-system/*
  • /wp-content/plugins/<plugin-slug>/ajax.php or endpoints containing “ticket”, “delete”, “attachment”
• Requests to admin-ajax.php with suspicious action names: admin-ajax.php?action=...
• Parameters with traversal tokens: %2e%2e%2f, ../, or absolute paths like /etc/passwd or /home/.../wp-config.php
• References to sensitive filenames: wp-config.php, wp-content/uploads, plugin/theme filenames
• Spikes in 200/204 responses from deletion-related endpoints or bursts of 4xx/5xx responses from the same IP range

Example quick grep ideas (adapt for your environment):

grep "admin-ajax.php" access.log | grep "woocommerce-support-ticket-system"
grep -E "(%2e%2e%2f|\.\./|wp-config|wp-content/uploads|/etc/passwd)" access.log

If you find activity in the last 24–72 hours, treat the site as potentially exploited and escalate to incident response.

Recommended WAF / virtual-patching strategies (apply now)

If you operate or have access to a web application firewall (WAF) or server access controls, implement layered rules now:

1. Block access to the plugin’s public endpoints. Deny GET/POST requests to /wp-content/plugins/woocommerce-support-ticket-system/* for unauthenticated clients; allow only from known admin IPs where practical.
2. Block unauthenticated deletion actions. Deny requests to admin-ajax.php or REST endpoints where parameters or action values indicate a deletion routine unless the request is authenticated and contains a valid nonce.
3. Prevent directory traversal / suspicious filename patterns. Block any request containing ../, %2e%2e%2f or absolute path patterns, and block references to sensitive files like wp-config.php or /.env.
4. Rate-limit and fingerprint request patterns. Apply per-IP rate limits on deletion-capable endpoints and flag repeated delete attempts.
5. Positive-wildcard parameter validation. Where possible, allow only numeric IDs (attachment IDs) for deletion APIs and block non-numeric or unusually long values that suggest path injection.
6. Logging and alerting. Log blocked attempts with full context and alert on repeated triggers.

Example abstract rule logic:

• Rule A: If request path matches plugin-delete-endpoint AND (no valid auth cookie OR missing nonce) → BLOCK & LOG.
• Rule B: If request body/query contains ../ or %2e%2e%2f OR references wp-config.php → BLOCK & LOG.
• Rule C: Rate-limit requests to N requests/minute per IP; if exceeded → BLOCK & ALERT.

Test rules in monitoring mode first to avoid false positives that might block legitimate admin activity, then enable blocking for confirmed malicious patterns.

Example WAF considerations for WordPress environments

• Protect admin-ajax.php: Many plugins misuse this endpoint and do not enforce permissions. Block or throttle POST requests where the action parameter matches suspect delete actions.
• Protect plugin folders: Use WAF plus server config rules to deny direct access to plugin PHP entry points.
• Block direct file deletion APIs from unauthenticated sources: deny deletion verbs or endpoints unless the request is proven authenticated and authorised.

How to harden your server and WordPress environment (practical steps)

1. File system hardening. Restrict filesystem permissions. Make wp-config.php owner-only writable where possible (e.g., chmod 400/440). Limit recursive write access to wp-content; only allow the webserver to write where necessary (uploads).
2. Principle of least privilege. Run PHP processes with a user that has access only to required directories. Use OS-level separation for multiple sites.
3. Web server rules. Deny direct execution of PHP in uploads and other non-executable directories. Restrict access to known sensitive files via server config.
4. WordPress best practices. Keep core, themes and plugins updated. Remove unused plugins. Enforce two‑factor authentication for admin accounts.
5. Backups and retention. Maintain off‑server, versioned backups. Test restores regularly and keep immutable copies where possible.

If you suspect an exploit — incident response and recovery

1. Isolate the site. Put the site in maintenance mode or restrict access while investigating.
2. Preserve evidence. Snapshot files and database before remediation. Collect web server, application and WAF logs for the incident window.
3. Check for missing/modified files. Compare the current file tree to a known-good backup or checksum manifest. Pay attention to wp-config.php, plugin/theme files and uploads.
4. Restore from a clean backup. If critical files are missing, restore from a backup known to be clean. Do not restore backups that may already be compromised.
5. Rotate credentials. Change WordPress admin passwords, database credentials, API keys and any secrets that could be abused.
6. Scan for backdoors. Use reputable malware scanners and manual review to search for web shells or modified PHP files. Replace infected files from trusted sources where possible.
7. Reapply updates and hardening. Update the vulnerable plugin, re-enable protections, and continue strict monitoring.
8. Notify stakeholders. Inform users, hosts or customers according to your notification policy and legal requirements.

Monitoring and ongoing detection after remediation

• Keep defensive rules in monitoring/alerting mode even after patching.
• Alert on file system changes in wp-content, uploads and webroot.
• Implement file integrity monitoring (FIM) to detect sudden deletions or unauthorized changes.
• Watch for repeated attempts to access blocked endpoints; attackers will often revisit targets.

If you’re a developer: avoid these common mistakes (secure coding checklist)

• Never delete files directly based on user-supplied input without canonicalisation and whitelist checks.
• Validate and canonicalise paths server-side; ensure targets are within an allowed directory.
• Require authentication and capability checks for destructive actions.
• Use nonces or token-based verification for state-changing AJAX endpoints and verify them server-side.
• Prefer numeric IDs resolved server-side to file paths rather than accepting filenames from clients.
• Log deletion actions with request context for auditing.

Virtual patching and incident support — what to expect

If you engage a security provider or operate your own edge controls, expect the following practical responses:

• Rapid creation and deployment of targeted WAF rules to block known exploit vectors (endpoint patterns, traversal tokens, suspicious parameters).
• Behavioural protections such as rate limiting and request fingerprinting to slow automated campaigns.
• File integrity monitoring and assistance identifying missing or modified files.
• Guided incident response playbooks: evidence collection, containment, clean restore and hardening steps.

If you don’t have managed edge protections in front of your site, apply server-level restrictions and follow the immediate actions above — vulnerability exploitation can happen quickly at scale.

Practical non-WAF mitigations you can apply if you can’t update now

• Deactivate the plugin. The safest short-term measure.
• Restrict access to plugin files. Add server rules to deny public access to plugin PHP entry points; allow only known admin IPs where feasible.
• Harden file permissions. Make sensitive files read-only where practical, after testing to ensure you do not break needed functionality.
• Use server-side allowlists. If the plugin exposes hooks or filters, add custom code to enforce strict deletion checks (e.g., only allow logged-in users with a capability).

Long-term programmatic recommendations for hosts & site operators

• Maintain rapid edge rule deployment capability to protect customers during zero-day windows.
• Offer well-tested auto-updates for plugins with security fixes and canary testing to reduce risk.
• Provide per-site file snapshots and fast restore workflows that avoid full server restores.
• Educate customers on plugin hygiene: remove unused plugins, prefer actively maintained plugins, and test updates in staging.

Detection playbook: queries and alerts you can implement today

• Alert on requests to /wp-content/plugins/woocommerce-support-ticket-system/* that result in HTTP 200 responses for deletion actions.
• Alert on admin-ajax.php POST requests containing suspicious action values or body parameters tied to deletion.
• Alert on requests that contain ../, %2e%2e%2f, absolute paths, or sensitive filenames.
• Schedule daily checks comparing the current file manifest to the previous manifest and alert on unexpected deletions.

Frequently Asked Questions

Q: If my site was hit but the attacker only deleted plugin files, will WordPress recover?

A: Often plugin files can be reinstalled and settings restored from backups, but if critical files (wp-config.php) or uploads were deleted — or backdoors were present — recovery can be more complex. Always run a full integrity scan after restoration.

Q: Can file system permissions alone prevent this?

A: Proper permissions reduce risk but are not a silver bullet. A vulnerable plugin running as the webserver user can still delete files that user can write. Defense‑in‑depth (updates + WAF + backups + permissions) is the correct approach.

Q: Will simply turning off access to admin-ajax.php be enough?

A: Not always. Many plugins depend on admin-ajax.php for legitimate functionality. Blocking it entirely can break features. Prefer targeted rules that block malicious patterns while preserving legitimate traffic.

Final checklist — immediate to-do list for every WordPress site owner

1. Identify all sites using the WooCommerce Support Ticket System plugin.
2. Update each installation to version 18.5 or later immediately.
3. If you cannot update immediately, deactivate the plugin.
4. Apply WAF rules or server-level restrictions to block deletion endpoints and traversal attempts.
5. Take a full backup (files + DB) now and store off‑server.
6. Search logs for suspicious delete attempts and indicators described above.
7. Run file integrity and malware scans; look for backdoors if suspicious activity is found.
8. Harden file permissions and restrict access to sensitive files.
9. Set up ongoing monitoring and alerts for the patterns above.

Closing thoughts

Arbitrary file deletion vulnerabilities attack site integrity and availability directly. The required response is immediate: patch to 18.5 now, or isolate and virtual‑patch the vulnerable endpoint until you can update. From a Hong Kong security practitioner perspective, speed and layered controls are essential — updates, edge protections, strict file permissions, reliable off‑site backups and active monitoring together reduce the chance of severe impact.

If you need professional incident response or help crafting targeted WAF rules and detection queries, engage a trusted security consultant or your hosting security team immediately.