Four Holes in 100 Days: What 2026 Taught Us About WordPress Security

Four times since mid-July, a stranger on the internet could take over a WordPress website without a password. It happened once in WordPress itself, twice in popular plugins, and once in PHP, the language WordPress runs on. Each time, attacks started within hours or days of the news going public.

I'm not writing this to scare anyone. WordPress runs a huge share of the web, including plenty of the sites I've worked on, and the people who maintain it moved fast every time. I'm writing it because the pattern matters more than any single bug. If you know the pattern, you know what to ask your web person.

What happened, in order

July 17: wp2shell (WordPress core)

Two bugs in WordPress itself, nicknamed wp2shell (CVE-2026-63030 and CVE-2026-60137), could be chained so that one web request ran code on the server. It worked on a default install with no plugins at all. WordPress fixed it in versions 6.8.6, 6.9.5 and 7.0.2 and pushed the update automatically. Sites that had automatic updates turned off, which is common on agency-managed sites, stayed exposed. Public attack code showed up within hours, and security firms confirmed real attacks within days.

August 19: Elementor Pro

Elementor is one of the most popular page builders, with more than 6 million sites using it. A bug in the Pro version's forms (CVE-2026-32475) let anyone upload a file and run it, as long as the site had a form with a file-upload field. That's a job application or a "send us a photo" form, which is very normal. Attacks started the same day the fix (version 4.2.2) came out. Wordfence blocked more than 190,000 attempts in the first five days.

October 7: Bricksforge

Bricksforge, an add-on for the Bricks site builder, had a flaw rated 10 out of 10 for severity (CVE-2026-85097). Again, no login was needed to upload and run code. Patchstack spotted attacks from 63 different addresses.

October 21: PHP2Shell (PHP itself)

Then it went one layer deeper. Two bugs in PHP, nicknamed PHP2Shell (CVE-2026-109618 and CVE-2026-109619), let a single request run code before your website's own code even starts. PHP powers roughly 70% of websites, so this isn't only a WordPress problem. Amazon saw someone trying it on October 17, four days before the fix, and as of today there's evidence of successful attacks. The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older don't get a new release.

The pattern behind all four

The window is hours, not weeks

Patchstack's State of WordPress Security in 2026 report found that about half of high-impact WordPress bugs were attacked within 24 hours of going public. For the most targeted ones, the typical time to first attack was five hours. "We'll get to it at the end of the month" doesn't work anymore.

Your host's firewall probably won't catch it

It's tempting to assume your hosting company has this covered. In Patchstack's testing, common hosting defenses blocked only 12% of attacks on known, actively exploited WordPress bugs. Firewalls like Cloudflare help and buy you time, but they don't replace the update.

A lot of sites are behind

In the first days after PHP2Shell, Brandefense's free checker found that 59% of sites showing their PHP version were still on a version without the fix, and a third were on PHP 8.1 or older. That sample isn't random, but it matches what I see: plenty of sites run on servers nobody has touched in years.

This isn't "WordPress is bad"

About 91% of WordPress security bugs are in plugins, and only six were found in WordPress core in all of 2025. The core team responded quickly to wp2shell. The real problem is usually simpler: nobody owns the updates. Sites get built, launched and handed off, and then the plugins, the PHP version and the server quietly age.

For business owners: a 15-minute check

You don't need to log in to anything. Send these five questions to whoever runs your website:

1. Are we on WordPress 7.0.2 or later? (Or 6.9.5 or 6.8.6 if we're on an older branch.)
2. What PHP version are we on, and does it have the PHP2Shell fix? Look for 8.2.35, 8.3.36, 8.4.27, 8.5.12 or newer.
3. Which plugins do we run, and are any of them unused or no longer updated? Every plugin is another door. Remove the ones you don't need.
4. Who gets the alert when a security fix comes out, and how fast do they act? If the answer is "nobody" or "whenever," that's the real fix.
5. When did we last test restoring the site from a backup? A backup you've never restored is a hope, not a plan.

If you can't name the person who patches your site, start there. Write their name down. If there isn't one, that's the gap to close this month.

For agencies managing many sites

If you run WordPress for dozens of clients, this fall handed you a lot of work. Here's what I'd prioritize, from one technical person to another:

• Keep a live inventory. For every site, track the WordPress version, PHP version, server and plugins, including premium ones like Elementor Pro and Bricks add-ons. You can't patch what you can't see.
• Patch PHP at the server, not site by site. One PHP update on a shared server covers every site on it. Check for servers still on PHP 8.1 or older, and plan for PHP 8.2 reaching end of life on December 31, 2026.
• Revisit disabled auto-updates. Many agencies turn off WordPress auto-updates to avoid surprises. wp2shell showed the cost of that. Consider letting security releases through automatically.
• Use the stopgap where you can't update yet. PHP lists turning off session.upload_progress.enabled as a partial workaround for PHP2Shell. It isn't a fix, and you should test it first.
• Look for signs you were hit, not just whether you're patched. Check upload folders, especially /wp-content/uploads/elementor/forms/, for .php files that shouldn't be there. Review logs from October 17, not October 21, since attacks started before the fix.

Hours-long windows are hard for a small team to cover, especially when every client site runs a slightly different stack. That's not a failing. It's just the job now.

The bigger lesson

None of these four were exotic. Each one was a door left open, followed quickly by people checking for open doors. The sites that came through fine weren't lucky. Someone was watching, the updates were allowed to run, and there was a tested backup if things went wrong.

Sources

• Tenable: wp2shell FAQ
• BleepingComputer: Elementor Pro flaw exploited to take over WordPress sites
• The Hacker News: Bricksforge CVSS 10.0 flaw exploited
• Amazon Threat Intelligence: PHP2Shell exploitation before disclosure
• BleepingComputer: PHP2Shell exploited in the wild
• Brandefense: PHP2Shell checker results
• Patchstack: State of WordPress Security in 2026