There is a particular kind of irony in a security plugin becoming the thing that gets your site hacked. That is exactly the situation WordPress site owners faced in March 2025, when researchers disclosed a critical vulnerability in WP Ghost (also known as Hide My WP Ghost), a popular hardening and firewall plugin installed on more than 200,000 sites. Tracked as CVE-2025-26909 and rated CVSS 9.6, the flaw allowed an unauthenticated attacker to include arbitrary files on the server and, in most real-world configurations, escalate that to full remote code execution. In plain terms: no login required, and the payoff is complete control of the site. If you run WP Ghost, this is one to take seriously.
CVE details at a glance
- CVE ID: CVE-2025-26909
- Plugin: WP Ghost / Hide My WP Ghost (slug: hide-my-wp)
- Active installations: 200,000+
- Vulnerability type: Unauthenticated Local File Inclusion (LFI), escalating to Remote Code Execution (RCE)
- CVSS score: 9.6 (Critical)
- Affected versions: All versions up to and including 5.4.01
- Patched version: 5.4.02 (later releases such as 5.4.03 also include the fix)
- Disclosed: March 2025, by Patchstack security researcher Rafie Muhammad
How the vulnerability works
Local File Inclusion is a class of bug where an application can be tricked into loading a file whose path is controlled by the attacker. In PHP, when that included file contains code, the server executes it. That is the bridge from “read a file you shouldn’t” to “run code you shouldn’t,” and it is why LFI in a PHP application is so dangerous.
WP Ghost has a feature that serves files based on rewritten, obfuscated URLs, part of how it hides the real structure of a WordPress install. When a visitor requested a page that did not exist (a 404), the plugin would take the requested URL, translate it back to an original path, and then include that path as a file. The problem was that the URL came straight from the incoming request, by way of the getCurrentURL() function, and was passed down through the plugin’s showFile() logic to a PHP include statement without adequate validation or sanitization.
Because the value was attacker-controlled and unchecked, a request could contain path traversal sequences and special PHP stream wrappers to point the include at a file of the attacker’s choosing. Researchers noted that well-known techniques such as php:// filter chains and the PHP_SESSION_UPLOAD_PROGRESS trick could turn this file inclusion into arbitrary code execution on nearly any typical server setup. Crucially, none of this required authentication: the vulnerable code path was reachable by any anonymous visitor hitting a non-existent URL.
One important nuance: exploitation depended on the plugin’s Change Paths feature being set to Lite or Ghost mode. That setting is not enabled by default, so not every install was exposed. But these are exactly the modes many people turn on, because path-changing is one of the main reasons to run WP Ghost in the first place. If you enabled that feature, you were very likely in the affected group.
Real-world impact
Remote code execution is about as bad as WordPress vulnerabilities get. Once an attacker can run PHP on your server, the site is no longer yours in any meaningful sense. Practically, that opens the door to installing a persistent backdoor or web shell, creating rogue administrator accounts, exfiltrating your database (including user records and password hashes), injecting spam or malicious redirects, planting SEO spam, using your server to attack others, or deploying ransomware-style defacement. Because the flaw was unauthenticated, it is the kind of bug that automated botnets love: they can spray requests across large numbers of sites without needing to guess credentials or hold any account.
The combination of a large install base, a trivial trigger (just an HTTP request), and a high-value outcome (code execution) is exactly the recipe that draws mass exploitation attempts once details become public. Even where a specific configuration was not vulnerable, the disclosure was a strong signal to patch immediately rather than wait to find out.
How to check if you’re affected
Start by confirming whether the plugin is installed and which version you are running. In your WordPress dashboard, go to Plugins > Installed Plugins and look for “WP Ghost” or “Hide My WP Ghost.” Check the version number listed beneath the plugin name.
- If the version is 5.4.01 or lower, you are running vulnerable code and should update right away.
- If the version is 5.4.02 or higher, you already have the patched code.
- To gauge your exposure, check the plugin’s Change Paths setting. If it is set to Lite or Ghost mode on an unpatched version, treat the site as actively exposed and prioritize the fix.
If you manage several sites, this is a good moment to inventory them all rather than checking one at a time. A single unpatched install is enough to cause a serious incident.
How to fix it
The fix is straightforward: update WP Ghost to version 5.4.02 or later. The vendor patched the flaw by adding proper validation on the user-supplied URL and path before it reaches the file inclusion logic, so untrusted input can no longer steer the include.
- In your dashboard, go to Plugins > Installed Plugins, find WP Ghost, and click Update now. If an update prompt is not showing, use Dashboard > Updates and check for available plugin updates.
- After updating, confirm the version reads 5.4.02 or higher.
- If you cannot update immediately, a temporary mitigation is to switch the Change Paths feature to Default mode, which removes the vulnerable code path, until you can apply the patch.
Beyond the update itself, a few hardening steps reduce the blast radius of this class of bug. Keep automatic updates enabled for plugins where you can, so critical patches land without waiting on a manual check. Run a reputable web application firewall so that known exploit patterns can be blocked at the edge even before you patch. If your unpatched site was internet-facing with the vulnerable configuration for any length of time, assume it may have been probed: review your list of administrator accounts for any you don’t recognize, scan for unfamiliar PHP files in wp-content/uploads and elsewhere, check for unexpected scheduled tasks, and rotate passwords and secret keys if anything looks off. When in doubt after a critical RCE exposure, a clean restore from a known-good backup is the safest path.
The takeaway
CVE-2025-26909 is a useful reminder that security software is still software, and every plugin you add, even a protective one, is part of your attack surface. That is not a reason to avoid security plugins; WP Ghost’s developers disclosed and patched this responsibly, which is exactly how the process should work. The real lessons are the boring, durable ones: keep everything updated, turn on automatic updates for critical fixes, understand which optional features you have enabled and what they expose, and keep reliable backups so recovery is an option rather than a crisis. A vulnerability becomes a breach mostly in the gap between disclosure and patching. Closing that gap quickly is the single most valuable security habit a WordPress site owner can build.
