Researcher h0xilo submitted a flaw in Everest Forms Pro for WordPress, tracked as CVE-2026-3300, to Wordfence’s bug bounty program and earned $325 for it. WPEverest patched the flaw on March 18. Wordfence published a full disclosure on March 30, but the exploitation started on April 13. That’s a 26-day window between patch and first attack, which sounds manageable until you realize thousands of sites running Everest Forms Pro still haven’t updated, and the attackers noticed.
The vulnerability lives in the plugin’s Complex Calculation feature. The culprit is a function called process_filter() inside the Calculation Addon, which takes values submitted through form fields and builds them into a PHP code string before passing that string to eval().
“This is due to the Calculation Addon’s process_filter() function concatenating user-submitted form field values into a PHP code string without proper escaping before passing it to eval().” reads the report published by Wordfence. “The sanitize_text_field() function applied to input does not escape single quotes or other PHP code context characters.”
The consequence is that any string-type form field, text, email, URL, select, or radio, becomes an injection point on any form using Complex Calculation.
No credentials needed. The attacker submits a crafted value through a public-facing form: a single quote to break out of the string literal, followed by arbitrary PHP code, followed by // to comment out the rest of the generated code and prevent a syntax error. The server processes the form, the calculation runs, and the injected PHP executes alongside it. The most common payload observed in Wordfence’s blocked requests is surgical in its simplicity.
“The attacker submits a value for a text field that begins with a single quote to close the wrapping string literal, followed by a PHP statement that calls wp_insert_user() to create a new administrator account with the username ‘diksimarina’.” continues the report. “The trailing // comment marker ensures the rest of the generated PHP code, including the closing quote, is treated as a comment and does not cause a syntax error.”
The server echoes back either ADMINCREATED or ADMINEXISTS depending on whether the account already existed, which tells the attacker exactly what happened. Subtle it is not.
Once that administrator account exists, the attacker can log in and do anything: upload web shells, modify themes or plugins, install backdoors, read and exfiltrate database contents. It’s full site ownership, delivered through a contact form. Wordfence recorded 29,300 blocked exploit attempts since public disclosure, with one particularly aggressive day standing out. On May 16, over 17,900 attempts were blocked in a single 24-hour period. One IP address, 202.56.2.126, accounts for over 26,300 of the total blocked requests on its own.
“Our threat intelligence indicates that attackers started actively targeting this vulnerability on April 13th, 2026, with mass exploitation occurring on May 16th, 2026. The Wordfence firewall has already blocked over 29,300 exploit attempts targeting this vulnerability.” states Wordfence.

The experts pointed out that Wordfence Premium, Care, and Response users had a firewall rule in place since February 27, before public disclosure. Free Wordfence users got the same rule on March 29. Neither group is safe from future attempts if the underlying plugin isn’t updated.
The fix is version 1.9.13, out since March 18. Update immediately. After updating, open your WordPress user list and look for any administrator account named “diksimarina” or registered to [email protected]. If you find one, the site is compromised: audit for web shells, check recently modified files across themes and plugins, rotate all credentials, and treat the database as potentially read. Also review server logs for requests originating from 202.56.2.126, 209.146.60.26, 15.235.166.18, 2402:1f00:8000:800::40db, and 185.78.165.153.
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, WordPress)