Summary

A new vulnerability (CVE-2025-10744) affects the WordPress plugin “File Manager, Code Editor, and Backup by Managefy” in versions ≤ 1.6.1. The issue is an unauthenticated information exposure (OWASP A3 / Sensitive Data Exposure). The vendor released a fix in version 1.6.2.

This guide aims to give administrators, developers and managed-host teams a practical checklist to:

• understand the risk,
• identify if sites are affected,
• contain and remediate quickly,
• harden environments to reduce future risk,
• and apply edge protections (virtual patching) where needed.

What the vulnerability is (plain language)

CVE-2025-10744 is an unauthenticated information exposure in the Managefy File Manager plugin. In short:

• A remote unauthenticated user may retrieve information that should be private.
• Exposed data could include file names, file contents, backup metadata, or configuration details depending on plugin usage.
• The vulnerability affects plugin versions ≤ 1.6.1; the vendor fixed the issue in 1.6.2.
• Because exploitation requires no login, any attacker able to reach your site over HTTP/HTTPS could attempt to access data.

Why this matters (threat model and risks)

Information disclosure is often underestimated. It may not directly give code execution, but it frequently enables follow-on attacks:

• Configuration files may reveal DB credentials, salts, API keys or server paths that enable further compromise.
• Backups may contain a full site copy: wp-config.php, uploads, user data.
• Exposed script contents can help craft RCE or SSRF attacks.
• Automated scanners can find and bulk-target vulnerable sites quickly after disclosure.

Treat this as time-sensitive: unauthenticated, automatable issues escalate fast in the wild.

Who is affected

• Any WordPress site with the plugin “File Manager, Code Editor, and Backup by Managefy” installed and active at version 1.6.1 or lower.
• Single-site and multisite installations.
• Sites that previously had the plugin and left residual files in web-accessible locations.
• Hosts offering one-click installs, plugin bundles or managed sites — scan across fleets.

Immediate actions (what to do in the next 60 minutes)

1. Check whether the plugin is installed and its version.
   • WP‑Admin: Plugins → Installed Plugins → look for “File Manager, Code Editor, and Backup by Managefy”.
   • SSH (site root):

     wp plugin list --path=/path/to/your/site

     or

     grep -R "Plugin Name: File Manager" wp-content/plugins -n || true

   • Typical plugin folder: wp-content/plugins/softdiscover-db-file-manager (confirm on your install).
2. If present and version ≤ 1.6.1: update immediately to 1.6.2.
   • WP‑Admin: click “Update now”.
   • CLI:

     wp plugin update softdiscover-db-file-manager --path=/path/to/your/site

     (Substitute the slug shown by wp plugin list if different.)

3. If you cannot update immediately, deactivate the plugin:

   wp plugin deactivate softdiscover-db-file-manager --path=/path/to/your/site

   or deactivate from WP‑Admin.

4. Remove publicly exposed backups from web‑accessible locations; move them outside the web root.
5. If you find secrets in exposed files (DB passwords, API keys), rotate them immediately.
6. Preserve logs and evidence for forensic review. If possible, increase logging temporarily.

If you can’t update — fast mitigations

If operational constraints prevent an immediate update, apply these stop-gap controls until you can patch:

• Restrict access to the plugin directory via webserver rules.
• Block or rate-limit suspicious requests to suspected plugin endpoints at the edge (CDN/WAF or reverse proxy).
• For AJAX admin endpoints, deny requests with suspicious parameters from unauthenticated sources (e.g., deny requests containing file=, path=, get_backup, download).
• Place the site into maintenance mode if you suspect active exploitation and need time to investigate.

Example webserver rules

Adapt these to your environment and test before production.

Apache (.htaccess)

<IfModule mod_authz_core.c>
    <FilesMatch "^(.*)$">
        Require ip 203.0.113.0/24
        # OR require valid-user
    </FilesMatch>
</IfModule>
<IfModule !mod_authz_core.c>
    Order deny,allow
    Deny from all
    Allow from 203.0.113.0/24
</IfModule>

Replace the IP block with trusted admin IPs or your management network.

Nginx

location ~* /wp-content/plugins/softdiscover-db-file-manager/ {
    allow 203.0.113.0/24;
    deny all;
}

Edge rule examples (conceptual)

SecRule REQUEST_URI|ARGS "@rx /(wp-content/plugins/softdiscover-db-file-manager|softdiscover-db-file-manager)/i"
  "id:1005001,phase:2,deny,log,msg:'Block suspicious access to File Manager plugin',severity:2,tag:'wp-vuln-CVE-2025-10744'"

SecRule REQUEST_METHOD "GET|POST"
  "chain,phase:2,deny,log,id:1005002,msg:'Block likely file-download attempts to vulnerable plugin endpoints'
   SecRule ARGS_NAMES|ARGS|REQUEST_URI|REQUEST_HEADERS|REQUEST_BODY "@rx (file=|path=|backup|download|get_file|get_backup|zip=|contents=)""

Monitor logs closely for false positives when enabling blocking rules.

How to detect exploitation (indicators of compromise)

Look for the following in logs and the filesystem:

• Unexpected HTTP requests referencing the plugin folder name or related endpoints.
• High request volume from single IPs targeting plugin endpoints (scanning).
• HTTP 200 responses that return file content (HTML, JSON, base64 data).
• New or changed files in uploads, wp-content, or plugin directories.
• New admin users, changed passwords, or suspicious cron jobs.
• Outbound connections to unknown domains from the server.
• Publicly-accessible backup files in webroot that you did not intend to publish.

Recommended log checks

• Web server access logs: grep for the plugin slug and suspicious parameters.
• PHP error logs for anomalies following plugin access.
• WordPress activity logs (if available) for changes during suspicious times.

Containment and cleanup checklist

1. If compromise is confirmed, isolate the site: suspend public access if feasible and change admin passwords.
2. Take a full forensic backup (files + DB) for analysis before making changes.
3. Update the vulnerable plugin to 1.6.2 or remove it if not required.
4. Replace wp-config.php and rotate DB credentials if that file was exposed.
5. Scan the site/server for web shells, modified core files and unknown scheduled tasks.
6. Restore from a known good backup if needed.
7. Rotate all administrative credentials (FTP/SFTP, control panel, SSH keys).
8. Notify stakeholders and affected customers if you operate a hosting service.
9. Review logs for evidence of data exfiltration and follow applicable breach notification steps if sensitive data was taken.

Long‑term hardening and prevention

• Minimise the use of browser-based file managers; prefer SFTP/SSH for file operations.
• Enforce least privilege for admin accounts and restrict plugin features to trusted roles.
• Keep backups offsite and never store full backups in web‑accessible directories.
• Test plugin updates in staging; enable automatic updates only for trusted, well-maintained plugins.
• Deploy edge protections (CDN/WAF/reverse proxy) to block exploit attempts and apply virtual patches when necessary.
• Use integrity monitoring (file change detection) and activity logging for early detection.
• Remove abandoned or low-quality plugins from all sites.

Virtual patching and detection — practical guidance

When you cannot update immediately, virtual patching (edge rules) and improved detection are pragmatic ways to reduce risk. Recommended steps:

• Deploy targeted edge rules that block requests to known plugin paths and suspicious parameters.
• Rate-limit or block automated scanning behaviour against plugin endpoints.
• Implement monitoring for large responses from plugin endpoints (indicative of file downloads).
• Alert on anomalous access patterns and provide captured evidence (full request/response) for forensic review.
• Test rules in a staging environment to tune for false positives before blocking in production.

Developer guidance — how this should have been implemented

• Never serve file contents or backups through unauthenticated endpoints.
• Enforce capability checks with WordPress native functions (e.g., current_user_can('manage_options')).
• Use nonces for AJAX actions and validate them server-side.
• Avoid storing secrets in webroot; if unavoidable, protect them with strict access controls.
• Validate and canonicalise file path input and restrict file operations to allowed directories.
• Log access to sensitive endpoints for audit trails and incident response.

How to check your environment: commands & tips

• List plugin versions via WP‑CLI:

  wp plugin list --format=table

• Search for plugin folder:

  ls -la wp-content/plugins | grep -i softdiscover || true

• Search access logs:

  grep -i "softdiscover-db-file-manager" /var/log/nginx/access.log* | tail -n 200

• Search for backup artifacts:

  find . -type f -iname "*backup*.zip" -o -iname "*backup*.tar*" -maxdepth 4

Sample incident response timeline

1. 0–1 hour: Confirm presence of plugin and version. Update or deactivate if vulnerable.
2. 1–3 hours: Apply temporary access restrictions (webserver/WAF) and search logs for suspicious activity.
3. 3–24 hours: Preserve forensic evidence and complete site scan. Remove exposed backups from webroot.
4. 24–72 hours: If compromise suspected, perform deeper forensic review, rotate credentials and restore from clean backups as necessary.
5. Post-incident: Review controls, improve logging and consider ongoing managed protection or consulting support.

What to tell your customers / stakeholders (sample message)

We identified a vulnerability in a third‑party plugin (File Manager by Managefy) that could allow unauthenticated users to access files or backups on affected versions (≤ 1.6.1). The vendor released a fix in 1.6.2. We have updated (or deactivated) the plugin and removed any publicly accessible backups. We are actively scanning for signs of impact and will notify if we find compromised data. We recommend all customers update to the latest version and apply edge protections while we complete the investigation.

Frequently asked questions

Q: If I updated to 1.6.2, am I safe?

A: Updating to 1.6.2 addresses the specific vulnerability. However, you should still scan for prior exploitation (backup downloads, exposed files), rotate credentials if they may have been exposed, and review the site for additional changes.

Q: If I deactivated the plugin, will that stop the exposure?

A: Deactivating typically prevents the plugin from serving PHP endpoints, which mitigates exposure. However, residual backup files or artifacts may still be web-accessible; remove such files from the webroot.

Q: Should I remove the plugin permanently?

A: If you do not need an in‑browser file manager, removing the plugin reduces future risk. Use SFTP/SSH for file operations where possible.

Example WAF detections to watch

• Repeated requests to the plugin path with file or backup parameters.
• Requests resulting in unusually large responses (file downloads).
• Requests from TOR exit nodes or known scanning IPs targeting plugin endpoints.
• Suspicious user agents combined with plugin access.

Recovery checklist (short)

• Update plugin to 1.6.2.
• Remove web-accessible backups.
• Rotate credentials if backups contained secrets.
• Scan for web shells and unusual files.
• Restore from clean backup if needed.
• Harden and restrict plugin directory if the plugin must remain active.
• Apply edge rules and detection until all sites are updated.