Critical Arbitrary File Deletion in WooCommerce Support

Plugin Name	WooCommerce Support Ticket System
Type of Vulnerability	Arbitrary File Deletion
CVE Number	CVE-2026-32522
Urgency	High
CVE Publish Date	2026-03-22
Source URL	CVE-2026-32522

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 was published for an unauthenticated arbitrary file deletion vulnerability affecting the WooCommerce Support Ticket System plugin (versions prior to 18.5). The issue is tracked as CVE-2026-32522 and carries a high severity rating (CVSS 8.6). The vulnerability allows an attacker to delete files on the web server without authentication — a capability attackers love because it can break sites, remove forensic trails, or clear log files to hide subsequent activity.

If you run WordPress and use this plugin (or manage sites for customers), treat this as time-critical. This post explains, from a WordPress security and web application firewall (WAF) vendor perspective, what the vulnerability is, how it can be abused at scale, how to detect possible exploitation, and practical mitigation — including immediate virtual-patching and long-term hardening steps you can apply today.

Note: this post is written from the WP‑Firewall security team perspective with actionable, expert guidance. It does not include exploit code or step-by-step instructions that would enable attackers.

---

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 evidence.
• Immediate recommended 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 to block exploit attempts (we provide recommended rule strategies 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” refers to a vulnerability where an attacker can cause the application to delete files chosen by the attacker. In WordPress plugins this commonly happens when:

• A plugin exposes a server-side file deletion function (e.g., unlink(), rm, filesystem delete) that accepts a user-provided filename/path.
• The function lacks proper access control (no authentication, authorization, or capability checks).
• The input is insufficiently validated or sanitised, allowing directory traversal or absolute paths.
• The plugin fails to check whether the target file is within an expected directory (missing canonicalisation checks).

Because the vulnerability in this advisory is described as “unauthenticated”, an attacker does not need valid WordPress credentials to trigger the deletion — the scope for mass-exploitation is high.

---

Likely root cause (technical, but concise)

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). The server-side code probably:

• Exposes an action (e.g., via admin-ajax.php or a custom endpoint) that calls a delete routine.
• Accepts a parameter like file, filename, path, or attachment_id (or even an encoded value).
• Does not verify the user is authenticated and/or authorized.
• Does not normalise the path to ensure it’s under a permitted directory (e.g., plugin upload folder).
• Does not enforce a whitelist of allowed filenames or extensions.

This combination gives attackers the ability to delete arbitrary files, often via directory traversal strings or absolute paths.

---

What attackers can do (realistic attack scenarios)

• Delete core WordPress files (e.g., wp-config.php, core PHP files) to break the site, causing downtime.
• Remove plugin or theme files to disable security controls or backdoors.
• Erase logs or forensic artifacts (e.g., access/error logs, plugin logs), making detection harder.
• Wipe media/uploads (images, invoices, backups stored in web root) — causing data loss.
• Churn site files to prepare for further attacks (e.g., disable defenses, then upload backdoor).
• Combine deletion with ransomware or extortion tactics: break the site and ask for payment.

Because the vulnerability is unauthenticated and easy to automate, attackers often scan the Web for vulnerable plugin footprints and send deletion requests in bulk.

---

Who is at risk

• Any WordPress site with the WooCommerce Support Ticket System plugin version lower than 18.5.
• Agencies or hosts managing multiple WordPress installs where the plugin is used.
• Sites with insufficient backups or low-privilege separation between file storage and the web server.

Even a low-traffic site can be targeted — attackers don’t care about traffic, they look for vulnerable software.

---

Immediate actions (first 60–120 minutes)

1. Update the plugin to 18.5 or later (recommended)
   This is the correct and permanent fix. Apply updates to production and staging sites as soon as possible.
2. If you cannot update immediately: disable the plugin
   Go to the WordPress Plugins admin and deactivate the plugin. If you use WP‑CLI:
   • wp plugin deactivate <plugin-slug>
3. Enable WAF/virtual patching to stop exploit attempts
   If you have a WAF (managed or plugin-level), activate rules that block requests to the vulnerable endpoints and suspicious payloads (we provide rule strategies below).
4. Take a fresh backup now
   Export a full backup (files + DB) before you do anything else. If the site shows signs of compromise, this snapshot is critical for investigation and recovery.
5. Search logs for suspicious activity
   Search access logs for POST/GET requests to plugin-specific endpoints, admin-ajax.php actions, or parameters that look like delete commands. If you see such requests from unknown IPs, treat as potential exploitation and escalate.
6. Contact your hosting provider or developer if you don’t control the environment. Share the CVE and ask them to assist with containment and patching.

---

Detection: what to look for in logs and telemetry

Set up searches in Apache/Nginx/Cloudfront logs, WAF logs, and WordPress logs for the following patterns (examples are fleshed out conceptually — adapt to your logs):

• HTTP requests to plugin paths:
  • /wp-content/plugins/woocommerce-support-ticket-system/*
  • /wp-content/plugins/<plugin-slug>/ajax.php or endpoints with obvious “ticket”, “delete”, “attachment” terms
• HTTP requests to admin-ajax.php with suspicious action names:
  • admin-ajax.php?action=… (look for actions that hint at deleting attachments, tickets or files)
• Parameters containing path traversal tokens:
  • %2e%2e%2f or ../ or absolute file paths (e.g. /etc/passwd or /home/.../wp-config.php) in query/body
• Requests that attempt to delete typical WordPress files:
  • Requests with parameters containing wp-config.php, wp-config, wp-content/uploads, plugin/theme filenames
• Sudden increase in 200/204 responses to deletion-related endpoints
• Unexpected spikes in 4xx/5xx in a short timeframe, particularly from the same IPs

Example (log query idea — adapt to your platform):

• Search for admin-ajax.php and the plugin slug together:
  • grep "admin-ajax.php" access.log | grep "woocommerce-support-ticket-system"
• Search for suspicious parameters:
  • grep -E "(%2e%2e%2f|\.\./|wp-config|wp-content/uploads|/etc/passwd)" access.log

If you find hits in the last 24–72 hours, treat the site as possibly exploited and follow the incident response steps below.

---

Recommended WAF / virtual-patching strategies (apply now)

If you manage a WP‑Firewall WAF or any other web application firewall, implement layered rules to mitigate exploitation until the plugin is upgraded:

1. Block access to the plugin’s public endpoints
   • If the plugin exposes a specific PHP or endpoint path, block direct HTTP access to that path for unauthenticated clients.
   • For example, block GET/POST requests to /wp-content/plugins/woocommerce-support-ticket-system/* except from known admin IPs.
2. Block unauthenticated deletion actions
   • Deny requests to admin-ajax.php or REST endpoints that include parameters or action values used by the plugin to perform deletions, unless the request is authenticated (e.g., has a valid WP nonce or cookie).
3. Prevent directory traversal / suspicious filename patterns
   • Block requests where any filename parameter contains ../, %2e%2e%2f, or absolute path patterns.
   • Block attempts to reference sensitive filenames: wp-config.php, .htaccess, .env.
4. Rate-limit and fingerprint the request patterns
   • Enforce rate limits on endpoints that delete files to slow down automated mass exploitation.
   • Use behavioral heuristics: multiple delete attempts in short intervals, many different filenames, same user-agent across different sites.
5. Positive-wildcard approach for parameter validation
   • If possible, only allow deletion parameters that match a secure whitelist (e.g., numeric attachment IDs). Block non-numeric or unusually long values that indicate path usage.
6. Logging and alerting
   • Log blocked attempts with full request context and alert on repeated triggers.

Example conceptual WAF rule logic (abstract and safe):

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

Important: When crafting rules, test in monitoring-only mode first to avoid false positives that could lock out admins. Then move to blocking for confirmed malicious patterns.

---

Example WAF considerations for WordPress environments

• Protect admin-ajax.php: Many plugins misuse admin-ajax.php for AJAX actions and do not enforce permissions. Block or throttle POST requests to admin-ajax.php where the action parameter matches the vulnerable plugin’s actions.
• Protect plugin folders: Use WAF rules plus server-level controls to prevent direct access to plugin-specific PHP entry points.
• Block direct file deletion APIs from unauthenticated sources: Generic rule: deny HTTP verbs and endpoints that attempt to delete files unless the request is authenticated and authorised.

---

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

1. File system hardening
   • Limit filesystem permissions. Critical files (wp-config.php, .htaccess) should be owner-only writable and not writable by the webserver user when possible (e.g., chmod 400/440 for wp-config.php).
   • Avoid granting the web server user recursive write access to the entire wp-content directory. Narrow write permissions to the uploads folder only where necessary.
   • Store backups and archives outside of the webroot.
2. Principle of least privilege
   • Run PHP processes with a user that only has access to required directories.
   • Use OS-level separation between user accounts for sites when hosting multiple sites.
3. Web server rules
   • Use .htaccess or server config rules to deny direct execution of PHP in certain directories (e.g., uploads) and deny access to known sensitive files.
   • If the plugin exposes a file that must not be public, restrict it via server configurations.
4. WordPress best practices
   • Keep WordPress core, themes, and plugins updated.
   • Minimise plugin footprint: remove unused plugins and keep plugins only if actively maintained.
   • Enforce two-factor authentication for administrative accounts.
5. Backups and retention
   • Maintain regular, automated backups stored off-server and immutable copies where possible.
   • Test restores regularly.

---

If you suspect an exploit — incident response and recovery

1. Isolate the site
   • If possible, put the site in maintenance mode or block public traffic while you investigate.
2. Preserve evidence
   • Snapshot the server (files and DB) before remediating further.
   • Collect web server and application logs, WAF logs, and access logs for the timeframe of the suspected event.
3. Check for missing/modified files
   • Compare current file list to a known-good backup or checksum manifest. Pay attention to wp-config.php, plugin/theme files, uploads, and any file with recent modification times.
4. Restore from a clean backup
   • If vital files are missing and you have a clean backup, restore the site to a known-good state. Do not restore backups that may already be compromised.
5. Rotate credentials
   • Change all WordPress administrative passwords, database credentials, API keys, and any other secrets that may have been exposed or used.
6. Scan for backdoors
   • Use a malware scanner to look for PHP backdoors or web shells. Clean or replace infected files.
7. Reapply updates and hardening
   • Update the vulnerable plugin to the patched version, re-enable only after confirmation that no backdoors remain.
   • Reintroduce WAF protections and continue strict monitoring.
8. Notify stakeholders
   • Inform affected users, hosts, or customers per your notification policy and legal requirements.

---

Monitoring and ongoing detection after remediation

• Keep WAF rules in place (or in a monitoring/alerting mode) even after patching.
• Set alerts for:
  • New 404s or 500s during routine site scans.
  • File system changes: unexpected file/modification events in wp-content, uploads, and root.
  • Repeated attempts to access blocked endpoints.
• Implement file integrity monitoring (FIM) to detect sudden deletions or unauthorized changes.

---

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

• Never perform filesystem delete operations directly on user-supplied input without canonicalisation and whitelist checks.
• Validate and canonicalise paths using server-side APIs; ensure the target file is within an allowed directory before deleting.
• Require authentication and verify capability (e.g., current_user_can('delete_posts') or custom capability) for any destructive action.
• Use nonces or token-based verification for state-changing AJAX/endpoints and verify them on the server.
• Avoid exposing generic endpoints that accept arbitrary file names; prefer numeric IDs that the server resolves to a safe file path.
• Log deletions and include the user or request context for auditing; do not suppress important security-relevant logs.

---

How WP‑Firewall helps (virtual patching, monitoring, and recovery assistance)

At WP‑Firewall we treat vulnerabilities like this with a layered approach:

1. Rapid virtual patching
   We create tailored WAF rules that block the specific exploit vectors (suspicious parameters, endpoint access patterns and directory traversal attempts) so sites remain protected until they can be updated. Virtual patches are deployed centrally and can mitigate mass-scan campaigns.
2. Behavioral protections
   Rate limiting, request-fingerprinting and anomaly detection reduce the success of automated exploit attempts. Even if the endpoint exists, abuse patterns are identified and mitigated.
3. File integrity monitoring and remediation guidance
   Our tools can help detect missing files and anomalous file changes and provide step-by-step guidance for recovery or restoration from backup.
4. Incident support
   If you suspect compromise, our support processes and incident playbooks walk you through containment, evidence collection, and clean recovery.

If you don’t have a managed WAF in front of your WordPress site, an unauthenticated vulnerability like this can be exploited quickly by automated scanning tools. Virtual patches provide immediate protection until the code-level fix is installed.

---

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

• Deactivate the plugin: the safest short-term fix is to deactivate the plugin until you can update it.
• Restrict access to plugin files: add server rules denying public access to the plugin’s PHP entry points. For example, deny requests to a specific plugin PHP file unless the request is from a known admin IP. (Caveat: be careful with IP restrictions if admins have dynamic IPs.)
• Harden file permissions: make sensitive files read-only where practical. But test thoroughly since some plugins legitimately require write access.
• Use server-side allowlists: if the plugin offers filters/hooks to override deletion behavior (some plugins do), add custom code to deny deletion requests unless they meet strict checks (e.g., only allow deletion by logged-in users with a capability).

---

Long-term programmatic recommendations for hosts & site operators

• Maintain a runtime WAF or edge security that can deploy rule updates quickly across customer sites.
• Offer auto-update for plugins that have security fixes, ideally with canary testing and rollback.
• Provide per-site file integrity snapshots and quick restoration workflows that don’t require full server restores.
• Educate customers about plugin security hygiene: remove unused plugins, prefer actively maintained plugins, test updates in staging.

---

Detection playbook: queries and alerts you can implement today

Add these detection ideas to your monitoring stack (elk, splunk, cloud logs, hosting logs):

• Alert when any request to /wp-content/plugins/woocommerce-support-ticket-system/* results in a HTTP 200 for a deletion action.
• Alert when admin-ajax.php receives POST requests containing suspicious action values (or body parameters) tied to deletion routines.
• Alert on requests that contain ../, %2e%2e%2f, absolute paths, or sensitive filenames in query or request body.
• Schedule a daily check comparing the current file manifest vs. the last known manifest; alert on any unexpected deletions.

---

Frequently Asked Questions

Q: If my site was hit but the attacker only deleted plugin files, will WordPress recover?
A: If plugin files are deleted, you can usually reinstall the plugin and restore settings from backups. But if critical files (e.g. wp-config.php or custom uploads) are deleted or backdoors were installed prior to deletion, the site could be in a more complex state. Always run a full integrity scan after restoration.

Q: Can file system permissions alone prevent this?
A: Proper permissions reduce risk but are not foolproof. A vulnerable plugin running under the webserver user may still delete files that the webserver user can write to. Defense-in-depth (updates + WAF + backups + permissions) is the right approach.

Q: Will simply turning off access to admin-ajax.php be enough?
A: Not always. Some plugins depend on admin-ajax for legitimate functionality. Blocking admin-ajax entirely can break features. Targeted WAF rules that block only the malicious patterns or endpoints are preferable.

---

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

1. Identify all sites that use 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 virtual patching to block deletion endpoints and directory traversal attempts.
5. Take a full backup (files + DB) now and store off-server.
6. Search logs for suspicious delete attempts and indicators described earlier.
7. Run a file integrity/malware scan and look for backdoors if suspicious activity is found.
8. Harden file permissions, restrict access to sensitive files, and implement logging.
9. Set up ongoing monitoring and alerting for the patterns above.

---

Start protecting your site with WP‑Firewall (Free plan)

Start protecting your site with the WP‑Firewall Basic (Free) plan

If you want immediate protection with an easy onboarding path, WP‑Firewall’s Basic (Free) plan provides essential managed protections that help stop mass-exploitation campaigns like this one while you patch:

• Essential protection: managed firewall, unlimited bandwidth, application-layer WAF.
• Malware scanner and continuous mitigation of OWASP Top 10 risks.
• Rapid virtual-patching to block known exploit vectors until code-level fixes are applied.

Sign up for the free plan and get a managed WAF rule set protecting your WordPress sites immediately:
https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(If you need automated malware removal, whitelist/blacklist controls, or auto virtual-patching across an agency or multiple sites, the paid plans include those capabilities and are priced for agencies and enterprises.)

---

Closing thoughts

Arbitrary file deletion vulnerabilities are one of the more destructive classes of web application bugs because they directly target your site’s integrity and availability. Tackling them requires speed: patch the plugin to 18.5 now, and if you cannot do that immediately apply virtual patches and isolate the vulnerable endpoint.

At WP‑Firewall we recommend a layered approach: code fixes + WAF virtual patches + server hardening + backups + monitoring. This combination prevents attackers from quickly taking advantage of a vulnerability and gives you time to apply permanent remediation.

If you need help implementing WAF rules, scanning sites for indicators of compromise, or running incident response, WP‑Firewall’s team can assist. Protect your sites now, and treat plugin security as a continuous operational concern—not a one-off task.