CVE-2026-0740: Ninja Forms File Upload Vulnerability Still Exposing 50,000 WordPress Sites
A WordPress plugin used on roughly 50,000 sites contains a CVSS 9.8 critical remote code execution vulnerability. A patch shipped on March 19 — but most sites haven't applied it. And the first patch attempt didn't actually fix the bug.
This is CVE-2026-0740, an unauthenticated arbitrary file upload flaw in the Ninja Forms — File Uploads plugin. If your site uses it, the next 10 minutes determine whether you're already compromised, vulnerable, or finally safe.
The bug, in three sentences
Ninja Forms File Uploads validates the file extension on the source filename (the one the user submitted), but not the destination filename (where the plugin actually saves it).
An attacker submits a multipart form-data POST with a PHP web shell disguised as image.png in the visible upload field, while injecting a path-manipulating destination filename in a parallel parameter. The source check sees .png and approves; the file lands on disk as shell.php.
From there: one HTTP request to https://victim.com/wp-content/uploads/.../shell.php?cmd=id and the attacker has shell-level access to the WordPress server. No login required.
Developer reviewing code on a laptop screen — investigating a vulnerability disclosureThe "partial patch" trap
Ninja Forms first tried to fix this in version 3.3.25. That patch added validation but missed an alternative path manipulation vector — the bug remained exploitable.
Version 3.3.27 (released March 19, 2026) is the first build that actually closes the hole. Anyone who saw "patch available", upgraded to 3.3.25, and ticked the task off their list is still vulnerable.
Check yours via WordPress admin → Plugins, or run from the site root:
wp plugin list --name=ninja-forms-uploads --format=csv
# or
grep "Version:" wp-content/plugins/ninja-forms-uploads/*.phpIf the version starts with 3.3. and the third digit is anything below 27, you are exposed.
How to check if you've been compromised
Patching closes the door. It does not tell you whether someone walked through it during the 7+ weeks the patch has existed but wasn't applied.
The forensic indicators specific to this exploit:
- Any
.phpfile inside/wp-content/uploads/. The uploads directory should never contain executable PHP. Search:
Anything returned is suspicious. Anything returned with a recent modification time is almost certainly a web shell.find wp-content/uploads -name "*.php" -type f - Suspicious POSTs to
/wp-admin/admin-ajax.phpwith actionnf_fu_uploadoriginating from non-customer IPs. - Files with double extensions like
image.png.phporupload.jpg.php— the path-manipulation signature. - WordPress admin users you don't recognise. Common follow-up after a webshell is established: create a fallback admin account.
- Outbound connections from your web server to unfamiliar IPs. Web shells often phone home or beacon for command-and-control.
If any of those turn up, treat the site as compromised. The full incident response process — isolate, snapshot, restore from a clean pre-breach backup, rotate every credential — is covered in our 24-hour recovery guide.
Why patches alone don't save you
The uncomfortable lesson from CVE-2026-0740 isn't that Ninja Forms had a bug — every plugin will, eventually. The lesson is the gap between disclosure and patching:
- Patch released: March 19, 2026
- Sites with auto-update enabled and on plugin tier 3.3.27+: maybe 30%
- Sites still exposed today, almost two months later: 50,000+
Even a perfectly diligent admin who updates weekly is exposed for up to seven days after each new disclosure. Plugins from less-active maintainers can sit on a "partial patch" for weeks. And there's always the next CVE.
This is exactly the gap a real-time pattern-matching firewall closes. The CVE-2026-0740 exploit has a fingerprint at the HTTP layer — a multipart form-data POST containing both a fake-extension primary upload AND a path-manipulating destination parameter, hitting nf_fu_upload. That request shape is detectable and blockable before it reaches the plugin's vulnerable code, regardless of whether the plugin is patched.
Computer hardware close-up — representing depth-of-defence securityOur Obsyde Aegis plugin pattern-matches exactly this class of attack at the request layer. It blocks malicious file upload attempts whether or not the underlying plugin is current. The signature catches the attempt; the patch closes the bug. Defence-in-depth, not either/or.
What to do in the next ten minutes
- Check whether you have Ninja Forms File Uploads installed. WordPress admin → Plugins. If yes, continue.
- Verify the version is 3.3.27 or higher. If lower, update immediately.
- Run the find command above across
wp-content/uploads/. Investigate any PHP files returned. - Search access logs for POST requests to
admin-ajax.phpwithaction=nf_fu_uploadcoming from outside your customer geography. - If anything looks wrong, isolate the site immediately and follow the recovery checklist.
- Enable plugin auto-updates for everything that supports it. Run weekly checks for plugins that don't.
- Consider a real-time WAF as the layer between vulnerable code and the internet — for the next CVE that lands, not just this one.
The bigger picture
Plugin vulnerabilities now account for roughly 96-97% of all WordPress compromises, per Patchstack's 2026 data. CVE-2026-0740 is one of dozens disclosed every month. The specific bug will be patched and forgotten by July. The pattern of "plugin disclosed → patch shipped → 50,000 sites still vulnerable two months later" repeats, every month, indefinitely.
Two ways to operate inside that reality:
- Patch within 24 hours of every disclosure, audit forensically, hope you catch every plugin you run, and never miss one.
- Run a real-time signature layer that catches the attack pattern at the HTTP edge — independent of whether any individual plugin is current.
Most WordPress site owners default to option 1 and routinely fall behind. Option 2 isn't a substitute for patching, but it makes the gap survivable.
References
Related Insights
CVE-2026-8713: Avada Builder Flaw Lets Anyone Delete Your WordPress Files (1 Million Sites at Risk)
A critical CVSS 9.1 vulnerability in the Avada Builder WordPress plugin lets unauthenticated attackers delete arbitrary files — including wp-config.php — leading to full site takeover. Roughly one million sites were exposed before the patch in version 3.15.4. Here's how it works, who's affected, exactly how to fix it, and how to check whether your site has already been hit.
10 min read
WordPress Security in 2026: The CVEs Putting Sites at Risk — and the Managed Protection That Stops Them
The WordPress CVEs hitting sites in 2026 — Ninja Forms, cPanel and NGINX — and why handing your site to a managed security company beats chasing every vulnerability yourself.
7 min read
CVE-2026-42945: 18-Year-Old NGINX Rewrite Module Flaw Puts a Third of the Web at Risk
CVE-2026-42945 — NGINX Rift — is a CVSS 9.2 heap buffer overflow undetected for 18 years. Affects every NGINX from 2008 onwards. Patches, exploit trigger, what to do tonight.
6 min read