Nazwa wtyczki	Icons Factory
Type of Vulnerability	Unauthenticated File Deletion
CVE Number	CVE-2025-7778
Pilność	Wysoki
CVE Publish Date	2025-08-15
Source URL	CVE-2025-7778

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

TL;DR
A critical vulnerability (CVE-2025-7778) affecting the WordPress Icons Factory plugin (versions <= 1.6.12) allows unauthenticated attackers to trigger an arbitrary file deletion routine via the plugin’s delete_files() functionality. The vulnerability requires no authentication, has a high severity CVSS (8.6), and can lead to site breakage, data loss, and further post-exploitation activity. If you run this plugin — act immediately: disable or remove the plugin, restore from clean backups if needed, and apply virtual patching via your WAF until an official fix is available.

---

Why this matters (a short, clear risk summary)

• Vulnerability type: Arbitrary File Deletion (missing authorization check on a file-delete function).
• Privilege required: None — unauthenticated attackers can trigger it.
• Impact: Attackers can delete arbitrary files that the web server user has access to. That includes plugin/theme files, uploads, cached files, and potentially core files if file permissions are permissive. Deleted core files can cause site downtime and be used as part of broader compromise workflows (data removal, persistence, enabling further exploits).
• Urgency: High. Because the attack requires no authentication, automated scanning and mass exploitation are likely once proof-of-concept methods circulate.

---

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

The plugin exposes a delete_files() routine that is callable in a context lacking proper authorization checks. Typical secure development practice requires verification that the caller is authenticated and has the necessary capability (for example: current_user_can('manage_options') or a valid capability checked via a properly verified nonce). In this case, the delete_files() function accepts input from an HTTP request and performs file removal without enforcing such checks.

Consequences:

• An attacker can craft HTTP requests that cause the plugin to delete files accessible by the web process.
• Deletions can break functionality (missing PHP files), remove content (uploads), or modify the website’s state to mask or enable further attacks.
• Depending on file permissions and hosting setup, the impact spans from site-specific disruptions to potentially wider infrastructure issues on shared hosting.

Note: The CVE identifier for this issue is CVE-2025-7778.

---

Exploitation scenarios and attacker goals

Attackers may exploit this vulnerability for several objectives:

1. Immediate denial of service (DoS) — delete core files, plugin files, or theme files so the site fails to load.
2. Destroy traces — delete logs or backup files to make forensic investigation harder.
3. Prepare for follow-on attacks — remove specific files to enable uploads with certain paths, replace deleted files with web shells or backdoors (if they can then place files).
4. Extortion — threaten site owners with permanent deletion unless a ransom is paid.
5. Targeted sabotage — if aimed at a specific organization, delete content or configuration to disrupt operations.

Because the vulnerability is unauthenticated, attacks can be automated and widely scanned for. This increases the speed and scale of impact.

---

How to quickly check if your site is affected

1. Inventory plugins:
   • In the WordPress dashboard, go to Plugins → Installed Plugins and look for “Icons Factory”. If present, check its version. Vulnerable versions are noted as ≤ 1.6.12.
2. Look for missing or recently deleted files:
   • Compare current plugin directory contents to a fresh copy of the plugin from a trusted source. If files are missing or timestamps are suspicious, investigate further.
3. Web server logs:
   • Search access logs and error logs for suspicious POST requests to admin-ajax.php or to plugin-specific endpoints around the time deletions occurred. Look for requests that include parameters like delete, remove, or file names referenced in deletion operations.
4. File system checks:
   • Review wp-content/przesyłanie, plugin and theme directories for altered or missing files.
5. Check for unknown admin users or changes to users/roles — while unauthorized file deletion itself doesn’t create accounts, attackers often follow up with further actions.

If you find evidence that files were deleted or modified and you cannot account for it, treat it as a suspected compromise and follow incident response guidance below.

---

Immediate remediation steps (what to do right now)

If you manage a site using the affected plugin, take these immediate actions in the order listed:

1. Put the site into maintenance mode (if possible) to prevent further automated exploitation.
2. Disable the vulnerable plugin:
   • From wp-admin → Plugins, deactivate Icons Factory.
   • If you cannot access wp-admin, rename the plugin’s directory via SFTP/SSH (e.g., rename wp-content/plugins/icons-factory Do icons-factory.disabled).
3. Restore missing files from a known-good backup (see notes below). If you’re unsure whether backup is clean, preserve the current state and obtain professional help for forensic review.
4. Rotate credentials:
   • Reset WordPress admin passwords and database credentials.
   • Rotate any API keys or credentials that might be used by plugins or themes.
5. Update everything:
   • Update WordPress core, themes, and other plugins after ensuring you have clean backups. Only re-enable the plugin if and when the vendor issues a secure patch.
6. If official patch is not available:
   • Apply a WAF virtual patch (see WAF mitigation section below).
   • Consider removing the plugin entirely and moving to a safe alternative.
7. Scan for additional malware:
   • Run a full malware scan for webshells or indicators of persistence.
8. Contact your host and request assistance, especially for server-level logs and snapshot restores if needed.
9. Review file system permissions:
   • Tighten file permissions so the webuser cannot delete core files (see hardening below).

If your site has been compromised (files removed and replaced with backdoors, or there is evidence of data exfiltration), escalate to a professional incident response team.

---

Detection: what to look for in logs and file systems

• Access logs:
  • POST requests targeting admin-ajax.php or plugin endpoints with unusual parameters.
  • Requests from single IPs that make repeated POSTs containing file path-like strings.
  • Requests with empty or forged referer headers, or user-agents that look like automated scanners.
• Error logs:
  • PHP warnings about missing files, failed includes, or require_once errors referencing plugin or core files.
• File system:
  • Missing PHP files in plugin/theme folders.
  • Deleted or empty files in wp-content/przesyłanie.
  • Unexpected changes in modification times, especially shortly after suspicious requests in logs.
• Database:
  • Unexpected modifications to options table or user accounts.
• Backups:
  • Compare your latest backup with the current filesystem and note differences.

Create a timeline correlating suspicious requests to file deletions. Preserve logs before making changes.

---

Indicators of Compromise (IOCs) — what to watch for

• Requests with parameters that reference file paths (e.g., paths with ../ or absolute paths).
• POST traffic spikes to admin-ajax.php or endpoints under /wp-content/plugins/icons-factory/
• Sudden 500/503 errors and missing includes in PHP error logs
• Files present in backups but absent on production
• Unexpected reboots of services if a script attempted broad deletions

If you find any of the above, collect logs, preserve filesystem snapshots, and proceed with incident response.

---

Virtual patching and WAF protection (recommended rules and logic)

If an official plugin update or fix is not yet released, a Web Application Firewall (WAF) can protect sites by blocking exploit attempts. Below are recommended defense-in-depth rules and detection strategies you can apply. These are written as conceptual rules and as an example ModSecurity-style rule. Adaptation to your WAF engine syntax will be necessary.

WAF mitigation strategy (conceptual):

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

Pseudo-rule logic:

• If HTTP request is a POST to admin-ajax.php or plugin endpoint AND
  • Request body contains parameters likely related to deletion (e.g., delete, file, path, filenames) AND
  • No valid WordPress authentication cookie present (wordpress_logged_in_*), AND
  • No valid nonce present or nonce invalid,

  THEN block the request and log the event.

Example ModSecurity-style rule (sanitized; adapt to your platform):

# Example: block unauthenticated attempts to trigger deletion-related actions
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:

• The exact parameter names used by the plugin may vary — so tune rules to match observed exploit parameters and plugin endpoints.
• If your WAF supports positive validation of nonces, require the presence of a valid wpnonce for any calls related to file operations.
• Use logging and alerting before putting rules in blocking mode so you can avoid false positives. Start with blocking for known-malicious request patterns and then expand.

WAF virtual patching is a temporary and effective mitigation while waiting for an official patch, but it should be combined with the other actions in this guide.

---

Safe rule examples and implementation guidance (practical tips)

1. Require authentication for file-operation endpoints:
   • If you can create a WAF rule that allows only requests that include WP user authentication cookies (wordpress_logged_in_*) to reach plugin endpoints that perform file operations, it will reduce risk.
2. Nonce enforcement:
   • Block POSTs that lack the expected nonce parameter (usually _wpnonce or similar) or that have invalid nonces as verified by a backend endpoint. If backend verification is not possible at the WAF layer, require the presence of the nonce parameter and whitelist internal backends that generate valid nonces.
3. Restrict accessible filesystem locations:
   • If the plugin accepts paths, block any requests containing ../ sequences, absolute paths, or references to wp-config.php, Plik .htaccess, or other critical files.
4. Block requests with suspicious payloads:
   • Use regex checks to detect file path patterns (/wp-content/uploads/.*|(\.\./)+|[A-Za-z]:\\) and block them for unauthenticated requests.

Reminder: Always test WAF rules in a staging or low-risk environment first. Monitor logs to fine-tune rules and reduce false positives.

---

Hardening recommendations to reduce impact of this and similar vulnerabilities

• Principle of least privilege for files and directories:
  • PHP files should be owned appropriately and file permissions set to disallow unnecessary write/delete by the web process for core files. For example, wp-config.php should be read-only under most hosting models.
• Disable plugin & theme editors:
  • define('DISALLOW_FILE_EDIT', true); W wp-config.php to reduce risk of code modifications via the admin UI.
• Maintain frequent, logical backups:
  • Keep daily backups offsite and use backups retention that allows you to roll back to a clean state quickly.
• Use strong admin account controls:
  • Enforce multi-factor authentication (MFA) for all administrator accounts and limit number of admin users.
• Limit plugin installation sources:
  • Only install plugins from reputable sources and maintain an inventory of installed plugins and versions.
• Monitor file integrity:
  • Use file integrity monitoring (FIM) to detect unexpected changes. Alerts should be triggered for deletions or changes in key directories.
• Periodic security audits:
  • Run periodic scans and audits; make sure to act on warnings and anomalies promptly.
• Harden PHP and server configuration:
  • Disable PHP functions that are commonly abused if not required (e.g., exec, system) and use appropriate open_basedir and other PHP hardening directives.

---

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

1. Isolate:
   • Put site into maintenance mode and block traffic from suspect IPs.
2. Preserve evidence:
   • Snapshot the current filesystem and database. Don’t overwrite logs or reconfigure the server in ways that would remove evidence.
3. Triage:
   • Identify which files were deleted, how and when; correlate with logs. Identify initial point of entry.
4. Recover:
   • Restore from clean backup prior to the attack time. Ensure backups are clean (scan backup before restore).
5. Remediate:
   • Apply the immediate remediations: disable vulnerable plugin, apply WAF virtual patch, rotate credentials, patch other vulnerabilities.
6. Rebuild:
   • If recovery from backup is impossible or guarantees a persistent backdoor is present, rebuild site from clean sources and restore content selectively after verification.
7. Post-incident review:
   • Conduct a root cause analysis and implement long-term controls to prevent recurrence.
8. Communicate:
   • If customer or regulatory notice is required, document timeline and notify stakeholders per your incident response plan.

---

Recovery and testing

• After restoring from backup and applying mitigations, run a full security scan.
• Test site functionality thoroughly — especially parts that depend on plugin features — before re-enabling public access.
• Verify WAF rules are capturing/blocking malicious attempts in logs and tune accordingly.
• Continue monitoring for at least several days to ensure no follow-on activity occurs.

---

Why this vulnerability is particularly dangerous for WordPress sites

• WordPress sites often run with many plugins and varying levels of maintenance. A single unauthenticated bug in a popular plugin can quickly be discovered and weaponized.
• Many shared hosting environments have file-permission setups that can amplify the impact of file-deletion bugs.
• Administrators sometimes delay updates or run outdated plug-ins, increasing window of exposure.
• Because deletion is silent (no direct code execution required), attackers can cause damage without leaving the immediate obvious traces that are typical of remote code execution (RCE) attacks.

This is why defense-in-depth, including virtual patching, monitoring, and rigorous backup strategies, is essential.

---

Frequently asked questions

Q: If I disable the plugin, will deleted files come back?
A: No. Disabling the plugin prevents further exploitation but does not restore deleted files. You must restore from backups or manual recovery. If deletion impacted site core files, restoring core from a fresh WordPress install and verifying plugins/themes is required.

Q: Can file deletions be recovered from server trash or temporary storage?
A: Not usually. Webservers generally delete files immediately; some control panels or hosts offer snapshot backups or trash features — check with your host immediately.

Q: Should I re-enable the plugin when a vendor patch is released?
A: Only after verifying the patch addresses the authorization checks (explicitly validates authentication and proper capability checks) and after testing in staging. If no patch is available or you lack confidence in vendor responsiveness, consider using alternative plugins or built-in functionality.

---

Long-term defenses WP Administrators should implement

• Enforce a plugin lifecycle policy: vet, inventory, update, and remove unused plugins.
• Use role-based access control and reduce the number of accounts with administrator privileges.
• Apply separation of duties for deployments and security operations.
• Integrate security testing in development and staging, and run automated dependency checks to detect vulnerable plugin versions.
• Adopt scheduled vulnerability monitoring and proactive virtual patching where possible.

---

Protect Your Site Now — Start with WP-Firewall Free Plan

If you want immediate, managed protection that covers this kind of vulnerability, consider starting with WP-Firewall’s Basic (Free) plan. The free plan includes essential defenses such as a managed firewall and WAF, malware scanning, and mitigation for OWASP Top 10 risks — the exact protections that can stop unauthenticated attempts to trigger file-deleting functions. Our free tier gives you instant coverage and is a fast way to gain control while you perform remediation or wait for vendor fixes.

Learn more and sign up for the free plan here:
https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Key benefits of the free plan:

• Essential managed firewall and WAF rules (virtual patching for known threats)
• Unlimited bandwidth through our protection layer
• Malware scanner and mitigation for common attack patterns (OWASP Top 10)

If you need more automated cleanup and proactive blocking, consider our paid tiers which add automatic malware removal, IP blacklisting/whitelisting, monthly reports, and auto virtual patching features.

---

Final thoughts from a WordPress security practitioner

Arbitrary file deletion is deceptively destructive: it doesn’t require privilege escalation, and its effects are often immediate and hard to reverse without reliable backups and intervention. For site owners, speed matters — the faster you detect, isolate, and mitigate, the lower the damage and recovery cost. The combination of disciplined patching, robust backups, least-privilege file permissions, and a WAF that can apply virtual patches provides the best practical defense.

If you manage multiple WordPress sites, treat this event as a reminder to inventory your plugins, prioritize those with external exposure (AJAX endpoints, file handlers), and apply layered defenses. If you’re unsure whether your site is affected or need help with a suspicious incident, reach out to trusted professionals or your hosting provider for deeper forensic investigation.

Stay vigilant, apply the mitigations above, and if you haven’t already, consider leveraging a managed firewall solution (including our free plan) to reduce the window of exposure while you remediate.

— WP-Firewall Security Team