When you see news of a 9.9 (or in some cases 8.8) vulnerability in Elementor, that is a cue to panic. 

When you see news of a 7.2 one in the tagDiv Composer plugin, with 140,000-odd installs? Concern, maybe. Panic, definitely not. 

Yet, here at MalCare, we barely saw any attacks trying to exploit the Elementor vulnerability. And billions on sites with tagDiv. (No, that’s not a typo. It is billions with a ‘b’.)

Updates are the centre of much debate in the WordPress ecosystem. On the one hand, they are much needed from a security angle. On the other hand, they are the cause of much stress courtesy site crashes and critical errors thanks to plugin conflicts. 

Vulnerability news is supposed to help site admin maintain sanity: which updates can wait for a spell, and which ones need us to drop everything in its favour. Severity scores help us prioritise. 

But they often end up doing exactly the opposite.

So what is happening here? We did some digging to figure it out. 

Data points don’t lie

At MalCare, we can gauge scale of hacks in two ways: 

1. How many attacks, attempting to exploit the vulnerability, are blocked by our firewall. 
2. How many sites, hacked due to this vulnerability, install MalCare to scan for and remove the malware.

This is an overly simplified version of our data points, of course, but it does paint an interesting picture. 

MalCare protects over 300,000 WordPress sites of all kinds, worldwide. So when we see trends in our data, we can extrapolate it to figure out the real-world impact of individual vulnerabilities.

Case A: Elementor vulnerability: damp squib

Elementor had a file upload vulnerability in December, and the noise surrounding it was immense. 

Articles ripping Elementor apart. Discussions in groups and people scrambled to deal with the vulnerability. Social media buzz, as people spoke of uninstalling the plugin altogether. 

To be fair, Elementor has seen more than its fair share of vulnerabilities lately. So this was not a surprising reaction. 

It is however an overreaction. 

Our data clearly shows that there were hardly any attacks trying to exploit the Elementor vulnerability. There were some, which were swiftly blocked by the firewall, but overall, there were no abnormal spikes. 

(In fact, if you will notice, our team avoided mentioning an exact number in the article, because the numbers were underwhelming.)

Secondly, there was no accompanying spike in the number of hacked sites added to our platform during that time frame. 

The reality was that, while Elementor boasts millions of installs, few sites had the open contributor level access required to exploit the vulnerability. 

And even fewer site admin knew how to check; but that is an entirely separate discussion.

Case B: tagDiv Composer: silent but deadly

On the other hand, we had tagDiv Composer with a modest 140,000 installs see over a billion attacks targeting an XSS vulnerability. 

The vulnerability had a severity score of 7.2 in one place, and 6.1 in another. Plus, it was an XSS vulnerability, which is not uncommon. 

There was zero buzz. 

In fact, the sheer number of attacks blocked by our firewall was so staggering, we scrambled around to figure out if there was a problem. 

To our amazement, we saw that all these attacks were targeting this single vulnerability on sites. 

What’s more, the attacks came in waves. The initial vulnerability was discovered around August 2023, and since then the hackers changed tactics each time, mutating to better escape detection and site defences.

Why did tagDiv Composer see so many attacks?

Attacks exploiting the tagDiv Composer vulnerability would cripple sites, their admin, and their visitors. There was also a huge risk of reinfection after malware removal, as hackers use compromised user accounts as a backdoor.

It was a firestorm—with a very low barrier for entry.

The XSS attack could be executed by anyone, without any special access to the site, simply by sending a request. The request would have inserted a special payload into the site. Thereafter, once an admin logged in and visited the homepage, the hacker would have gained complete access.

We examined the hack requests and saw this was the objective. And when hacked sites were added to our platform for cleaning, we were able to confirm this sequence of events had occurred. 

Why billions when 1-2 requests for a site is enough

Billions do make us sit up and take notice, but the reality was that hackers did not really need to send 20000 attacks to crack a site. 

At first, we were also swayed by the vanity metric, but when we took a step back, it was clear that something else was going on.

Attacks at internet scale with few resources

The billion+ attacks we saw took place on sites protected by MalCare—around 400,000 sites. 

Considering how many sites use WordPress, the number of attacks would have been 100x—if not more. 

That’s 100s of billions. Remember, not a typo. 

And all of this was achieved using a handful of IPs. 

Hackers maintain lists of sites across the Internet to attack at will.

Double trouble

The (lack of) consequences

Without MalCare’s firewall, any one of these attacks could have found its mark. 

But equally, without a great firewall, the volume of requests would have slowed down each target site to the point of unusability. (This is what a DDoS attack is, after all.) Even sites without the tagDiv plugin saw attack requests. They weren’t even at risk, but could have slowed down by the sheer scale.

However, our bot protection prevailed for both cases. MalCare’s firewall blocked these attacks preemptively and reduced the potential load on sites.

Not just any security

The only reason 400,000 WordPress sites didn’t get hacked was because of MalCare’s firewall. 

Web host security didn’t protect those sites. Other DNS-based firewalls didn’t protect those sites. Other plugin-based firewalls didn’t protect those sites. 

The permutations of the requests were designed to pierce the defences of firewalls, and they would have succeeded if not for MalCare.

Vulnerabilities, severity, and the way forward

High severity scores convey danger and damage on a sliding scale, but they cannot account for scale in the real world.

So while scores and noise will raise WordPress users’ blood pressure, it doesn’t convey important, pertinent information.  

People need to be alerted only about high severity vulnerabilities affecting their sites, so they can act upon them. Too much and too little noise are both equally dangerous. 

Plus, a system that relies on noise to function is inherently unreliable. 

Reliable site security should protect sites from all exploits: noise and vulnerabilities notwithstanding. 

MalCare’s Atomic Security does that. 

Atomic Security prevents attacks on WordPress sites, so the sirens are no longer necessary. We can take a breath, finish whatever we are doing, and update vulnerable plugins mindfully.

It is a secure WordPress future worth aiming for.