Everest Forms Pro CVE-2026-3300: The Unauthenticated WordPress Takeover Hiding in Your Contact Form

A visitor fills out the quote form on your website. A few seconds later, a WordPress administrator account nobody on your team created logs in and starts installing things. No password was guessed. No employee clicked a link. The form itself was the way in.

That is happening right now to small-business sites running Everest Forms Pro, a popular WordPress form builder. The flaw, tracked as CVE-2026-3300, carries a CVSS score of 9.8 and lets an unauthenticated attacker run PHP code on your server through an ordinary form submission. Wordfence, the firm that found and reported it, has blocked more than 29,300 exploitation attempts, including a single-day surge of over 17,900 on May 16. Active attacks began on April 13, roughly two weeks after the bug went public.

Here is the part that decides whether you keep reading. If your website runs on WordPress and has Everest Forms or Everest Forms Pro installed at version 1.9.12 or earlier, this is your emergency for the week, and the response is a ten-minute plugin update plus a hunt for accounts you did not create. If your site lives on Squarespace, Wix, Shopify, or a hand-built page with no WordPress behind it, you can close this tab; none of it reaches you. And if you run WordPress but have never installed Everest Forms, you are clear too, though the hardening section at the end will save you the next time a plugin breaks. The whole job here is to tell you which of those three groups you are in before you spend any effort.

It is worth being concrete about what a hijacked website costs a small business, because the damage rarely stays on the website. An attacker with admin control can redirect your customers to a fake checkout, quietly inject spam or malware that gets your domain flagged by Google Safe Browsing, and harvest whatever the site stores - form submissions, customer emails, payment details handed to a plugin. The cleanup is the small part. The expensive part is the weeks your domain spends on a blocklist while prospects see a red warning instead of your homepage, and the trust you spend rebuilding with customers who got a phishing email that appeared to come from you. For a company whose website is its storefront, an afternoon of unpatched plugin is a quarter of recovered reputation.

What actually broke

Everest Forms ships an add-on called Calculation that lets a form do math: total a quote, add line items, apply a discount. To evaluate the formula you build in the form editor, the plugin assembles a string of PHP and hands it to PHP's eval() function, which runs whatever that string contains.

The problem is how a visitor's input reaches that string. When a form uses the Complex Calculation feature, values typed into ordinary fields - text, email, URL, select, and radio fields - get concatenated into the PHP that eval() executes. The plugin runs those values through sanitize_text_field() first, the standard WordPress cleanup routine. That function strips HTML tags and trims whitespace, but it leaves single quotes and the other characters that change the meaning of PHP code untouched. An attacker opens a field value with a quote, closes the string the plugin was building, and appends their own PHP. The flaw lives in the add-on's process_filter() function, and it was confirmed in the GitHub Advisory Database as well as on NVD.

// Simplified shape of the vulnerable path in the Calculation add-on.
$formula = "return " . $user_supplied_value . ";";
eval($formula);            // visitor input reaches eval() unescaped

// sanitize_text_field() removes tags but leaves ' ( ) ; intact, so a
// submitted value like:   1'); wp_insert_user($rogue_admin); //
// closes the formula string and runs the attacker's PHP.

What attackers do with that access is consistent. The most common payload calls WordPress's own wp_insert_user() to create a new administrator. In the wave Wordfence tracked, that account is named diksimarina, registered to the email diksimarina@gmail.com. Once it exists, the attacker has the same control over the site you do: install plugins, edit pages, redirect customers to a scam, or drop a web shell and stay.

Check whether you are exposed, and whether you are already owned

Two questions, in order. First: what version of Everest Forms is running. Second: is there an administrator on the site that nobody on your team created. You can answer both from the WordPress dashboard, but if you have shell or WP-CLI access to the host, it is faster and harder for a tampered admin screen to lie to you.

From WP-CLI

# 1. Which Everest Forms version is installed? Anything <= 1.9.12 is vulnerable.
wp plugin get everest-forms --field=version
wp plugin get everest-forms-pro --field=version

# 2. List every administrator. Look for accounts you did not create;
#    the known-bad one in this campaign is "diksimarina".
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

# 3. Search for the rogue account by name or email directly.
wp user list --search="diksimarina" --fields=ID,user_login,user_email

In the web server logs

The injection arrives as a POST to the Everest Forms submission handler, which rides on admin-ajax.php. Grep your access logs for the source addresses Wordfence published, and for unusual volumes of form-submission POSTs dated on or after April 13.

# Known attacker IPs from Wordfence telemetry for CVE-2026-3300.
grep -E '202\.56\.2\.126|209\.146\.60\.26|15\.235\.166\.18|185\.78\.165\.153' \
  /var/log/nginx/access.log /var/log/apache2/access.log 2>/dev/null

# Form submissions hitting the AJAX endpoint; a sudden spike here is a flag.
grep 'admin-ajax.php' /var/log/nginx/access.log | grep -i 'everest' | tail -50

If you find the diksimarina account, or any administrator you cannot account for, treat the site as compromised. Updating the plugin shuts the door, but it does nothing about an attacker who already walked through it.

The fix, and the order to do it in

1. Update Everest Forms and Everest Forms Pro to 1.9.13 or later. WPEverest released the patched build on March 18, 2026. This is the single step that closes the vulnerability, so do it first.
2. If you cannot update this minute, pull the calculation forms. Disable or unpublish any form that uses the Complex Calculation feature until the plugin is current. That removes the path attackers are spraying.
3. Hunt for rogue admins before you assume you are clean. Run the user checks above. Delete any account you did not create, and reassign its content to a real user so you do not lose pages on the way out.
4. Rotate what a compromise would have exposed. Reset every administrator password, destroy active sessions so a stolen login dies, regenerate the WordPress salts in wp-config.php, and rotate any API keys or database credentials stored on the site.
5. If you saw evidence of intrusion, do not just patch. Restore from a backup taken before April 13, or bring in someone to do a proper cleanup. A created admin account is rarely the only thing an attacker leaves behind.

# Kill any sessions a stolen admin login is riding on.
wp user session destroy <user_login_or_id> --all

# Force fresh WordPress salts so existing auth cookies stop working.
wp config shuffle-salts

Make the next plugin bug less of an emergency

You will not read the source of every plugin you install, and you should not have to. What you can do is shrink the blast radius so the next vulnerable plugin, and there will be one, does less damage. These are the right-sized versions of controls large companies spend real money on, and they cost a small business almost nothing but a little discipline.

Five things worth doing this week

• Cut the plugin count. Every active plugin is code running with your site's privileges. Remove the ones you no longer use, and delete them rather than just deactivating; a deactivated plugin can still be exploited in some cases.
• Turn off dashboard file editing. Add define('DISALLOW_FILE_EDIT', true); to wp-config.php so a stolen admin account cannot paste a web shell into your theme straight from the browser.
• Put a web application firewall in front of the site. Wordfence shipped a blocking rule to its paying customers on February 27 and to free users on March 29, both well ahead of the official patch. A managed WAF buys you that head start on the bugs you have not patched yet.
• Keep real backups, off the server, and test a restore. The gap between a bad afternoon and a closed business is having a restore point from before the intrusion that you have actually proven works.
• Watch the administrator list. A brand-new admin account is one of the highest-signal events on a WordPress site. A weekly review, or an alert when a privileged user is created, catches exactly the payload this campaign relies on.

// wp-config.php - block theme and plugin editing from the dashboard.
define( 'DISALLOW_FILE_EDIT', true );

Update Everest Forms today, then check for the admin you did not create

If you run a WordPress site, do not wait for a calm moment. Confirm the Everest Forms version, update it to 1.9.13, and read your administrator list before you touch anything else this week. The whole sequence takes less than half an hour. Nobody is targeting your company by name; attackers are spraying every site that runs the plugin, and a small-business site with a contact form is precisely what their scanners surface. We help small businesses find the internet-facing weaknesses those scanners hit first and close them before someone else does. If you want a second set of eyes on what your website actually exposes, that conversation is worth having now rather than after a cleanup.