The Three-Month Fuse: The Everest Forms Pro Attack and Why a Patched Plugin Can Still Put Websites at Risk

Illustration showing a cyber attack bypassing a security shield to compromise a website.

A critical vulnerability in Everest Forms Pro is a good example of a problem that goes beyond one WordPress plugin.

The vulnerability, tracked as CVE-2026-3300, allowed an unauthenticated attacker to execute arbitrary PHP code on a WordPress site. The flaw is rated critical, with a CVSS score of 9.8 out of 10.

The developer released version 1.9.13 on March 18, 2026, to fix the problem.

That should have been the end of it.

It wasn’t.

Attackers began actively exploiting the vulnerability weeks later, with security researchers reporting large numbers of attacks against sites that had not installed the security update. The attack code itself was designed to create a new WordPress administrator account named “diksimarina,” giving the attacker administrative control of the compromised site.

So when someone says, “That vulnerability was patched months ago,” that misses the point.

The patch is not the same thing as the patch being installed.

The Three-Month Fuse

The timeline is what makes this particularly interesting.

  • March 18, 2026: Everest Forms Pro 1.9.13 is released with the security fix.
  • March 30: The vulnerability is publicly disclosed and assigned CVE-2026-3300.
  • April 13: Security researchers begin seeing active exploitation.
  • May: Exploitation surges, with thousands of attempts targeting vulnerable websites.
  • June: Security researchers continue warning WordPress site owners about the ongoing attacks and the need to update.

What Went Wrong in Everest Forms Pro?

The technical mistake in this case was particularly serious.

Everest Forms Pro’s Calculation Addon used PHP’s eval() function to process calculations. User-submitted form values were incorporated into PHP code before that code was evaluated.

The plugin did apply sanitize_text_field() to the submitted data, but that function is not designed to make arbitrary input safe for insertion into PHP source code. It does not provide the kind of protection needed to prevent PHP code injection in this situation.

That created a code-injection vulnerability.

An unauthenticated visitor could submit specially crafted data through a form using the Complex Calculation feature and cause arbitrary PHP code to execute on the server. The vulnerability could then be used to create administrator accounts and establish further control over the site.

Security Tip: If you run Everest Forms Pro, check your WordPress User list immediately for unauthorized administrator accounts using the username diksimarina.

The Plugin Dependency Problem

WordPress itself is not the issue here. The issue is the way a WordPress website can end up being assembled.

Need advanced forms? Install a plugin.

Need SEO features? Install another.

Need membership features? Another plugin.

Need caching? Another.

Need some other functionality that isn’t built into the platform? Find another plugin.

A site can eventually depend on a collection of independently developed components, each with its own code, developer, update schedule, compatibility requirements, and security history.

That creates a much larger maintenance burden.

And every additional component creates another piece of software that can potentially contain a vulnerability.

The Everest Forms Pro attack demonstrates exactly why this matters.

The developer can release a fix. Security researchers can identify the vulnerability. WordPress can continue operating normally.

But an individual website can still be vulnerable because the site is running the old version of the plugin.

The security of the website therefore depends not only on the security of WordPress, but also on the security and maintenance of every important third-party component installed on that website.

The Problem Isn’t Just Updating Plugins

The usual response is simple:

Just keep your plugins updated.

Of course websites should be kept updated.

But that doesn’t make the underlying dependency problem disappear.

Updates can also introduce compatibility problems. A plugin update can interact differently with the WordPress version, theme, PHP version, another plugin, or custom code on the site.

That is one reason some website owners delay updates, test them first, or leave certain components untouched until they know an update won’t break something else.

Now the administrator has another job: maintaining an ecosystem of independently developed software components.

That is a very different maintenance model from having major website functionality built into the website-building platform itself.

The UltimateWB Approach

Major website functionality is built into UltimateWB rather than requiring a separate third-party plugin for every major feature.

Forms and surveys are built in. So are SEO tools, e-commerce, forums, memberships, listings, classifieds, auctions, social networking features, photo galleries, mailing-list functionality, and more.

That doesn’t mean UltimateWB somehow makes security vulnerabilities impossible. No software can honestly make that claim.

It means you don’t need a separate third-party plugin for each major piece of website functionality.

For example, if you need a sophisticated form with calculations, you don’t have to install a separate form plugin and then depend on that plugin developer to maintain it alongside everything else on your site.

The Forms & Surveys Builder is built into UltimateWB.

The same principle applies across the platform.

Built-In Means Fewer Moving Parts

This is one of the biggest differences between UltimateWB and a typical plugin-dependent WordPress setup.

With UltimateWB, major functionality is designed to work as part of the same website-building platform. In most cases, the website owner is simply keeping UltimateWB itself updated rather than tracking a collection of different plugin developers, update schedules, compatibility issues, and security advisories.

And if you aren’t using third-party software, there is nothing there to monitor or update.

That is not just about convenience – but also security.

It is an architectural choice.

A website is only as secure as the software actually running on it.

That is why reducing unnecessary third-party dependencies is a worthwhile part of building a website.

And it is one of the reasons UltimateWB was built with so much functionality directly into the platform.


Related


Looking for a website builder that helps you avoid plugin headaches? Learn more about UltimateWB! We also offer web design packages if you would like your website designed and built for you.

Got a techy/website question? Whether it’s about UltimateWB or another website builder, web hosting, or other aspects of websites, just send in your question in the “Ask David!” form. We will email you when the answer is posted on the UltimateWB “Ask David!” section.

About the UltimateWB Team

This article was written and reviewed by the UltimateWB Development Team. With over 20 years of hands-on experience in full-stack web development, database optimization, and secure server administration (WHM/cPanel), we engineer UltimateWB with clean, built-in apps so you never have to deal with the performance-draining software bloat, security risks, or compatibility issues of third-party plugins. We build software designed from day one for maximum developer autonomy and lightning-fast performance.

This entry was posted in Coding, Server Admin & Security and tagged , , , , , , , , , , , , , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *