If you maintain enough WordPress sites, you start to recognise the same plugin category turning up in compromise after compromise. File manager plugins are at the top of that list. They are popular because they are useful. They are dangerous because they hand a powerful capability to whoever can reach them. And historically, several of the most widely installed file managers have had critical vulnerabilities that allowed unauthenticated remote code execution.
This article explains why file manager plugins are such a consistent attack vector, looks at a recent real Sydney agency compromise traced to one of them, and offers safer alternatives.
What file manager plugins do
A WordPress file manager plugin gives administrators a web based file browser inside the dashboard. From the admin panel, you can navigate directories, edit files, upload new ones, change permissions, and in some cases run server side commands. The use case is convenience. You can fix a misbehaving file without needing SFTP credentials or a separate file transfer tool.
The trouble is that this capability is so powerful that any flaw in the plugin gives an attacker exactly the same capability. If the plugin has a vulnerability that lets a request bypass the administrator check, the attacker has effectively been handed a web shell with full filesystem access.
The historical record
The wp-file-manager family in particular has a long and well documented history of critical vulnerabilities. The most famous was CVE-2020-25213, an unauthenticated remote code execution in the bundled elFinder library that affected millions of sites and was exploited at massive scale. Several follow up advisories have been published since for various forks and bundled versions.
This is not unique to one plugin or one author. The whole category struggles with the same problem. The bundled file management libraries are large, complex, and difficult to keep both feature complete and secure. When a vulnerability is found in the upstream library, it propagates through every WordPress plugin that bundles it.
A recent Sydney agency case study
In May 2026 we audited a Sydney agency site that had been compromised. The forensic audit identified fifteen malicious files dropped into the document root, organised into five directories that mirrored the names of real WordPress pages. The malicious files implemented an SEO cloaking attack, serving spam content to Googlebot while serving doorway HTML to human visitors.
The strongest suspect for the entry point was an outdated file manager plugin that had been installed and forgotten. The plugin had not been updated. The plugin family had multiple historic remote code execution advisories. The mechanism by which the malicious files were dropped was almost certainly an exploit of one of those vulnerabilities. The single most impactful preventive change for that site would have been removing the plugin entirely before the compromise.
Why people install these plugins in the first place
The motivation is always the same. Someone needed to fix a file, did not have SFTP set up, and installed a file manager from the plugin directory. The plugin worked, the fix was made, and the plugin stayed installed. Five years later, the original problem is long forgotten and the plugin is still active.
The convenience that motivated the install was a one off need. The attack surface it created is permanent for as long as the plugin remains on the site.
What to use instead
For nearly every use case a file manager plugin solves, there is a safer alternative.
SFTP. Every reputable WordPress host provides SFTP access. A free client like FileZilla or Cyberduck gives you the same file browsing and editing capability without exposing it to the public web. Authentication happens at the SSH layer, not as a plugin endpoint.
The hosting control panel. Most hosts have a file manager built into their control panel, accessible only after authenticating to your hosting account. This is much safer than a WordPress plugin because the access path is not on the public site URL.
SSH and wp cli. For technical users, command line access to your host gives you everything a file manager does and more, with no plugin exposed to the web.
The built in WordPress theme and plugin editor, if you must. WordPress itself includes a basic editor for theme and plugin files. It is not as full featured as a file manager plugin, and best practice is to disable it in wp-config.php with DISALLOW_FILE_EDIT, but it does cover the common case of editing a specific file without adding plugin attack surface.
If you absolutely need a file manager plugin
If your workflow truly requires a file manager plugin, treat it as a privileged tool. Install it only on the sites where it is genuinely needed. Keep it updated immediately on every release. Restrict access to it with additional measures, such as IP whitelisting or HTTP basic auth at the server layer. Deactivate or uninstall it the moment it is no longer needed.
Above all, do not leave it active on a site that has not been touched in months. An idle file manager plugin is a future incident waiting to happen.
The wider lesson
File manager plugins are the clearest example of a broader principle. Convenience and security are in tension. Anything that gives you a powerful capability through your site’s URL is also a powerful target if it has a flaw. The principle applies to backup plugins with web based restore, security plugins with full filesystem scanning, and any tool that exposes server side actions to authenticated requests.
For each of these, ask whether the capability needs to live on the site or whether it can live in a safer place. Often the answer is the safer place, and the WordPress plugin can be removed entirely.
Need a hand?
If you have a file manager plugin on your WordPress site and you are not sure whether you still need it, Smart Coding can review your workflow, set up safer alternatives, and remove the plugin cleanly. Get in touch and we will close one of the largest single doors that attackers use on WordPress sites.
