CVE-2026-0740

What it actually does

Ninja Forms - File Uploads for WordPress versions up to and including 3.3.26 fail to enforce sufficient file type validation in NF_FU_AJAX_Controllers_Uploads::handle_upload. Because the upload handler is reachable without authentication, a remote attacker can submit crafted upload requests and place arbitrary files on the web server. If the uploaded file is stored in a web-accessible location and executable file types such as PHP are accepted or can bypass filtering, the issue can lead to remote code execution with the privileges of the web server process. Successful exploitation can also enable web shell placement, content tampering, credential theft from WordPress configuration files, plugin/theme modification, and persistence across normal application restarts.

Why it matters to the business

A vulnerable public WordPress site can be fully compromised without valid credentials. Operational consequences may include website defacement, malware or phishing content hosted from the trusted domain, theft of customer or administrator data, search-engine blocklisting, disruption to online forms or business workflows, and pivoting into connected hosting infrastructure. The risk is elevated because the CVSS score is critical, EPSS is high at 0.57807, exploitation is reported as weaponized, and the issue has been public for 125 days, giving attackers ample time to automate scanning and exploitation even though it is not currently listed in CISA KEV.

How an attack unfolds

An attacker first identifies a WordPress site running the Ninja Forms - File Uploads add-on at a vulnerable version. They then send an unauthenticated multipart upload request to the plugin's upload handling path, abusing the missing or incomplete file type validation in the upload controller. Instead of a permitted document or image, the attacker uploads a server-executable payload such as a PHP web shell or a file crafted to bypass weak extension or MIME checks. If the server stores the file under a web-accessible uploads directory and executes it, the attacker requests the uploaded file directly to run commands. From there, they can enumerate the WordPress installation, read configuration files, access database credentials, create administrator users, modify plugins or themes for persistence, exfiltrate data, or use the compromised site to host additional malicious content.

How to fix it

Upgrade Ninja Forms - File Uploads to version 3.3.27 or later. Version 3.3.25 only partially addressed the issue and should not be considered sufficient. If immediate upgrade is not possible, disable the Ninja Forms - File Uploads plugin, restrict unauthenticated access to upload functionality, and block execution of scripts from WordPress upload directories at the web server layer. Enforce an allowlist of permitted file extensions and MIME types, randomize stored filenames, store uploads outside the web root where possible, and ensure the web server does not execute PHP, CGI, Perl, Python, or other script types from upload paths. Review all existing uploaded files for executable content because patching prevents new exploitation but does not remove already-uploaded web shells.

How to confirm the fix worked

Confirm the installed Ninja Forms - File Uploads version is 3.3.27 or later through the WordPress admin plugin inventory, wp-cli, or filesystem plugin metadata. Verify that the upload endpoint rejects executable extensions and disguised executable files, including double extensions and mismatched MIME types. Confirm web server configuration prevents execution in wp-content/uploads and any Ninja Forms upload subdirectories. Review the filesystem for PHP or other executable files under WordPress upload locations. If a web application firewall or reverse proxy is in use, validate that unauthenticated multipart requests attempting to upload executable files to WordPress AJAX endpoints are blocked or alerted.

Typical attack path

1. Scan the internet for WordPress sites exposing Ninja Forms functionality or plugin assets associated with Ninja Forms - File Uploads.
2. Determine whether the File Uploads add-on appears to be version 3.3.26 or earlier, or simply attempt exploitation against exposed upload endpoints.
3. Submit an unauthenticated multipart/form-data request to the plugin upload handler with a disallowed or executable file type.
4. Confirm that the uploaded file was accepted and determine the resulting URL or filesystem location under the WordPress uploads area.
5. Request the uploaded payload from the web server to verify execution or to interact with a web shell.
6. Use the foothold to read WordPress configuration, harvest credentials, create persistence, alter site content, or pivot further into the hosting environment.
7. Clean up obvious upload traces or blend the payload into normal media or plugin directories to avoid detection.

How to detect it

Investigate whether exploitation has already occurred by correlating web access logs, WAF logs, WordPress logs, file integrity monitoring, hosting control-panel logs, and endpoint telemetry from the web server. Look for unauthenticated multipart/form-data POST requests to WordPress AJAX endpoints or Ninja Forms upload handlers, especially requests containing executable file extensions, double extensions, suspicious MIME types, or unusual filenames. Follow those events with filesystem review for newly created files under wp-content/uploads, Ninja Forms upload directories, or other web-accessible media paths. High-confidence signs include PHP files in upload directories, web requests to those uploaded PHP files, command-execution parameters in query strings or POST bodies, unexpected child processes spawned by the web server user, and recent modification of WordPress plugin/theme files. Also review for creation of new WordPress administrator accounts, changes to wp-config.php, injected code in theme files, suspicious scheduled tasks or cron jobs, outbound connections from the web server to unfamiliar IPs, and malware/phishing files placed under the site document root.

• NF_FU_AJAX_Controllers_Uploads::handle_upload
• POST /wp-admin/admin-ajax.php
• multipart/form-data
• action=nf_fu_upload
• /wp-content/uploads/
• /wp-content/uploads/ninja-forms/
• .php
• .phtml
• .php5
• .phar
• .shtml
• .cgi
• .pl
• .asp
• .aspx
• .jsp
• .php.jpg
• .php.png
• GET /wp-content/uploads/
• POST /wp-content/uploads/
• <?php
• eval(
• base64_decode(
• shell_exec(
• system(
• passthru(
• proc_open(
• popen(
• assert(
• cmd=
• whoami
• uname -a
• /bin/sh
• /bin/bash
• wp-config.php
• wp-content/plugins/ninja-forms-uploads
• wp-content/plugins/ninja-forms-file-uploads

What your security team should do

• Immediately upgrade Ninja Forms - File Uploads to 3.3.27 or later on all WordPress sites; do not rely on 3.3.25 as a complete fix.
• Treat exposed vulnerable sites as potentially compromised because exploitation is weaponized and the issue has been public for more than four months.
• Search web roots and upload directories for unexpected executable files, especially PHP files in wp-content/uploads and Ninja Forms upload paths.
• Disable script execution in upload directories using web server configuration such as Apache .htaccess, Nginx location rules, or hosting control-panel equivalents.
• Review access logs for unauthenticated multipart POST requests to WordPress AJAX endpoints followed by GET requests to newly uploaded files.
• Rotate WordPress administrator credentials, database credentials, and hosting credentials if evidence of web shell execution or unauthorized file modification is found.
• Add SIEM and WAF detections for executable file uploads to WordPress endpoints and for execution of PHP files from upload directories.
• Back up evidence before cleanup if compromise is suspected, then remove malicious files, reinstall plugins/themes from trusted sources, and verify WordPress core integrity.