How CVE-2026-3300 enables advanced attacks on WordPress

A recently discovered critical vulnerability in the WordPress plugin Everest Forms Pro shows how a simple application flaw can become the first step of a much larger attack.

Identified as CVE-2026-3300 and rated 9.8/10 on the CVSS scale, this vulnerability allows an unauthenticated attacker to execute arbitrary PHP code on a WordPress server.

But the most interesting part is not just the flaw itself.

This case helps us understand how cybercriminals turn a compromised website into a banking data theft platform by using trusted services such as Google Tag Manager and Stripe.

Understanding the CVE-2026-3300 vulnerability

The Everest Forms Pro plugin provides a feature that allows advanced calculations based on data entered in a form. To perform these calculations, the plugin dynamically generated PHP code before executing it using the eval() function.

The problem is that some user-supplied data was directly embedded into this code without sufficient protection. In practice, an attacker could submit a specially crafted value in a form field in order to inject their own PHP code.

The server would then execute the attacker’s instructions with the privileges of the application.

This vulnerability allowed, among other things, to:

• create a WordPress administrator account
• install a webshell
• deploy a backdoor
• modify the website
• take full control of the server

 

At first glance, this story looks like a classic WordPress vulnerability. However, it highlights a much broader trend in cybersecurity.

Once an attacker gains access to a website, their goal is usually not only to modify its content. They often aim to turn the site into an attack platform. One of the most common scenarios is the installation of a payment skimmer.

What is a skimmer?

A skimmer is a malicious script injected into an e-commerce website to steal information entered by customers during checkout.

The script can collect:

• credit card number;
• cardholder name;
• expiration date;
• billing address;
• email address;
• phone number.

From the victim’s perspective, everything looks normal.

• The website works.
• The order is confirmed.
• The payment appears legitimate.

In reality, a copy of the information is silently sent to the attackers.

Why are these attacks becoming harder to detect?

Historically, cybercriminals sent stolen data to their own servers. Security solutions could then detect communications to unknown or malicious domains.

Today, attackers adopt a different strategy. Instead of using their own infrastructure, they exploit legitimate services already trusted by companies. This is exactly what has been observed in several recent campaigns.

When Google Tag Manager becomes an attack vector

Google Tag Manager is used by millions of companies to quickly integrate:

• Google Analytics;
• advertising pixels;
• marketing tools;
• tracking scripts.

Since this service is widely used and considered trustworthy, it is generally allowed by browsers and security policies. Attackers take advantage of this trust to distribute malicious code via Google Tag Manager. From the perspective of security systems, the traffic appears to come from Google. Yet the browser is executing a malicious script.

When Stripe becomes attack infrastructure

The most innovative aspect of this campaign involves the use of Stripe. Traditionally, malware communicates with a command-and-control (C2) server owned by attackers to receive and store stolen data.

In this campaign, cybercriminals replaced their own infrastructure with Stripe. The stolen data was stored directly in objects associated with a Stripe account controlled by the attackers. In other words, Stripe was used as:

• storage space;
• database;
• communication channel.

This approach provides a major advantage for attackers: communications occur with a legitimate domain that companies already trust.

But what about 3D Secure and OTPs?

Many people believe that strong authentication via SMS, banking apps, or OTP codes completely prevents this type of fraud.

But the reality is more complex. Researchers have observed campaigns capable of handling 3D Secure validation steps in real time. The goal is not to break or technically bypass the OTP system. Instead, attackers try to make the victim perform the validation themselves.

The principle is as follows:

1. The victim enters their banking information on a fake payment page.
2. The data is immediately transmitted to the attackers.
3. The attackers initiate a real transaction.
4. The bank then sends a 3D Secure validation request.
5. This request is relayed to the victim through the fake payment interface.
6. Believing they are confirming their own purchase, the victim approves the transaction.

 

From the bank’s perspective:

• the correct phone was used;
• the correct banking app confirmed;
• the correct OTP code was entered.

All checks are therefore satisfied.

The OTP system is not broken.

It is used as designed, but within a transaction the victim does not fully understand.

This is called a relay attack or a form of social engineering applied to the authentication process.

Conclusion

The CVE-2026-3300 vulnerability highlights the importance of security updates and regular code audits.

However, it also reveals a much larger trend: cybercriminals are now exploiting the trust placed in popular platforms to hide their activities.

Google Tag Manager, Stripe, cloud services, and SaaS platforms are gradually becoming unintended components of some attack infrastructures.

For cybersecurity professionals, the challenge is no longer only about blocking bad domains, but about understanding how perfectly legitimate services can be abused for malicious purposes.

📚 Source: https://thehackernews.com/2026/06/hackers-exploit-critical-everest-forms.html