CVE-2026-15991: Authenticated arbitrary file deletion in WordPress File Manager
TL;DR - File Manager for WordPress 6.0 through 6.9 is vulnerable to authenticated arbitrary file read and deletion. - Subscriber-level users may be enough to exploit it via crafted requests to the plugin connector. - Patch now if exposed; active exploitation is not confirmed, but impact is high.
Vulnerability at a Glance
| Field | Value |
|---|---|
| CVE ID | CVE-2026-15991 |
| CVSS Score | 8.8 High |
| Attack Vector | Network-reachable web request to the plugin connector |
| Auth Required | Yes, authenticated; subscriber-level access and above |
| Patch Available | Yes, but the exact first fixed version was not confirmed from retrievable primary-source advisory text |
This vulnerability affects the WordPress plugin File Manager with plugin slug wp-file-manager. According to the NVD description, all versions from 6.0 through 6.9 are vulnerable. The issue lets an authenticated attacker read and delete arbitrary files on the server, with the reachable file scope reportedly rooted at WordPress ABSPATH.
The operational risk is higher than the wording “file deletion” might suggest. In WordPress environments, deletion of certain files such as wp-config.php can trigger installation or reconfiguration flows that may lead to site takeover or code execution conditions. Even without a public exploit being verified in the sources reviewed here, this is a strong candidate for urgent remediation because it combines low required privileges with high post-exploitation impact.
What Is This Vulnerability?
At its core, CVE-2026-15991 is an authorization and input-handling flaw in the File Manager plugin’s connector flow. The NVD description attributes the issue to insufficient file path validation in the connector function and, more importantly, to a mismatch in how commands are interpreted at different points in request processing.
The vulnerable behavior is triggered when an attacker sends a POST request but places the command in the URL query string instead of exclusively in the POST body. Specifically, the NVD states that passing cmd=rm or cmf=file in the query string of a POST request can bypass the expected permission enforcement. The reason is that the plugin’s bind registration logic reads the command from $_POST only, while the dispatcher later reads from merged $_GET + $_POST data and still executes the command.
That distinction matters because the expected rm.pre permission handler is never registered when the command is only seen in the query string during a POST. The dispatcher, however, still processes the command. In practice, that means an authenticated attacker can invoke file operations that should have been blocked or filtered by earlier controls.
The NVD further notes that the vulnerable volume defaults to ABSPATH, which is the WordPress installation root. That expands the impact beyond a confined upload directory and creates the possibility of reading or deleting application-critical files. If the attacker can remove configuration or other sensitive files, the result can go beyond availability loss and become a full compromise scenario.
Technical Notes
The vulnerable pattern described by NVD is conceptually similar to the following request shape:
POST /wp-admin/admin-ajax.php?page=file-manager&cmd=rm HTTP/1.1
Host: example.com
Cookie: wordpress_logged_in=...
Content-Type: application/x-www-form-urlencoded
target=l1_Lw&reqid=12345
The key element is that the command is supplied in the query string of a POST request, creating a mismatch between validation/bind logic and dispatch logic.
Who Is Affected?
The affected product is File Manager for WordPress, listed on WordPress.org as File Manager with plugin slug wp-file-manager. Based on the NVD record, the affected versions are all versions from 6.0 through 6.9. If you run any version in that range, you should treat the instance as vulnerable unless you have independently validated a backported fix.
The current plugin listing observed in the research notes shows version 8.0.4 on WordPress.org, which strongly suggests the issue is not present in the current branch. However, the exact first fixed version number for this CVE was not confirmed from retrievable primary-source advisory text in the available material. That means defenders should avoid claiming a precise remediation floor such as “fixed in 7.0” unless they have vendor release notes or code diffs in hand.
In practical terms, this affects organizations that allow lower-privileged WordPress accounts, including subscriber roles, on sites where File Manager is installed. That includes membership sites, e-commerce deployments, community portals, learning platforms, and any environment where user registration is enabled. If your threat model includes account takeover through credential stuffing or phishing, this bug becomes even more relevant because a compromised low-privilege account may be sufficient for exploitation.
Managed hosting and multisite administrators should also check for dormant or forgotten plugin installs. This is the kind of issue that may sit unnoticed because the plugin is present even if its file-management features are rarely used. If the plugin exists anywhere in the environment and the version falls between 6.0 and 6.9, it deserves immediate review.
CVSS Score Breakdown
The NVD lists this vulnerability at CVSS 8.8 High. The exact CVSS vector was not present in the returned NVD tool output, so it is important not to invent one. Still, the score is consistent with a vulnerability that is remotely reachable through a web interface, requires only low privileges, and can cause major integrity and confidentiality impact.
The available facts support that reading. The attack is carried out over HTTP against a WordPress plugin endpoint, so network reachability is implied. The privileges required are relatively low because subscriber-level access and above is enough according to the CVE description. The ability to read arbitrary files affects confidentiality, while the ability to delete arbitrary files affects integrity and availability. If deleting a key file enables site takeover or a code execution path, the practical risk to the business is significant.
Because no official vector string was returned in the source data, defenders should use the score as a severity indicator rather than relying on inferred metric values. In internal prioritization, the right conclusion is straightforward: low-privilege authenticated web bug plus arbitrary file operations plus possible follow-on takeover equals urgent remediation.
Exploitation Status
At the time of the research note, active exploitation in the wild is not confirmed from the sources provided. The CVE is not listed in the CISA Known Exploited Vulnerabilities catalog, which means there is no KEV-backed confirmation of exploitation at this time. That should not be read as proof of safety; it only means exploitation has not been publicly confirmed through that specific channel.
The same caution applies to exploit code. A public PoC was not confirmed in the retrieved sources. The note explicitly states that no clearly attributable public proof of concept for CVE-2026-15991 was verified during the research run. Therefore the correct wording is: no confirmed public PoC located in retrieved sources.
That said, the vulnerability appears operationally straightforward based on the root cause description. The request manipulation required is simple, the privilege threshold is low, and the impact is meaningful. In the absence of confirmed exploitation data, defenders should assume opportunistic abuse is plausible once details circulate more widely, especially on public-facing WordPress sites that permit user logins.
How to Detect It
Detection should focus on three areas: plugin inventory, suspicious authenticated requests to the plugin connector or AJAX endpoints, and file integrity anomalies involving critical WordPress files. Start by identifying every site running File Manager (wp-file-manager) and checking whether the installed version falls within 6.0 through 6.9. That is your highest-confidence detection step because version exposure is known even when exploitation evidence is not.
Next, review web server and WordPress logs for suspicious POST requests where the query string contains cmd=rm or cmf=file. The vulnerable behavior hinges on supplying these parameters in the URL query string of a POST request. Even if you cannot fully reconstruct a successful exploit, that request shape is uncommon enough to merit investigation, particularly when coming from subscriber accounts or newly created users.
Also inspect for follow-on indicators such as missing wp-config.php, unexpected recreation of installer flows, unexplained file deletion under the WordPress root, and access to plugin endpoints shortly before service disruption. If you use EDR or file integrity monitoring on the web server, look for delete events under the site root tied to the PHP-FPM, Apache, or Nginx worker context.
Technical Notes
Example Apache or Nginx access log grep for suspicious patterns:
grep -E 'POST .*cmd=rm|POST .*cmf=file' /var/log/nginx/access.log /var/log/apache2/access.log
A broader grep for File Manager related requests:
grep -Ei 'file-manager|wp-file-manager|admin-ajax\.php.*(cmd=rm|cmf=file)' /var/log/nginx/access.log
Example pseudo-Sigma style detection logic for web logs:
title: Possible exploitation of CVE-2026-15991
logsource:
category: webserver
detection:
selection_method:
cs-method: POST
selection_uri:
cs-uri-query|contains:
- "cmd=rm"
- "cmf=file"
condition: selection_method and selection_uri
level: high
Example Splunk search:
index=web sourcetype IN ("nginx","apache","iis")
method=POST ("cmd=rm" OR "cmf=file")
| stats count values(uri) values(user) values(src_ip) by host
If WordPress is installed via WP-CLI, enumerate the plugin version directly:
wp plugin list --path=/var/www/html | grep wp-file-manager
Mitigation and Patching
The safest mitigation is to upgrade the File Manager plugin to a non-vulnerable release immediately. What can be stated with confidence from the available evidence is that versions 6.0 through 6.9 are vulnerable and that the currently observed WordPress.org version is 8.0.4. What cannot be stated with confidence from the retrievable sources is the exact first fixed version for this CVE. If you need strict evidence for change-control purposes, validate the vendor changelog or code diff before documenting the precise fix floor.
In the absence of that explicit advisory text, the conservative operational recommendation is: upgrade to the latest available version from WordPress.org, which the research note observed as 8.0.4, provided it is compatible with your environment. If you cannot patch immediately, reduce exposure by disabling or removing the plugin, restricting WordPress login access, and reviewing whether subscriber registration is necessary on affected sites.
Because the issue requires authentication, compensating controls can help, but they should not be treated as a complete fix. Restricting new registrations, enforcing MFA for administrative users, and monitoring subscriber account creation can reduce exploitability. Still, any valid low-privilege account may be sufficient, so patching or temporary plugin removal remains the primary remediation path.
You should also plan for post-patch validation. Confirm the plugin version, inspect for deleted or altered files under the WordPress root, restore any missing critical files from backup, rotate secrets if wp-config.php or related files may have been exposed, and review logs for suspicious requests preceding the remediation window.
Technical Notes
Upgrade via WP-CLI:
wp plugin update wp-file-manager --path=/var/www/html
Verify installed version after upgrade:
wp plugin get wp-file-manager --field=version --path=/var/www/html
Temporarily deactivate the plugin if you cannot patch immediately:
wp plugin deactivate wp-file-manager --path=/var/www/html
If emergency removal is required:
wp plugin delete wp-file-manager --path=/var/www/html
Basic file check for critical WordPress config presence:
ls -l /var/www/html/wp-config.php
find /var/www/html -maxdepth 2 -type f | grep -E 'wp-config\.php|\.php$'
If you run a WAF or reverse proxy, consider a temporary rule to alert or block suspicious POST requests carrying the vulnerable command pattern in the query string:
Condition: HTTP method = POST AND query string contains "cmd=rm" OR "cmf=file"
Action: block or challenge, then log at high severity
References
The primary authoritative source for this CVE is the NVD entry, which describes the affected versions, attack prerequisites, root cause, and impact. It explicitly identifies the vulnerable plugin as the WordPress File Manager plugin and states the vulnerable range as 6.0 through 6.9. It also describes the GET/POST command parsing mismatch that enables the permission bypass.
The product identity and current plugin listing information were verified from the official WordPress.org plugin page for File Manager with slug wp-file-manager. The current observed version in the research notes was 8.0.4, but again, that source alone does not prove the exact first fixed version for this specific CVE. For defenders who need patch provenance, the next step is to review WordPress plugin Trac changesets or vendor release notes directly.
Technical Notes
Primary references:
- NVD CVE record: https://nvd.nist.gov/vuln/detail/CVE-2026-15991
- CISA KEV catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
- WordPress.org plugin page: https://wordpress.org/plugins/wp-file-manager/
- WordPress.org plugin metadata output: https://wordpress.org/plugins/wp-file-manager/?output_format=md
NVD-listed code reference URLs associated with the issue:
- https://plugins.trac.wordpress.org/browser/file-manager/tags/6.9/backend/app/Http/Controllers/FileManagerController.php#L32
- https://plugins.trac.wordpress.org/browser/file-manager/tags/6.9/backend/app/Http/Controllers/FileManagerController.php#L34
- https://plugins.trac.wordpress.org/browser/file-manager/tags/6.9/backend/app/Providers/AccessControlProvider.php#L121
- https://plugins.trac.wordpress.org/browser/file-manager/tags/6.9/backend/hooks/ajax.php#L10
- https://plugins.trac.wordpress.org/browser/file-manager/tags/6.9/vendor/studio-42/elfinder/php/elFinder.class.php#L802
For more information on software supply chain security basics, visit our guide on Software Supply Chain Security Basics. If you want to learn about the importance of cloud security posture management, check out our article on What is Cloud Security Posture Management?.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.