CVE-2026-118423: WP Libre Form Unauthenticated RCE

Detection Guidance

Start by identifying every WordPress site with WP Libre Form installed, then determine whether the installed version is 1.5.0.1. Review:

• WordPress administration data.
• Plugin directories.
• Software inventories.
• Deployment manifests.
• Backup and staging environments.
• Upload directories associated with the plugin.

Compare upload-directory contents with known-good backups or file-integrity baselines. Pay particular attention to unexpected PHP files, recent file creation times, and files owned by the web-server account.

The most useful indicators include:

• Unexpected PHP files in upload locations.
• POST requests to form or upload endpoints.
• Subsequent requests for newly created scripts.
• Changes to wp-config.php.
• Unexpected WordPress administrator accounts.
• Modified plugin or theme files.
• New cron jobs or scheduled tasks.
• Web-shell-like files.
• Outbound connections initiated by the web server.

Linux File Searches

The following command searches common WordPress locations for PHP and related script files:

find /var/www -type f \
  \( -path '*/wp-content/uploads/*' -o -path '*/wp-content/plugins/*' \) \
  \( -iname '*.php' -o -iname '*.phtml' -o -iname '*.php[0-9]' \) \
  -printf '%TY-%Tm-%Td %TH:%TM:%TS %u %p\n' \
  2>/dev/null

Adapt the path to the actual document root. Preserve suspicious files for analysis rather than immediately executing or deleting them.

Web-Log Review

A generic web-log search can identify upload attempts and requests for PHP files:

zgrep -hEi \
  'POST .*upload|POST .*form|multipart/form-data|/wp-content/uploads/.*\.(php|phtml)(\?|[[:space:]])' \
  /var/log/nginx/access.log* /var/log/apache2/access.log* 2>/dev/null

Look for a sequence in which an external address submits a multipart request, the server returns a success or redirect response, and the same or another address requests a newly created PHP file.

Splunk-Style Query

index=web
(method=POST OR uri_path="*wp-content/uploads*")
(uri_query="*upload*" OR http_content_type="multipart/form-data"
 OR match(uri_path, "\.(php|phtml)(/|\?|$)"))
| stats count min(_time) as first_seen max(_time) as last_seen
  values(src_ip) as source_ips values(uri_path) as paths
  by host status

If unauthorized PHP execution is confirmed, treat the host as potentially compromised and begin incident response rather than performing only plugin cleanup.

Remediation and Patching

The primary action is to disable or remove WP Libre Form version 1.5.0.1 from internet-facing WordPress sites.

No verified fixed version is identified in the available NVD record or retrieved WPScan reference. Do not claim remediation by upgrading to an unverified version. Before re-enabling the plugin, obtain a trusted upstream release that explicitly addresses the upload-validation flaw and verify its version, provenance, and behavior.

If the plugin is not required, removal is preferable to leaving it disabled but present. If the site must retain the functionality temporarily:

• Restrict access to relevant form and upload endpoints.
• Enforce authentication where operationally possible.
• Apply web-application-firewall or network controls.
• Prevent script execution in upload directories.
• Monitor logs and file creation events closely.

These are compensating controls, not substitutes for removal or a verified security update.

WP-CLI Deactivation and Removal

For a standard WordPress installation:

wp plugin deactivate wp-libre-form --path=/var/www/html
wp plugin delete wp-libre-form --path=/var/www/html

The plugin slug may differ from the directory name in a specific deployment. Confirm the installed slug first:

wp plugin list --path=/var/www/html

Before removal, preserve relevant logs and the plugin directory if an investigation may be required. Take a backup or snapshot, but do not restore potentially malicious files into production without inspection.

Apache Upload-Directory Protection

The exact Apache configuration depends on the PHP integration and distribution. A commonly used baseline is:

# Place in the applicable uploads directory configuration.
<FilesMatch "\.(php|phtml|php[0-9])$">
    Require all denied
</FilesMatch>

Nginx Upload-Directory Protection

Ensure that requests under the uploads path are not passed to PHP-FPM:

location ~* ^/wp-content/uploads/.*\.(php|phtml|php[0-9])$ {
    deny all;
    return 404;
}

Validate configuration syntax and reload through the organization’s normal change process:

sudo nginx -t && sudo systemctl reload nginx
# or, for Apache:
sudo apachectl configtest && sudo systemctl reload apache2

Configuration behavior varies by deployment. Test that legitimate media remains accessible while PHP requests in upload directories return a denial or not-found response.

Review filesystem permissions as well. The web process should not be able to write executable application code wherever possible.

Incident Response Considerations

If suspicious uploads or code execution are found:

1. Isolate the affected host or site where practical.
2. Preserve logs, suspicious files, hashes, timestamps, and ownership data.
3. Capture a disk or virtual-machine snapshot when feasible.
4. Rotate WordPress, database, hosting, SSH, and API credentials.
5. Inspect for persistence, modified files, new accounts, and scheduled tasks.
6. Rebuild from a known-good source when compromise is confirmed or cannot be reliably scoped.
7. Review connected systems for lateral movement or stolen credentials.

Removing one malicious file does not establish that the attacker lacked additional access.

Administrators should also review broader identity exposure, including non-human accounts and service credentials. The non-human identity definition and security guide provides useful context for assessing service-account risk after a server compromise.

References

• NVD: CVE-2026-118423
• WPScan: WP Libre Form 1.5.0.1, unauthenticated RCE via arbitrary file upload
• CISA Known Exploited Vulnerabilities Catalog

The available references identify WP Libre Form 1.5.0.1 as affected but do not identify a fixed version, CVSS vector string, public proof of concept, or confirmed exploitation in the wild. Organizations should monitor the NVD, project advisories, vendor channels, and trusted threat-intelligence sources for updates before deciding whether a later release is safe to deploy.

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.