Pluginnaam	WordPress File Manager, Code Editor, and Backup by Managefy
Type of Vulnerability	Unauthenticated Information Exposure
CVE Number	CVE-2025-10744
Urgentie	Laag
CVE Publish Date	2025-09-30
Source URL	CVE-2025-10744

Urgent: CVE-2025-10744 — Unauthenticated Information Exposure in ‘File Manager, Code Editor, and Backup by Managefy’ (≤ 1.6.1) — What WordPress Site Owners Must Do Now

Author: WP‑Firewall Security Team | Date: 2025-09-30 | Categories: Security, Vulnerability, WordPress | Tags: CVE-2025-10744, WordPress, plugin vulnerability, WAF, incident response

Samenvatting

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

This blog is written from the perspective of the WP‑Firewall security team. Our goal is to give WordPress administrators, developers and managed hosts a practical, actionable guide to:

• understand the risk,
• identify whether they are affected,
• contain and remediate quickly,
• harden environments to prevent exploitation,
• and apply virtual patching / WAF protections where appropriate.

This is written in a straightforward, human tone by experienced WordPress security practitioners — not marketing copy. If you manage WordPress sites, follow the checklist below immediately.

What the vulnerability is (short, plain language)

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

• A remote unauthenticated user can retrieve information that should be private.
• The exposed information may include file names, file contents, backup metadata, or other configuration details depending on how the plugin was used on a site.
• The vulnerability affects plugin installations at versions ≤ 1.6.1.
• The vendor fixed the issue in 1.6.2 — updating is the supported remediation.

Because the vulnerability is unauthenticated, any attacker that can reach your website over HTTP/HTTPS could attempt to exploit it without prior login.

Why this matters (threat model and risks)

Information disclosure vulnerabilities are often underestimated. While they don’t immediately grant remote code execution or database writes, they can enable or accelerate severe follow-up attacks:

• Exposure of configuration files could reveal database credentials, salts, API keys, or paths that enable more serious attacks.
• Exposed backup files may contain full site copies, including wp-config.php, uploads, and user data.
• File contents could reveal secrets or server-side scripts that allow an attacker to craft RCE or SSRF attacks.
• Attackers often scan for these weak points and use them to map sites and build targeted attacks or bulk exploit campaigns.

Because exploitation is unauthenticated and easy to automate, the realistic risk increases quickly after public disclosure — even for vulnerabilities with a moderate CVSS. Treat this as time-sensitive.

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 WordPress instances are both in scope.
• Sites that had the plugin installed previously and left residual files behind may still be at risk.
• Hosts that provide one-click installers, automatic plugin bundles, or managed sites should scan across their fleet.

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

1. Check if the plugin is installed and its version.

   • From WP‑Admin: Plugins → Installed Plugins → look for “File Manager, Code Editor, and Backup by Managefy”.
   • From the server shell (SSH), in your site root:

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

   • or inspect the plugin header:

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

   The plugin folder is typically: wp-content/plugins/softdiscover-db-file-manager (plugin slugs vary; confirm on your install).

2. If the plugin is present and version ≤ 1.6.1: update immediately.

   • From WP‑Admin: click “Update now” or use the plugin updater.
   • From CLI:

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

   If the repo slug differs, substitute the identifier shown by wp plugin list.

3. If you cannot update immediately, disable the plugin temporarily:

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

   or from WP‑Admin: Deactivate.

4. Remove publicly exposed backups from web‑accessible locations. If the plugin stored backups in a web‑accessible directory, move them outside the web root immediately.
5. Rotate any exposed secrets if you discover them in backups or exposed config files (database passwords, API keys, OAuth secrets).
6. Preserve logs and evidence for forensics. Increase logging level if possible.

If you can’t update — fast mitigations

Not every site can update immediately due to compatibility, staging, or operational constraints. Use these mitigations until an update is possible:

• Block or restrict access to the plugin directory with webserver rules (recommended):
  • 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 IPs or restrict to your admin network. This is useful when you only access the file manager from specific IPs.

  • Nginx

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

• Block HTTP GET/POST requests that appear to be querying file content or backup download endpoints via your WAF (see sample rules later).
• If the plugin exposes AJAX actions via admin-ajax.php, create a rule to deny requests with suspicious parameters (e.g., file=, path=, get_backup, download) from non-admin sessions.
• Put the site into maintenance mode if you suspect active abuse and need time for an in-depth response.

How to detect exploitation (indicators of compromise)

Look for the following signs in logs, file system and control panel:

• Unexpected HTTP requests to plugin-specific paths, e.g. requests containing the plugin folder name or endpoints that reference code editor/backups.
• Large numbers of requests from a single IP to those plugin endpoints (scanning behavior).
• HTTP 200 responses that return file contents (HTML, JSON, base64 payload) where a request ordinarily shouldn’t.
• New or modified files in uploads, wp-content, or plugin directories (timestamps that don’t match admin activity).
• New admin users, changed passwords, or unexpected cron events (wp_options → cron).
• Outbound connections to suspicious domains from the server (reverse shell/exfiltration).
• Presence of backup files in web root accessible via direct URL that you did not intentionally publish.

Recommended log checks:

• Web server access log: grep plugin slug and look for unusual parameters or large response sizes.
• PHP error logs for unexpected warnings/errors that start after plugin access.
• WP activity logs (if you have an auditing plugin) for changes during suspicious periods.

Containment and cleanup checklist

1. If compromise is confirmed, isolate the site: disable network access if possible, change admin passwords, and suspend public access.
2. Take a full forensic backup of the site (files + DB) for analysis before making changes.
3. Update the vulnerable plugin to 1.6.2 (or remove if not necessary).
4. Replace wp-config.php and rotate DB credentials if the file was exposed.
5. Scan the site and server with a reputable malware scanner; look for web shells, modified core files, and unknown scheduled tasks.
6. Restore from a known good backup if necessary.
7. Rotate all credentials (FTP/SFTP, control panel, SSH keys) used to administer the site.
8. Notify stakeholders and, if you host customer sites, affected customers.
9. Review logs for indicators of data exfiltration; if sensitive data has been stolen, follow applicable breach notification laws and policies.

Long‑term hardening and prevention

• Minimize the number of “file manager” plugins: they create additional attack surface. Where possible, use SFTP / SSH for file management rather than in‑browser editors.
• Enforce principle of least privilege: admin accounts should be limited, and plugin features that expose file systems should be restricted to trusted roles.
• Move backups to offsite storage and never leave full backups in a web‑accessible directory.
• Enable regular automatic updates for plugins you trust and have tested; otherwise use a staging environment to validate updates early.
• Implement a Web Application Firewall (WAF) to block automated exploit attempts and to apply virtual patches until vendor updates are deployed.
• Use security plugins that provide integrity monitoring (file change detection) and activity logging for early detection.
• Regularly scan plugins for known vulnerabilities and remove abandoned or low-quality plugins.

How WP‑Firewall helps you now (virtual patching and detection)

At WP‑Firewall we treat vulnerabilities like this in two parallel ways:

1. Immediate virtual patching (WAF rules)
   • We deploy WAF rules that specifically target suspicious request patterns associated with information disclosure attempts.
   • Virtual patching reduces risk for sites that cannot update immediately by blocking exploit traffic at the edge.
   • Our WAF can be tuned per-site to avoid false positives while still stopping scanners and malicious requests.
2. Detection and alerting
   • WP‑Firewall monitors anomalous file requests, large downloads, and abnormal patterns to plugin paths.
   • Alerts are sent to administrators with suggestions for remediation and evidence for forensic teams.

Below are example WAF signatures and recommendations you can implement on your own WAF or with WP‑Firewall. These are generic rules to illustrate the approach; WP‑Firewall applies refined signatures based on observed exploit traffic to reduce false positives.

Example ModSecurity rule (conceptual — test before production):

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=)""

Notes:

• Adjust IDs when integrating with your ruleset.
• Gebruik log En deny carefully and monitor for false positives in a staging environment first.

Example nginx rule to return 403 for direct plugin directory access (quick mitigation):

location ~* ^/wp-content/plugins/softdiscover-db-file-manager/ {
    return 403;
}

If admin access must be preserved for some IPs, use allow / deny blocks around the location.

Practical developer recommendations (how this should have been implemented)

If you are a plugin author or developer, follow these hard rules:

• Never serve file contents or backups via an unauthenticated endpoint.
• Enforce capability checks using WordPress’s native functions (e.g., current_user_can('manage_options')) for sensitive operations.
• Use nonces for AJAX endpoints that change state or expose data to bound actions.
• Avoid storing secrets in files accessible to the webroot; if you must store them, ensure they are outside webroot or protected by strict access checks.
• Perform access control checks before reading or returning any file content.
• Validate and sanitize any file path input; canonicalize and compare to allowed directories.
• Log access to sensitive endpoints for audit trails.

How to check your environment: commands & tips

• List plugin versions via WP‑CLI:

  wp plugin list --format=table

• Search for plugin folder on disk:

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

• Search logs for plugin-specific requests:

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

• Search for backup artifacts in web root:

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

Sample incident response timeline (recommended)

1. 0–1 hour: Identify if plugin exists and if it is active. If active and vulnerable, either update or deactivate.
2. 1–3 hours: Apply temporary access restrictions (webserver/WAF) and search logs for suspicious access.
3. 3–24 hours: Preserve forensic evidence and complete a full site scan. Remove exposed backups from webroot.
4. 24–72 hours: If compromise suspected, do deeper forensic review, rotate credentials, and if necessary restore from a clean backup.
5. Post-incident: Review controls, enable better logging, and consider ongoing managed protection / WAF.

What to tell your customers / stakeholders (sample communication)

If you need a short, clear message for customers:

• We identified a vulnerability in a third‑party plugin (File Manager by Managefy) that could allow unauthenticated users to access certain 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 indicators of impact and will notify if we find any compromised data. We recommend all customers update to the latest version and enable WAF protections while we complete our investigation.

Frequently asked questions

Q: If I updated to 1.6.2, am I safe?
A: Updating to 1.6.2 removes the specific vulnerability. You should still scan for signs of prior exploitation (backup downloads, exposed files), rotate sensitive credentials if they may have been exposed, and ensure the plugin was not used to introduce additional changes.

Q: If I deactivated the plugin, will that stop the exposure?
A: Deactivating typically prevents PHP endpoints from processing, which mitigates exposure. But residual backup files or artifacts may still be accessible; remove web‑accessible backups.

Q: Should I remove the plugin permanently?
A: If you don’t actively need an in‑browser file manager, removing the plugin reduces future risk. Use SFTP/SSH for file operations when possible.

Example WAF detections we recommend watching for

• Repeated requests to plugin paths with parameters likely referencing files or backups.
• Requests that result in unusually large responses (indicative of a file download).
• Requests from TOR exit nodes or known bad scanning IPs that hit the plugin endpoints.
• Suspicious user agent strings 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 plugin must remain active
• Enable WAF rules / virtual patching until all sites are updated

Protect your site instantly — start with WP‑Firewall Free

If you’re managing WordPress sites and you want an immediate safety net while you apply the steps above, sign up for WP‑Firewall’s free plan. The free Basic plan gives you essential protection: a managed firewall, unlimited bandwidth, an application layer WAF, malware scanning, and mitigation coverage for OWASP Top 10 risks. Sign up here and get automated defenses protecting your site within minutes: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(Also consider Standard or Pro plans if you need automatic malware removal, IP allow/deny lists, monthly security reports, or automatic virtual patching across your fleet.)

Final thoughts from WP‑Firewall

Information disclosure bugs like CVE-2025-10744 are a reminder that convenient features—browser-based file managers and backup interfaces—have to be implemented with extreme care. For site operators, speed matters: update, contain, and inspect quickly. For teams that need more time to patch, virtual patching via a WAF is a proven way to buy time and reduce risk.

If you want hands-on help applying virtual patches, building precise WAF rules, or running a forensic check of a suspected compromise, our security team can assist. Sign up to the free WP‑Firewall plan to get immediate baseline protection and then evaluate higher-tier plans if you want managed response and reporting.

Stay safe, keep plugins updated, and treat file‑access features like the sensitive capability they are.

— WP‑Firewall Security Team