WordPress Core RCE: Hackers Try New Tactics, MalCare Blocks 3.8M Attacks

On July 17, WordPress released an emergency update for 2 core vulnerabilities, which could be chained together to take over a site. 

In the first week, we saw about 15,000 attacks per day. 

Everyone assumed this would slowly taper off as the days passed. I also heard some agencies say that a lot of sites would have received the auto-update, so the fallout wouldn’t be that large. 

But we were all wrong. 

Now, three weeks later, we’re seeing over 900,000 attacks per day, and the numbers are still rising.

The sheer volume and repetition of attacks is staggering. Over the first 17 days, our patch blocked 3.8 million attacks –

• 93% of these targeted sites were attacked 200 times each
• 700+ sites faced 10,000+ attacks each
• 50,000 attacks hit a single WooCommerce store alone

But the bigger problem was how quickly new attacks are showing up.

The attacks are changing over time

After the vulnerability disclosure on the 17th, the first attacks were easy to recognise. 

The vulnerable endpoint (batch/v1) was visible in the request URL. They looked like this:

Or this:

But then attackers found another way in.

They realised WordPress would also accept the batch/v1 route when it was sent inside the form data of the request.

So they simply moved batch/v1 out of the URL and into the request body. The new attack looked like this:

This is just one example out of almost a dozen new attacks we’re seeing. 

It’s a clear sign that hackers are using AI to drastically increase the volume and variations of their attacks on vulnerabilities.

How MalCare is handling new attacks

If you’re a MalCare customer, you’re already protected. 

Vulnerability Shield is blocking such new attacks because of its seven-step process of building patches. 

Basically, our team doesn’t build patches based on just publicly known attacks. We study how the vulnerable code actually behaves, map the different ways an attacker can reach it, and then try those variations ourselves before the patch goes live, to ensure it blocks them. 

So in this case, our virtual patches were built to recognise the vulnerable route wherever WordPress could accept it, not just the request URL. 

It checked for three conditions that would be required for the exploit to be successful, regardless of what the attack looked like. So even when the attacks changed, our patches could block them. The three conditions were: 

• The request method needed for the attack
• The vulnerable WordPress batch route, wherever it appeared
• The malformed data needed to trigger the vulnerability

What agencies should do next 

By our estimate, around 15% of sites still haven’t updated. So first, please check that every client site is on a patched WordPress version.

Then you should check whether your sites were attacked. Search for requests containing:

But since the attacks changed later, you can check for the new ones — if your logs capture POST or form data, search for:

Some firewalls don’t store enough request data to check this properly. 

Especially if a site was slow to update or was being attacked repeatedly, I wouldn’t rely on the firewall logs alone.

So I’d recommend a proper malware scan to confirm if anything slipped through the cracks. 

The takeaway

Attack volumes are rising faster than ever before. New variations are appearing within days, sometimes hours. 

We must invest in proactive security against vulnerabilities, and all of us i.e., security companies, web hosts, and agencies – need to get better at sharing what we see and improving our defences together.