Urgent Security Alert: Icons Factory plugin (≤ 1.6.12) — Unauthenticated Arbitrary File Deletion (CVE-2025-7778)

TL;DR
A critical vulnerability (CVE-2025-7778) in the WordPress Icons Factory plugin (versions ≤ 1.6.12) permits unauthenticated attackers to invoke a file deletion routine (delete_files()) without authorization checks. CVSS is high (8.6). Consequences include site breakage, data loss and follow-on actions by attackers. If you run this plugin, act immediately: disable or remove the plugin, restore from verified clean backups if needed, and apply virtual patching via your WAF until a vendor fix is available.

Why this matters (short risk summary)

• Vulnerability type: Arbitrary File Deletion — missing authorization checks on a file-delete function.
• Privilege required: None — unauthenticated attackers can trigger the deletion.
• Impact: Attackers can delete files that the web server user can access — plugin/theme files, uploads, cache, and possibly core files if permissions permit.
• Urgency: High — unauthenticated flaws are rapidly scanned and weaponized once public proof-of-concept code circulates.

Technical summary (what the vulnerability is and how it happens)

The plugin exposes a delete_files() routine callable without proper authorization. Secure design expects verification that the caller is authenticated and has a relevant capability (for example, a current_user_can() check combined with nonce validation). In this case, delete_files() processes HTTP-supplied input and performs file removal without enforcing such checks.

Consequences:

• An attacker can craft HTTP requests that delete files accessible by the web process.
• Deleted files can break site functionality, remove media, or alter the site to hide further compromise.
• Depending on hosting and permissions, the blast radius may extend to other sites on shared hosting.

Note: CVE identifier: CVE-2025-7778.

Exploitation scenarios and attacker goals

Typical attacker objectives using this vulnerability:

1. Immediate denial of service — delete core/plugin/theme files to make the site fail.
2. Destroy traces — delete logs or backups to complicate forensic investigation.
3. Prepare for follow-on attacks — remove specific files to enable replacement with web shells or backdoors (if file upload is later possible).
4. Extortion — threaten permanent data removal unless paid.
5. Targeted sabotage — disrupt an organisation by removing content or configurations.

How to quickly check if your site is affected

1. Inventory plugins: In wp-admin → Plugins → Installed Plugins, look for “Icons Factory” and check version — vulnerable versions are ≤ 1.6.12.
2. Look for missing or recently deleted files: Compare the plugin directory to a fresh copy from a trusted source; investigate suspicious timestamps or absent files.
3. Web server logs: Search access and error logs for suspicious POST requests to admin-ajax.php or plugin-specific endpoints. Look for parameters such as delete, remove, file, path or direct file paths.
4. File system checks: Inspect wp-content/uploads, plugin and theme directories for deleted or altered files.
5. Check for unusual user changes: Although deletion does not create users, follow-on activity may add admin accounts — verify users and roles.

If you confirm deletions and cannot explain them, treat the site as potentially compromised and follow the incident response steps below.

Immediate remediation steps (do this now)

1. Place the site into maintenance mode to reduce automated scanning and exploitation.
2. Disable the vulnerable plugin:
   • From wp-admin → Plugins, deactivate Icons Factory.
   • If wp-admin is inaccessible, rename the plugin directory via SFTP/SSH (e.g., wp-content/plugins/icons-factory → icons-factory.disabled).
3. Restore missing files from a known-good backup. If you doubt backup integrity, preserve current evidence and seek professional forensic help.
4. Rotate credentials: reset WordPress admin passwords, database credentials, and any API keys that plugins or themes use.
5. Update everything: update WordPress core, themes and other plugins after ensuring backups are clean. Do not re-enable the plugin until a verified vendor patch is available.
6. If no vendor patch is available yet: apply WAF virtual patching (see the WAF section below) and/or remove the plugin permanently and migrate functionality if necessary.
7. Scan for malware and persistence: look for web shells, unexpected PHP files, cronjobs or scheduled hooks added by attackers.
8. Contact your host for server-level logs and possible snapshot restores.
9. Review and tighten filesystem permissions so the web user cannot delete core files unnecessarily.

If you confirm replacement files, exfiltration, or other indicators of deeper compromise, escalate to a professional incident response team.

Detection: what to look for in logs and file systems

• Access logs: repeated POST requests to admin-ajax.php or plugin endpoints containing file path-like parameters; unusual user agents or empty referers.
• Error logs: PHP warnings/errors about missing includes or require_once failures referencing plugin or core files.
• Filesystem: missing PHP files in plugin/theme folders, deleted or empty files under wp-content/uploads, unexpected modification times.
• Database: unexpected changes in options or new admin users.
• Backups: files present in backups but absent in production.

Indicators of Compromise (IOCs)

• Requests with parameters that reference file paths (../ sequences or absolute paths).
• POST spikes to admin-ajax.php or endpoints under /wp-content/plugins/icons-factory/.
• 500/503 errors and missing include errors in PHP logs immediately following suspicious requests.
• Files present in backups but missing on production systems.

Virtual patching and WAF protection (recommended rules and logic)

While awaiting an official vendor patch, a WAF can mitigate attack attempts. Below are conceptual defence rules and a ModSecurity-style example you can adapt to your WAF.

WAF strategy (conceptual):

• Block unauthenticated requests attempting to call file deletion routines in the plugin.
• Require presence/validation of WordPress nonces for admin-side POSTs where possible.
• Block admin-ajax calls that attempt file operations unless they originate from authenticated sessions with proper capabilities.
• Rate-limit suspicious POSTs and block repeat offenders.

Pseudo-rule logic:

If HTTP method is POST to admin-ajax.php or plugin endpoint AND
  request body contains parameters matching deletion actions (e.g., delete, remove, file, path) AND
  no wordpress_logged_in_* cookie is present AND
  no valid nonce is present
THEN block and log the request.

Example ModSecurity-style rule (sanitize and adapt to your environment):

SecRule REQUEST_METHOD "POST" "chain,phase:2,deny,log,id:100001,msg:'Block potential Icons Factory delete_files exploitation - unauthenticated request'"
  SecRule REQUEST_URI|ARGS|ARGS_NAMES "@rx (delete_files|delete_file|remove_file|file_to_delete|icons_factory_delete)" "t:none,chain"
  SecRule REQUEST_HEADERS:Cookie "!@rx wordpress_logged_in_"

Notes: parameter names may vary. Start with logging mode to reduce false positives, then move to blocking for confirmed malicious patterns.

Safe rule examples and practical tips

1. Require authentication for file-operation endpoints: allow only requests with WP authentication cookies to reach endpoints that perform file operations.
2. Nonce enforcement: block POSTs that lack expected nonce parameters (e.g., _wpnonce) or that have invalid nonces.
3. Restrict file path patterns: block requests containing ../ sequences, absolute paths, or references to critical files (wp-config.php, .htaccess).
4. Regex-based payload blocking: detect and block file path patterns such as /wp-content/uploads/.*|(\.\./)+|[A-Za-z]:\\ for unauthenticated requests.

Test WAF rules in staging first and monitor logs to reduce false positives.

Hardening recommendations to reduce impact of this and similar vulnerabilities

• Principle of least privilege: set file ownership and permissions to prevent the web process from deleting core files where possible.
• Disable plugin & theme editors: add define(‘DISALLOW_FILE_EDIT’, true); to wp-config.php.
• Maintain frequent, offsite backups with sufficient retention to roll back to a clean state.
• Enforce strong admin controls and multi-factor authentication for administrative accounts.
• Limit plugin sources: install only from reputable sources and maintain an inventory of installed plugins and their versions.
• Monitor file integrity using FIM (file integrity monitoring) and trigger alerts on deletions or unexpected changes.
• Periodic security audits and scanning in staging and production.
• Harden PHP and server settings: limit potentially dangerous functions and set open_basedir where appropriate.

Incident response playbook (step-by-step when compromise suspected)

1. Isolate: place site in maintenance mode and block suspect IPs.
2. Preserve evidence: snapshot filesystem and database; do not overwrite logs.
3. Triage: identify which files were deleted, correlate with logs, determine initial entry point.
4. Recover: restore from a clean backup taken before the attack; scan backups before restore.
5. Remediate: disable the vulnerable plugin, apply WAF rules, rotate credentials, and patch other vulnerabilities.
6. Rebuild if necessary: if a persistent backdoor is suspected, rebuild from clean sources and selectively restore verified content.
7. Post-incident review: conduct root cause analysis and implement controls to prevent recurrence.
8. Communicate: inform stakeholders, customers or regulators as required by policy.

Recovery and testing

• After restoring from backup and applying mitigations, run full security scans and integrity checks.
• Test site functionality, especially plugin-dependent areas, before restoring public access.
• Verify WAF logs are blocking malicious attempts and tune rules accordingly.
• Monitor closely for several days after recovery for signs of follow-on activity.

Why this vulnerability is especially dangerous for WordPress sites

• WordPress installations commonly use many third-party plugins of varying quality — one unauthenticated bug can be widely exploited.
• Shared hosting permission models can amplify damage from file-deletion bugs.
• Deletion is silent and immediate — attackers can cause damage without leaving obvious attack artifacts typical of RCE.

Frequently asked questions

Q: If I disable the plugin, will deleted files come back?

No. Disabling the plugin prevents further exploitation but does not restore deleted files. Restore from backups or perform manual recovery.

Q: Can file deletions be recovered from server trash or temporary storage?

Not usually. Web servers typically delete files immediately. Some control panels or hosts provide snapshots or trash features — contact your host promptly.

Q: Should I re-enable the plugin when a vendor patch is released?

Only after verifying the vendor’s patch properly enforces authorization checks and nonce validation. Test the patch in staging before re-enabling in production. If vendor responsiveness is poor, consider removing the plugin entirely and migrating functionality.

Long-term defenses administrators should implement

• Implement a plugin lifecycle policy: vet, inventory, update and remove unused plugins.
• Use role-based access control and minimise the number of administrator accounts.
• Separate duties for deployment and security operations.
• Integrate security testing in development pipelines and run dependency checks to detect vulnerable plugin versions.
• Schedule vulnerability monitoring and prepare virtual patching capabilities for rapid response.

Final thoughts — a note from a Hong Kong security expert

Arbitrary file deletion is deceptively destructive: it requires no privilege escalation and its effects can be immediate and costly. From a practitioner’s perspective in Hong Kong and other high-density hosting markets, speed is critical. Detect, isolate and mitigate quickly to reduce the damage window.

Apply layered defenses: strict backups, least-privilege permissions, monitoring, and WAF-based virtual patches while waiting for vendor fixes. If you manage multiple sites, prioritise inventory and rapid mitigation for plugins exposing AJAX or file-handling endpoints.

If you are unsure whether your site is affected or need assistance investigating suspicious activity, contact trusted security professionals or your hosting provider for forensic support.

— Hong Kong Security Expert