CVE-2024-0761 is a high severity (CVSS 8.1) sensitive information exposure in the File Manager plugin for WordPress, in all versions up to and including 7.2.1. Backup filenames are guessable, so unauthenticated visitors may reach site backups. Update to a release newer than 7.2.1 and block direct access to the backup directory.
What's affected
The File Manager plugin for WordPress (listed under the vendor name filemanagerpro, plugin directory slug wp-file-manager), all versions up to and including 7.2.1. The record says backup filenames are built from a timestamp plus 4 random digits, and that the exposure applies in configurations where the .htaccess file in the backup directory does not block access.
The record does not name a fixed version. The references include a plugin changeset, so a later release carries the change, but confirm the exact version on the plugin page or changelog before you rely on it.
The record classifies the weakness as CWE-330 (use of insufficiently random values). NVD scores it 8.1 (High) with the vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H.
How to check if you're exposed
Plugins are the usual blind spot on a WordPress estate, so start with an inventory. If you have shell access and WP-CLI, this lists every plugin with its version and status:
wp plugin list --fields=name,status,version,update
Look for File Manager in the output and compare the version to the range above. Without WP-CLI, open Plugins in the dashboard and read the version under the plugin name. Do this on every site, including staging copies and old multisite installs, because inactive plugins still sit on disk and some can be reached directly by URL.
The free in-browser dependency scan covers application dependencies in your repositories. It does not read a live WordPress install, so use the plugin list for this one.
What to do now
- Update File Manager to the newest release on the plugin page, and confirm in the changelog that it is later than 7.2.1.
- Check that the backup directory is not readable over HTTP. If your web server ignores .htaccess, add an equivalent deny rule in the server configuration.
- Look in the backup directory for old archives and remove the ones you do not need. A backup that no longer exists cannot be downloaded.
- Review access logs for requests to the backup folder from unfamiliar addresses. If you see downloads you cannot explain, treat any secrets in those backups, such as database credentials and API keys, as exposed and rotate them.
Why it matters
A timestamp plus four digits is a small search space. Ten thousand possible suffixes per second of timestamp is something a script can walk through, which is why the CWE class is insufficient randomness rather than a bug in file permissions. The attacker needs no account, and the backups can hold the whole site, including the database.
The high attack complexity in the vector reflects the dependency on server configuration. If your server already refuses to serve that directory, the practical risk drops a lot. Treat that as a second layer, not a reason to skip the update.
The record does not mark this CVE as being in the CISA Known Exploited Vulnerabilities catalog, and nothing in the record says it is exploited in the wild. That can change, so keep it on your watch list.
Quick check
Does a server rule alone solve this?
It removes the exposure path the record describes, but the plugin still produces predictable names. Update the plugin and keep the server rule.
Sources
The links below are the references listed in the CVE record. The record and its description were the basis for this post, and the vendor advisory remains the authority for fixed versions.
Last reviewed: 19 October 2026.
