The attack that arrived as a form submission, and ran when you opened it

Tuesday morning. Coffee on the desk, the admin screen open, and the overnight list to work through: two orders, a refund query, four form submissions. You open each one, because that is the job. For a small number of WordPress site owners this month, one item on that list was the attack, and opening it was the moment it ran.

Nobody clicked a dodgy link. Nobody opened an attachment. Patchstack, the WordPress security firm, identified a campaign on 4th October 2026 planting attack code in a form submission or an order, through flaws in two unrelated plugins: WPC Product Bundles for WooCommerce, on more than 30,000 shops, and from 5th October Ninja Forms, one of the most installed contact form plugins there is, on more than 500,000 sites.^[1][2]

Here is what to do before reading further. Ninja Forms versions 3.15.3 and earlier are affected; 3.15.4 fixed it, and the current release is 3.15.5. WPC Product Bundles versions 8.6.6 and earlier are affected; 8.6.7 fixed it, and the current release is 8.7.5.^[1] If you run either, update now. The rest of the article explains why this one is worth a few minutes of your attention even if you do not.

Why reading a message could run a program

Both flaws are the same type, known as stored cross-site scripting, which means a site saves a snippet of attacker code as if it were ordinary text and later shows it to someone, and the browser runs it.^[2] In plain terms: a stranger types a few lines of code into one of your form fields instead of a name and a message. Your site files it away like any other enquiry. It does nothing at all while it waits.

Then you log in and open it to read, and the code runs inside your browser, in your logged-in session.

That last part is the whole story, so it is worth being slow about it. WordPress decides what someone is allowed to do based on who is logged in. It does not keep re-checking; once you are in, you are trusted. Code that runs in your browser while you are logged in as an administrator inherits that trust. It never has to steal your password or prove who it is, because as far as the site is concerned, it is already you, doing things you are allowed to do. In this campaign, what it did was quietly grant the attacker their own way back in.^[1]

The ordinary screen was the delivery van

Step back and notice what that means, because it undoes a rule every small business owner has been taught. Security advice has always been about places you can choose not to go. Do not click the link. Do not open the attachment. Do not install the thing off the dodgy website.

This arrived in the one place you cannot choose not to go: your own orders and enquiries, in data a customer submitted, running because you did your job properly. There was nothing to not click. There was an order to pack and a question to answer. The contact form is the most innocent-looking thing on a small business website, and it is also the most direct line there is from a stranger to the screen where you run everything.

The part most people get wrong about “it needs a login”

When a plugin flaw is described as needing a logged-in user, it sounds reassuring, as though only staff could trigger it. This campaign is the reason that reassurance is misplaced. The stranger who submits the form is not logged in at all. The logged-in user whose session runs the code is you, later, reading what they sent. The attacker never needs an account because they borrow yours for the half-second the page is loading.

So the useful question this story leaves you with is not “is my plugin patched”, though it should be. It is “who is logged in when the overnight enquiries get read, and what is that account allowed to do”.

Updating closes the door, it does not clear the room

One honest caution, kept short on purpose. On a site where this ran before the update, patching the plugin does not undo what already happened. Patchstack is explicit that updating stops further exploitation but does not clean a site that was already caught, and that this campaign deliberately left more than one way back in, including an administrator account hidden from the normal user list, so that removing the obvious culprit does not finish the job.^[1] That is not a reason to panic. Exploitation so far is limited.^[1] It is the reason that checking a site that ran a vulnerable version is a separate task from updating it, and worth asking someone to do properly.

What to do this week

1. Update both plugins if you run either, to Ninja Forms 3.15.5 and WPC Product Bundles 8.7.5, or let your host do it.
2. Open your Users list and read it like a guest list. Every administrator is a session this kind of attack could run inside. Most small sites have three or four admins left over from a web designer, a marketing agency and somebody who left two years ago. Name each one, and ask who still works with you.
3. Demote the ones who only write. The person who adds blog posts needs an author account, not an administrator one. It is a two-click change and it shrinks the number of doorways considerably.
4. If you were running a vulnerable version, have someone check the site for accounts you did not create, including ones that may not show in the ordinary user list, and for plugins nobody remembers installing. This is the separate job described above.

Where your hosting comes in

On our managed WordPress hosting, the plugin updates that close flaws like these are applied for you, so the gap between a fix being released and your site actually having it is measured in hours rather than left to a free weekend. We cannot see inside your WordPress user list from the outside, and we would not want standing access to it, so reviewing who has an administrator account is genuinely your job, and the four steps above are written so you can do it without us. But if you run either of these plugins and would rather talk it through, or you were on an old version and want a second pair of eyes on whether anything was left behind, that is exactly the kind of thing to send our way. A compromise check on a site that ran vulnerable code is a different piece of work from applying an update, and we would far rather do it than have it skipped.

The advice was never really “be careful what you click”. On a site you log into every morning, it was always “be careful what is logged in”. A stranger cannot reach the screen where you run your business, but the message they leave you can, at the moment you sit down to read it. Knowing who else could be reading that post in an administrator’s session is this week’s small, worthwhile job.

Related reading

• Your contact form is a door: two upload flaws and what to check
• This WordPress backdoor keeps a copy of itself in eight places, and each one rebuilds the others

Sources

1. Four ways back in: the WordPress XSS campaign that hides its own admin account, Patchstack, 6th October 2026.
2. Ninja Forms plugin flaw exploited to hack WordPress sites, BleepingComputer, 6th October 2026.