Top/Articles/Ninja Forms: seven flaws, one lets buyers pay zero. Update to 3.15.0
ninja-forms-cve-cover-en-update

Ninja Forms: seven flaws, one lets buyers pay zero. Update to 3.15.0

Ninja Forms, a WordPress form-builder used on 600,000+ sites, has two flaws rated 9.3. CVE-2026-65048 can take over an administrator from a form submission with no login; CVE-2026-65049 can bulk-delete all form data on multisite. Fix 3.14.9 (latest 3.14.10) is out — here's how to update and confirm you're safe.

NewsPublished July 22, 2026Last updated Aug. 13, 2026
Table of contents
Key takeaways

Ninja Forms, a WordPress form-builder used on 600,000+ sites, has two flaws rated 9.3. CVE-2026-65048 can take over an administrator from a form submission with no login; CVE-2026-65049 can bulk-delete all form data on multisite. Fix 3.14.9 (latest 3.14.10) is out — here's how to update and confirm you're safe.

Between July and August 2026, seven vulnerabilities were disclosed in Ninja Forms, the WordPress form-builder plugin. They include one that hands over an administrator account to someone who never logs in, and one that lets an attacker rewrite a payment amount down to zero. The plugin runs on more than 600,000 sites worldwide.

Here is the conclusion up front. The version you want is 3.15.0, released on August 12, 2026. At various points along the way the advice was "3.14.9 fixes it" or "3.14.10 is fine" — neither is sufficient today. Version 3.14.12 added a further database-related fix with no CVE attached to it, so going all the way to the latest release is the one answer that leaves nothing behind.

The short version

  • Seven vulnerabilities were disclosed across July and August 2026. The most severe is CVE-2026-65048 at 9.3, which can lead to an administrator takeover with no login required
  • The one that costs money directly is CVE-2026-65052: rewrite a form's calculated total and pay zero
  • Closing all seven takes 3.14.10 or later. But because 3.14.12 carries an extra fix with no CVE number, 3.15.0 is the safe target
  • No real-world attacks have been reported, and none of the seven appear on the US CISA exploited-vulnerabilities list. Nothing is forcing your hand, but there is no reason to sit on this either

Which version is actually safe

You can find the version you are running on the "Plugins" screen in the WordPress dashboard. Match that number against the table below.

Your versionWhat is still openWhat to do
3.14.8 or earlierAll seven
(admin takeover and payment tampering included)
Update to 3.15.0
3.14.9Two
(the SQL issue and shortcode execution)
Update to 3.15.0
3.14.10 / 3.14.11No disclosed CVEs
remaining
Update to 3.15.0
(for the extra SQL fix)
3.14.12NoneUpdate to 3.15.0
(new features only)
3.15.0NoneNothing to do

The dividing line is whether you stopped at 3.14.9. In late July, advisories all over the place said "update to 3.14.9," so a fair number of site operators updated once and considered the matter closed. Two vulnerabilities found after that point are still open in 3.14.9.

With 3.14.10 or 3.14.11, every disclosed CVE is closed. But the 3.14.12 changelog lists a security item described as hardening of SQL query handling, with no CVE number and no detailed writeup attached. There is no upside to leaving an unexplained fix out of your install, so going straight to the latest release is the quickest way to stop thinking about it.

For the record, the latest release, 3.15.0, adds an "AI Form Builder" that generates forms from plain-language instructions. It contains no security fixes, but nothing in it is a reason to hold back from updating either.

The seven disclosed vulnerabilities

Severity here is CVSS, the common scale that rates how serious a flaw is from 0 to 10. There are two generations of the scoring criteria, and the same flaw can score differently under each, so both numbers are listed.

CVEWhat it allowsSeverity
(new / old scale)
PreconditionFixed in
CVE-2026
-65048
Take over an admin
from a form submission
9.3 / 9.3No login needed3.14.9
CVE-2026
-65052
Rewrite the amount due
down to zero
8.7 / 7.5No login needed3.14.9
CVE-2026
-65049
Bulk-delete the form data
of every site in a network
8.4 / 9.3Subsite admin
privileges
3.14.9
CVE-2026
-65050
Expose collected submissions
to ordinary visitors
7.1 / 6.5Author role3.14.9
CVE-2026
-65051
Walk straight past every input check
(CAPTCHA included)
6.9 / 6.5No login needed3.14.9
CVE-2026
-15663
Slip rogue commands
into the database
— / 4.9Administrator privileges3.14.10
CVE-2026
-15256
Make the site run commands
written into a URL
— / 4.8No login needed
(conditions apply)
3.14.10

The first five were disclosed on July 21, 2026, CVE-2026-15663 on July 24, and CVE-2026-15256 on August 6. What makes this case confusing is that the order of disclosure does not match the order of the fixes: the last of the seven is a problem that had already been fixed in 3.14.10 and only received a number nearly three weeks later.

Note also that some sources list 3.14.10 as the fixed version for the five disclosed on July 21. The public vulnerability databases record 3.14.9 as the fix, and that discrepancy alone makes it harder to answer "how far do I need to go?" Updating to the latest release means you never have to work out which source is right.

Who goes after this, and what for

The people who exploit the members of this set that anyone can reach from outside are attackers who sweep the web for sites running an old Ninja Forms and fire crafted strings through their contact forms. They are not picking famous targets. A small-business site or a personal site with an "inquiry" or "request information" form gets caught on exactly the same terms.

What they do with it splits into two broad categories. One is planting code inside a submission so that it runs the moment the site owner opens the dashboard. The other is rewriting the amount being submitted so that an order goes through without payment. The first leads to a takeover; the second leads straight to lost revenue.

The damage does not stop with the site's owner. A hijacked site gets used as a springboard to redirect visitors to fake pages, or gets fitted with code that skims the personal data people type in. The names, email addresses, and messages left in a form are, to the people who sent them, information they never wanted a stranger to see. From the operator's side, there is also the risk of losing an accumulated archive of inquiries and orders. WordPress core itself has had flaws that lead to site takeover, so patching only the plugin leaves the job half done.

A closer look at the three with the biggest impact

CVE-2026-65048: code planted in a form runs inside the dashboard

This is the most severe of the seven, rated 9.3. The flaw sat in the Repeatable Fieldset feature, which lets a visitor fill in the same set of inputs more than once. The internal routine that handled the ordering of each submitted field accepted arbitrary strings without checking that the value was a number, and then embedded that value directly into the dashboard's HTML.

This class of defect is called stored cross-site scripting: code sent by an attacker is saved on the server, and later runs unbidden in the browser of whoever displays that content. In this case, an outsider who is not logged in can plant it simply by submitting the form, and it then runs with the site owner's privileges the instant that owner performs the everyday act of reviewing an incoming inquiry. Once it runs, it can go as far as hijacking the administrator's logged-in session, quietly creating a new administrator account, or installing malicious code on the site.

The fix shipped in 3.14.9. It was found by Pavel Kohout of Aisle Research, who reported all five of the vulnerabilities disclosed on July 21.

CVE-2026-65052: set the amount to zero and the order still goes through

This is the one whose real-world consequences are easiest to picture. Ninja Forms can calculate a total based on the options a visitor selects, and paired with a payment plugin it gets used for signup forms and simple order forms. The internal routine that produced that total did not stop with an error when it received an unexpected value — it simply carried on. It failed open rather than closed.

The result is that anyone, without logging in, can tamper with the submitted data and rewrite the amount they owe. They can push the total to zero and still have the order accepted, because nothing on the server side re-derives the correct price. For any site taking paid signups, selling products, or accepting donations through Ninja Forms, this one issue alone justifies the update. Severity is 8.7 on the newer scale and 7.5 on the older one. The fix shipped in 3.14.9.

CVE-2026-65049: form data across every site wiped in one shot

This one matters in a multisite setup, where several sites run under a single WordPress installation. Operations that affect the whole network should be reserved for the top-level administrator, but Ninja Forms' permission check only looked at privileges scoped to an individual site. As a result, someone who is merely the administrator of one subsite can send a crafted request and bulk-delete the Ninja Forms data of every site on the network.

Form definitions and every inquiry or order record collected to date can be lost together. Severity is 9.3 on the older scale and 8.4 on the newer one. The newer score is a little lower because the attack requires subsite administrator privileges, but that does not change what you need to do. The fix shipped in 3.14.9.

The two that 3.14.9 does not fix

This is the part that gets missed most often. If you only followed the advice of the time and updated to 3.14.9, two issues are still open. Both are fixed in 3.14.10.

CVE-2026-15663: reaching the database through the import feature

In the import feature that loads form definition files, the key names of settings were passed straight into a database query. This is SQL injection: mixing rogue strings into the commands sent to a database in order to pull out or alter data that should not be reachable. Every version up to and including 3.14.9 was affected.

The attack does, however, require administrator privileges. It is not something an outsider can pull off alone, which is why severity stops at 4.9. Think of it as a second-stage tool for widening the damage once an administrator account has already been taken through some other flaw or a leaked password.

CVE-2026-15256: making the site run commands written into a URL

This one only received its number on August 6, 2026. The 3.14.10 changelog had long carried a line about blocking unauthenticated shortcode execution, so it was clear that something had been fixed, but nearly three weeks passed before the details were published.

A shortcode is the WordPress mechanism where writing a short snippet such as [ninja_form id=1] into a post or page calls up the corresponding feature. In principle only people with editing rights on the site should be able to use it.

The problem arises when a form is configured to prefill its fields from a string appended to the URL. If such a form sits on a public page, the string in the URL gets processed as a shortcode, letting someone who is not logged in run any shortcode registered on the site. The WPScan advisory that reported it goes as far as publishing working reproduction steps.

Severity is a modest 4.8. The attack only works if the form carries a particular configuration, and what can be executed is limited to shortcodes already registered on that site. Even so, no login required, plus published reproduction steps is not a combination to shrug off. The US CISA also rates this particular issue as having proof-of-concept code available. It was found by Meher Sudhakar Abbireddi.

Those "Ninja Forms is under attack" articles are about a different plugin

Search for "Ninja Forms vulnerability" and near the top you will find articles from April 2026 reporting a wave of attacks actually observed in the wild. It was a real, well-documented incident covered by major security outlets. If reading this far has made you nervous, let us separate the two cases first.

That was a different plugin. The issue was CVE-2026-0740, a flaw in "Ninja Forms – File Uploads," an add-on plugin that adds file attachment support. Rated 9.8, it allowed an outsider to upload arbitrary files and execute code on the server — clearly more severe than any of the seven covered here. It runs on roughly 50,000 sites, and the fix shipped in 3.3.27.

The names are similar, but it is a separate product from the core plugin (600,000 sites), with its own version numbering. All seven issues in this article are in the core plugin. The flip side is that if you also run the File Uploads add-on, you need to check that version separately. If "Ninja Forms - File Uploads" appears in your Plugins list, that applies to you.

Why these are missing from the security vendors' databases

Here is a snag you will hit if you try to verify any of this yourself. Look up the databases most often consulted for WordPress vulnerability information — Wordfence Intelligence and Patchstack — and the five disclosed on July 21 are not there (as of August 13, 2026).

The reason is that a different organization issued the CVE numbers. Those five were assigned by VulnCheck, a security company that does not specialize in WordPress. CVE-2026-15663, by contrast, was issued by Wordfence and CVE-2026-15256 by WPScan, and both appear in their respective databases. Their absence is not evidence that the flaws do not exist — it is a question of whose remit it is to catalog them.

The primary sources for vulnerability information are the public database NVD and the changelog published by the vendor. It is safer not to read the absence of an entry in one security company's database as proof that you are fine. The same gaps happen with other plugins, so it pays to build the habit of checking from your own side of the fence with a tool that inventories the software you depend on.

Almost nothing about this exists in Japanese

While researching this article we went looking for Japanese-language coverage, and virtually none of the seven has been explained in Japanese at all.

Search JVN iPedia, Japan's national vulnerability database, for "ninja" and all you get are records from 2024 and 2016. Not one of the Ninja Forms vulnerabilities disclosed in 2026 is registered there. We also checked every JPCERT/CC weekly report from July 15 through August 13, and none of the seven is mentioned. There is nothing in the IPA advisories either. On Qiita, Zenn, and Hatena Bookmark, we found no explanatory posts published since July.

Even when a search does land on a Japanese page, a closer look usually shows it is about a different vulnerability from 2022 or 2024. "No coverage in Japanese" does not mean "not a big deal". It simply means that a plugin used on 600,000 sites has a flaw allowing payment amounts to be rewritten, and nobody has written it up in Japanese.

Is any of this being exploited?

Here is where things stand as of August 13, 2026.

✓ What we can confirm

  • None of the seven appears on the US CISA catalog of vulnerabilities known to be exploited in the wild. Checked against revision 2026.08.11 of that list, all 1,665 entries (here is a dashboard for browsing it)
  • The estimated probability of exploitation within the next 30 days (EPSS) is below 0.4% for all seven
  • No security vendor has reported observing real-world attacks
  • For CVE-2026-15256, the reporting party's advisory publishes reproduction steps
  • Ninja Forms has not been pulled from distribution and updates normally from the official WordPress directory (62.1 million cumulative downloads, rated 88/100)

In other words, your site is not going down today or tomorrow over this. That said, attacks starting only after a fix ships and the method becomes guessable is a well-worn pattern for this kind of vulnerability. Nobody is rushing you, but this is not something to leave until the next maintenance window either — that is about the honest assessment.

What to do

Open "Plugins" in the WordPress dashboard, and if Ninja Forms shows an update notice, click update. That is the whole job. Afterwards, confirm that the displayed version reads 3.15.0. As a precaution, take a backup of the site before updating.

We also recommend turning on automatic updates for the plugin. WordPress plugins usually ship with auto-updates off, and that is exactly what causes cases like this one — where you update once and further fixes land afterwards — to slip through. With auto-updates on, the next time this happens you will not have to lift a finger.

If circumstances stop you from updating right away, the stopgaps are limited. Adopting a practice of not casually opening incoming form submissions in the dashboard will suppress the trigger for CVE-2026-65048. Temporarily taking your public forms offline closes the three that need no login. Both are first aid only; updating is the only real fix. WordPress plugins have seen a run of vulnerabilities over the same period, so it is worth also reviewing our roundup of flaws in popular plugins to make sure no update has been overlooked.

The order the fixes landed in

For anyone who wants to follow the sequence, here it is laid out against the official changelog.

VersionDate in the official changelogSecurity content
3.14.9July 2026Fixes five CVEs
(65048–65052)
3.14.10July 20, 2026Fixes two CVEs
(15663 and 15256)
3.14.11July 23, 2026None
(bug fixes only)
3.14.12August 10, 2026Hardened SQL query handling
(no CVE assigned)
3.15.0August 12, 2026None
(AI feature added)

As you can see, the security fixes arrived in three separate batches. The CVE numbers also came after the fixes, and in the case of CVE-2026-15256 the number was assigned more than two weeks after 3.14.10 shipped. An approach of "act when a CVE appears" will always be late against a pattern like this. The practical policy is: if the changelog says "Security," update, number or no number.

Frequently asked questions

Q. So which version should I be on?

3.15.0. If all you want is to close every disclosed CVE, 3.14.10 or later is enough, but 3.14.12 carries a database-related fix with no CVE number attached, so going to the latest release is the sure thing.

Q. I already updated to 3.14.9. Is there anything left to do?

Yes. CVE-2026-15663 and CVE-2026-15256 are both still open in 3.14.9. Because the advice circulating in late July was "go to 3.14.9," plenty of sites are parked there. Update to 3.15.0.

Q. Am I at risk just from having a form on my site?

Three of the seven can be triggered by someone who is not logged in. The more you expose forms that require no account — "contact us," "request information," "book an appointment" — the more likely you are to be in scope. If you take payments through a form, factor in CVE-2026-65052, which allows the amount to be rewritten.

Q. Are these already being used in attacks?

As of August 13, 2026, no real-world attacks have been reported for any of the seven, and none appears on the US CISA exploited-vulnerabilities list. That said, the advisory for CVE-2026-15256 includes reproduction steps, so the method itself is public.

Q. I saw news in April that Ninja Forms was under attack.

That concerned a separate add-on plugin, "Ninja Forms – File Uploads" (CVE-2026-0740), and has nothing to do with the seven in this article. If you do run that add-on, though, check separately that it is on 3.3.27 or later.

Q. I searched the Wordfence database and found nothing.

The five disclosed on July 21 had their CVE numbers issued by VulnCheck and are not cataloged in the Wordfence or Patchstack databases (as of August 13, 2026). Not being listed does not mean not existing. Check NVD, the public database, and the vendor's changelog.

Summary

Ninja Forms, used on 600,000 sites, had seven vulnerabilities disclosed between July and August 2026. The most severe is CVE-2026-65048 (9.3), which leads to administrator takeover with no login required; the one with the most tangible consequences is CVE-2026-65052, which lets an attacker rewrite a payment amount down to zero.

The remedy is updating to 3.15.0, and nothing more. The complication is that the fixes arrived in three batches, so stopping partway at 3.14.9 leaves two issues open. The people most likely to miss something are, perversely, the ones who updated exactly as the advice of the day told them to.

No real attacks have been confirmed, and nothing here is on the US government's exploited list. There is no need to panic, but the one lesson worth taking away is that waiting for a CVE number puts you behind. In this case, the last of the seven got its number more than two weeks after the fix shipped. When a changelog says a security fix is included, updating before you go looking for a number is both faster and safer.

References

avatar-m-1

Backend Engineer / AWS / Django