WordPress vulnerabilities exploited in 2026

On 17 July 2026, WordPress released version 7.0.2 to close a critical flaw in the core itself. According to Patchstack, the first attack attempts reached its sensors about 90 minutes after that version was published. Not days. Minutes.

That changes the question worth asking. It is no longer "what score does this flaw have?" but "how long will it take me to update?". This article goes through what was actually attacked this year (up to 25 October), what each case teaches, and an update routine that a business website or a shop can stick to without losing its mind.

What was attacked, case by case

KEV is the catalogue of exploited vulnerabilities kept by the US cybersecurity agency (CISA). Being listed there means there is evidence of real-world use. The dates come from its public file, checked on 23 October.

wp2shell: two flaws that together were an open door

This is the most serious case of the year, because it hit the WordPress core and not a plugin. Two flaws were chained. One, in the REST API (CVE-2026-63030), let attackers bypass data validation. The other, an SQL injection in WP_Query (CVE-2026-60137), scored only 5.9 on its own. Patchstack explains that together they allowed an anonymous visitor to create an administrator and, from there, run code.

Here is the first lesson: the score of each piece does not tell you what they are worth together. A 5.9 was sitting inside a chain that ended in full control.

In the days that followed, Patchstack blocked more than 65,000 attempts from more than 1,500 different IP addresses. WordPress.org enabled forced updates for the affected sites, so anyone who had automatic updates switched on received the fix without doing anything.

CVE-2026-87902: the same day

Another core flaw, on 22 September. Patchstack saw the first attempt at 11:49 UTC, on the very day 7.1.2 was released, and the first attempt to write a file to the server at 15:34. That said, it had conditions: a theme with a certain folder and PHP with register_argc_argv enabled. Not every site was vulnerable in practice.

Elementor Pro: forms with file uploads

CVE-2026-32475, a flaw in the file upload field of Elementor Pro forms (up to 4.2.1). Patchstack published it on 19 August, the day 4.2.2 came out, and recommends checking wp-content/uploads/elementor/forms/ for .php files. Reports on when the attacks began do not agree with each other, so I am not counting it as a "same-day attack" example.

Bricksforge: attacked before there was an advisory

Here, updating fast is not enough. The attacks began on 7 October at 21:47 UTC, before the public advisory. When there is no margin, what counts is checking afterwards whether anyone got in.

All-in-One WP Migration and Everest Forms Pro: more nuance

The first (CVE-2026-19949) was fixed in 7.110. The NVD explains that the SQL injection is exploited when an administrator restores a backup. It scores 8.8 and, as far as I could confirm, is not in KEV. For the second (CVE-2026-3300, code execution up to 1.9.12) there are exploitation reports that I could not cross-check against a primary source, so I am leaving it as awaiting confirmation.

What all this teaches

1. The score (CVSS) is a starting point, not a traffic light. It measures how serious the flaw is on paper. It does not say whether anyone is using it. Between an 8.8 with no confirmed attacks and a 5.9 inside a 9.8 chain, the score misleads. More useful questions:

• Can it be exploited without logging in?
• Does it affect a normal installation, or does it need an unusual setup?
• Have attacks been observed, or is it in the KEV catalogue?
• Do I use that component, with that feature switched on?

2. The window is hours. Whoever reads the patch builds a scanner and points it at the whole internet. Waiting for the "end-of-month maintenance" leaves a critical site exposed for almost four weeks.

3. Not everything is urgent. WordPress 7.1.3 (6 October) carried seven fixes, and Patchstack said it was not an emergency. If everything is urgent, nothing is, and people end up not updating at all.

4. Updating closes the door; it does not throw anyone out. With Elementor Pro and Bricksforge, anyone who got in earlier is still inside.

Volume: why you cannot read it all

Wordfence reported that between 12 and 18 October, 497 vulnerabilities were disclosed across 327 plugins and 23 themes. The week before, it was 654. Nobody can read that every week.

The way out is not to read more, but to know what you have installed. Out of 500 advisories, the ones that matter to your site are those that match your plugin list.

A realistic routine for a business website or a shop

1. Take an inventory. Plugins, theme and PHP version. Delete what you do not use: every extra plugin is one more door to watch.
2. Decide who keeps watch. A specific person, not "somebody". Wordfence offers its vulnerability database free of charge, with an API and webhook alerts. Patchstack has its own open database. And Spain's INCIBE-CERT publishes alerts in Spanish.
3. Two lanes.
   • *Urgent* (no login needed, exploited or in KEV, and you use it): backup, quick test and update within 24 hours.
   • *Routine*: once a week, without rushing.
4. Back up before touching anything. With a restore you have tested, stored off the server.
5. Test on a copy (staging) if the site takes payments. A complete test order, the emails and the forms. On an informational site, checking the homepage and one form is enough.
6. Automate what is safe. Core security updates are applied automatically by default; leave them that way. For small, low-risk plugins, automatic updates save work. For the page builder, the payment gateway and plugins that touch orders, better to do it by hand and test.
7. Premium plugins are a separate case. Elementor Pro, Bricksforge or Everest Forms Pro are updated through the vendor's licence, not through WordPress.org. If the licence has expired, the notice may not reach you.
8. After a critical flaw, check whether anyone got in. .php files in uploads, new administrators, plugins you did not install.

What to do depending on your case

What we don't know

• Unverified: exactly when the attacks on Elementor Pro began, and the real-world exploitation of All-in-One WP Migration and Everest Forms Pro.
• Blocking figures: these are attempts detected by one security company's systems, not a count of how many sites fell.
• A quarterly study circulating on blogs, according to which the attacks started on patch day in three out of four cases, is something I could not check against Patchstack. That is why I only use the cases I could verify.

So, what now

Take your inventory today and write down who watches the advisories. It is the cheapest step and the one that changes the most.

At AGENCIA RSE, this is part of our WordPress maintenance: watching the advisories, testing changes on a copy and checking the checkout afterwards. Even so, everything above can be done on your own. And if you want a first look from the outside, there are some free tests.

*If you spot any outdated information, let us know and we will correct it.*