WordPress Plugins Are Still Getting Owned: The Everest Forms Pro Lesson

If you run a WordPress site, this week's security news should make you nervous. CVE-2026-3300, a critical vulnerability in the Everest Forms Pro plugin, is being actively exploited in the wild. Attackers are using it to create rogue administrator accounts and plant webshells on servers, giving them full control of every site on the host.[1]

The vulnerability is almost absurd in its simplicity. Everest Forms Pro has a "Complex Calculation" feature that takes values submitted through form fields, drops them into a PHP string, and runs the result through eval(). Yes, eval() on user input. The plugin runs user input through sanitize_text_field(), but that function does not escape single quotes or other characters that influence PHP syntax. An attacker can close the string, inject arbitrary PHP code, and comment out the rest. Classic injection, 2026 edition.[2]

What the Attack Looks Like

Wordfence reports that exploitation started on April 13, 2026, and they have blocked over 29'300 attempts so far. The primary attack pattern is straightforward: an attacker submits a form field value that starts with a single quote to close the wrapping string, then injects a call to wp_insert_user() to create a new administrator account with the username "diksimarina". A trailing // comment marker ensures the rest of the generated PHP code is ignored, so no syntax error is thrown and the exploit executes cleanly.[2]

Once the attacker has admin access to WordPress, they can do anything: modify content, install plugins, plant backdoors, upload webshells, and access the database. From there, if the WordPress instance shares a server with other sites, the attacker can pivot to those as well.

Why This Hits Close to Home

I have seen this pattern play out firsthand. A WordPress plugin vulnerability on a shared hosting server was the entry point for a compromise I dealt with this month. The attacker used it to drop a PHP webshell, then used the webshell to download and run an IMAP brute-forcer. The first cleanup missed some webshells hidden in unusual locations, and the attacker created new ones during our cleanup process. The second compromise was worse than the first.[3]

The pattern is always the same: vulnerable WordPress plugin, PHP webshell, lateral movement, persistent access. The Everest Forms Pro exploit is just the latest iteration of an attack vector that has been devastating shared hosting environments for years.

The Cleanup Lessons (That I Learned the Hard Way)

After cleaning up a server compromise, here are the rules I wish I had followed from the start:

1. Search everywhere, not just obvious directories. Webshells hide in uploads folders, theme directories, and places like /wp-content/ with names designed to blend in (radio.php, 2index.php, wp-login.php in unusual locations). Zero-byte stubs are also common. If you only search the obvious places, you will miss something.

2. Block entire subnets, not just individual IPs. The attackers used three IPs from the same /24 subnet. Blocking individual IPs is a whack-a-mole game. Block the whole subnet.

3. Change every password after compromise. This is non-negotiable. If an attacker had access, assume they extracted every credential they could find. FTP passwords, database passwords, admin passwords, all of it.

4. Check for persistence mechanisms. Crontabs, SSH authorized keys, hidden directories in system paths, ld.so.preload entries. A recent rootkit writeup showed attackers using seven separate persistence mechanisms, including replacing system tools like ps, top, and lsof with fake versions that hid malware processes.[4]

5. You cannot clean a compromised system from inside it. If a rootkit is involved, every tool on the system is suspect. Boot from rescue media, mount the disk, and clean from outside. The alternative is chasing malware that keeps "reappearing" because you were never actually deleting it.

What to Do Now

If you run Everest Forms Pro, update to version 1.9.13 or later immediately. If you cannot update, disable the Complex Calculation feature. Check your admin accounts for any user named "diksimarina" or any accounts you did not create. Review your server logs for POST requests to form endpoints that contain single quotes or PHP function names.[2]

More broadly, if you run WordPress on a shared server, treat every plugin as a potential entry point. Keep everything updated, minimize the number of plugins you run, and consider whether a form plugin really needs to evaluate mathematical expressions via eval() on user-supplied input. Spoiler: it does not.