Overview of the vulnerability

On 23 December 2025 a public disclosure identified an arbitrary file deletion vulnerability affecting the WooMulti WordPress plugin in versions ≤ 1.7 (CVE-2025-12835). The root cause is broken access control around a file deletion endpoint: authenticated users with the Subscriber role may invoke a plugin action that deletes files on the filesystem without proper capability checks, nonces, or path canonicalization. Because only Subscriber privileges are required, any user with a basic account on a website (including accounts created by self-registration or compromised low-privilege accounts) can exploit this bug.

Technical highlights

• Affected plugin: WooMulti
• Vulnerable versions: ≤ 1.7
• CVE: CVE-2025-12835
• Required privilege: Subscriber (low privilege)
• Classification: Arbitrary file deletion / Broken Access Control
• CVSS (as published): 7.7 (High)
• Official fix: None at time of publication (deferred or pending vendor patch)

This combination — a vulnerability that requires only a Subscriber account and performs file system deletion — makes this a high-priority issue. Attackers can exploit it to cause site outages, delete plugins/themes/core files, or prepare the ground for further compromise.

Why this is dangerous (impact analysis)

Arbitrary file deletion is deceptively destructive. Even if remote code execution is not immediately achieved, deleting critical files can:

• Break site rendering and functionality (missing plugin/theme files or corrupted assets).
• Remove core WordPress files that prevent the site from bootstrapping properly, leading to downtime.
• Remove backup and log files, limiting incident response and recovery options.
• Disable security controls (delete security plugin files) and make follow-on attacks easier.
• Combine with other misconfigurations to escalate privileges or achieve persistence.

Because Subscriber accounts are commonly allowed for user-generated content and self-registration, attackers do not need privileged credentials. A low-cost, automated campaign could register accounts and exercise the delete endpoint across many sites.

Operational consequences

• Ecommerce sites can suffer transaction loss and reputation damage.
• Sites may be offline for hours or days while restoring and investigating.
• Hosts and managed WordPress providers may need to isolate affected sites to prevent lateral movement.

How an attacker could abuse it (attack flow)

Typical abuse path:

1. Create or compromise a Subscriber account on the target site (many sites allow registration).
2. Identify the vulnerable action or AJAX endpoint exposed by the plugin (often visible in page source or network logs).
3. Craft a request that invokes the deletion action, providing a path parameter that points to a target file on the server (e.g., /wp-content/plugins/some-plugin/file.php 或 ../wp-config.php).
4. Send the malicious request repeatedly or target multiple files or directories.
5. Observe the site’s behavior; if files are deleted, escalate or cause denial of service.

Because the endpoint lacks proper capability checks and path sanitization, path traversal or absolute path usage may be possible. The lack of nonce or CSRF protection further simplifies automation.

How to detect active exploitation

Assume immediate detection scanning is essential. Look for the following indicators:

HTTP and application-level signs

• Unusual POST requests to plugin endpoints, especially with parameters like file, path, delete, action=..., ，或类似。.
• POST/GET requests from accounts with Subscriber role to endpoints that normally require higher privileges.
• Spike in requests to plugin PHP files under /wp-content/plugins/woomulti/ or other plugin directories.
• Failed requests returning 200 OK but with missing file results afterward.

Server and filesystem signals

• Sudden disappearance of PHP files in plugins or themes directories.
• Missing images, assets, or files under /wp-content/uploads that previously existed.
• Files modified or deleted near the same timestamps as suspicious HTTP requests.
• Unexpected errors in PHP/FPM or Apache/nginx logs referring to missing includes or require_once failures.

WP and host audit checks

• 检查 wp_options for unexpected changes.
• Check for missing scheduled tasks (cron) or orphaned processes.
• Use file integrity tools (tripwire, AIDE, or checksum baselines) to detect tampering.

Practical detection commands (examples)

Find recently modified or deleted PHP files (by comparing to backups or using timestamps):

inotifywait -m -r -e delete,modify /var/www/html/wp-content 2>/dev/null

find /var/www/html/wp-content -name '*.php' -printf "%T@ %p
" | sort -n | tail -n 50

Check web server logs for suspicious patterns:

grep -E "woomulti|some-plugin-endpoint|action=delete" /var/log/apache2/access.log

Step-by-step immediate mitigations for WordPress site owners

If your site uses WooMulti (≤1.7), act immediately. These actions are ordered by speed and impact.

1) Deactivate or remove the plugin (fastest, most reliable)

WP-Admin: Plugins → Deactivate WooMulti

wp plugin deactivate woomulti --allow-root

or uninstall:

wp plugin uninstall woomulti --allow-root

Rationale: Removing the vulnerable code from the execution path is the most reliable short-term mitigation.

2) Block the plugin’s entry points at the web server level

If the plugin exposes a specific PHP file or AJAX action, block access to it via .htaccess (Apache) or nginx rules. See the next section for sample rules.

3) Deploy WAF or edge rules (generic guidance)

Use available Web Application Firewall rules (self-managed or host-provided) to block malicious patterns: block POST requests that contain suspicious parameters, or requests targeting the plugin folder. If you operate your own WAF appliance, deploy a custom rule immediately. If using host-managed rules, ask for urgent deployment.

4) Restrict user registration and Subscriber activity

• Disable public user registration temporarily: Settings → General → Membership.
• Audit and remove suspicious Subscriber accounts:

wp user list --role=subscriber --field=user_login,user_email
wp user delete username --reassign=admin

Force password resets for accounts with suspicious activity.

5) Harden file permissions

Ensure the webserver user cannot arbitrarily delete files outside intended directories. Adapt the webserver user as needed:

chown -R www-data:www-data /var/www/html
find /var/www/html -type f -exec chmod 644 {} \;
find /var/www/html -type d -exec chmod 755 {} \;
chmod 440 /var/www/html/wp-config.php

6) Isolate and investigate

• Put the site into maintenance mode to reduce attack surface while investigating.
• Take a filesystem snapshot or backup before making changes so you can analyze deleted files.
• If active exploitation is detected, isolate the host from other servers or networks to prevent lateral movement.

7) Backups and restore plan

• Restore missing files from a trusted, recent backup if necessary.
• Do not restore from backups created after compromise timestamps — choose a pre-incident snapshot.

Suggested temporary server-level blocks (Apache / nginx)

If you cannot remove the plugin immediately, server-level denial of access can help. Replace woomulti with the actual plugin path if different.

Apache (.htaccess) examples

Deny direct access to specific plugin PHP files:

<FilesMatch "^(woomulti|some-plugin-file)\.php$">
    Require all denied
</FilesMatch>

Deny POST requests to files in the plugin folder:

<Directory "/var/www/html/wp-content/plugins/woomulti/">
  <LimitExcept GET HEAD>
    Require all denied
  </LimitExcept>
</Directory>

nginx examples

Return 403 for non-idempotent requests to the plugin directory (add to server block):

location ~* /wp-content/plugins/woomulti/ {
    if ($request_method !~ ^(GET|HEAD)$) {
        return 403;
    }
}

Block requests containing suspicious query parameters:

if ($arg_action = "delete_file") {
    return 403;
}

Important: Test server rules in staging where possible. Misconfigured rules can break frontend behavior.

Developer guidance: fix patterns and safe deletion implementation

If you are a plugin or site developer applying a patch, follow these secure design principles to eliminate broken access control and unsafe file operations.

1) Enforce proper capability checks

Do not rely on role names alone; use capability checks appropriate for the action. For file deletions that affect site integrity, require a high-privilege capability such as manage_options or a custom capability mapped to administrators.

if ( ! current_user_can( 'manage_options' ) ) {
    wp_send_json_error( 'Insufficient permissions', 403 );
}

2) Use nonces for every state-changing action

check_ajax_referer( 'woomulti_delete_file', 'security' );

3) Sanitize and canonicalize file paths; disallow traversal

Resolve the absolute path and confirm it resides inside an allowed directory (e.g., plugin upload folder):

$base_dir = WP_CONTENT_DIR . '/uploads/woomulti/';
$file = isset($_POST['file']) ? wp_unslash( $_POST['file'] ) : '';
$file_path = realpath( $base_dir . $file );

if ( $file_path === false || strpos( $file_path, $base_dir ) !== 0 ) {
    wp_send_json_error( 'Invalid file', 400 );
}

Do not accept absolute paths or patterns containing ../. Use realpath() to validate.

4) Use the WordPress Filesystem API

global $wp_filesystem;
if ( ! function_exists( 'WP_Filesystem' ) ) {
    require_once ABSPATH . 'wp-admin/includes/file.php';
}
WP_Filesystem();

if ( $wp_filesystem->exists( $file_path ) ) {
    $result = $wp_filesystem->delete( $file_path, false, true );
}

5) Log every deletion attempt

Record who performed the action, request IP, timestamp, and file target for forensic analysis.

6) Fail safe: prefer “deny by default”

If any check fails or cannot be confirmed, deny the deletion request.

7) Least privilege for file operations

Limit file operations to a small, dedicated directory (e.g., plugin-managed uploads) and ensure other directories are not writable by web processes.

8) Code review and fuzz testing

Conduct a security code review and run automated checks on file handling and capability logic. Fuzz inputs to ensure there are no bypasses.

Post-incident recovery and hardening

If your site was impacted, follow this incident response checklist.

1. Preserve evidence

Take filesystem snapshots and export server logs. Do not overwrite logs.

2. Assess scope

Which files were deleted? Which user accounts were used? Was there evidence of lateral movement?

3. Restore from trusted backups

Restore missing files from a backup taken prior to the compromise. Validate checksums.

4. Reset and rotate credentials

Rotate admin and hosting control panel passwords, SSH keys, and API tokens if relevant.

5. Rebuild or update affected components

Replace vulnerable plugin with a patched release when available. If a fix is not immediately available, keep the plugin deactivated or apply virtual patching at the edge or server layer.

6. Re-scan for malware

Run a comprehensive malware scan and integrity check. Attackers commonly plant backdoors in remaining files.

7. Harden configuration

define( 'DISALLOW_FILE_EDIT', true );

Enforce secure file permissions and disable PHP execution in upload directories via .htaccess or server config.

8. Monitor

Increase logging and monitoring for a period after recovery. Enable alerts for file deletions and changes in plugin directories.

9. Communicate if necessary

Be prepared to notify customers or stakeholders if sensitive data or services were affected.

Appendix: useful WP-CLI and shell commands

WP-CLI quick checks

wp user list --role=subscriber --format=csv
wp plugin deactivate woomulti --allow-root
find wp-content/plugins/woomulti -type f -printf "%TY-%Tm-%Td %TT %p
" | sort -r | head -n 50

File system snapshots and backups

rsync -aAXv /var/www/html /backup/$(date +%F)/site-snapshot/

Inotify monitoring for real-time deletions (install inotify-tools)

inotifywait -m -r -e delete,delete_self,modify /var/www/html/wp-content/uploads /var/www/html/wp-content/plugins/woomulti

Search web server logs for suspicious plugin hits

grep -i "woomulti" /var/log/apache2/access.log* | tail -n 200
grep -i "woomulti" /var/log/nginx/access.log* | tail -n 200

Final notes and recommended timeline

1. Immediate (0–2 hours): Deactivate the plugin or enforce server-level blocks. Disable public registration if not needed.
2. Short term (2–24 hours): Investigate logs, take snapshots, and restore missing critical files from trusted backups.
3. Medium term (24–72 hours): Apply developer fixes (capability checks, nonces, path canonicalization) or reinstall patched plugin when available.
4. Long term: Harden site and hosting configuration, implement file integrity monitoring, and maintain an incident response plan to reduce exposure time for future zero-day issues.

If you manage many WordPress sites or host customers, enable automated edge protections and centralized monitoring to reduce the window of exposure between disclosure and vendor fixes. If you need immediate assistance configuring mitigations or server rules for this vulnerability, engage your internal security team or an experienced security consultant.