Everest Forms Pro CVE-2026-3300 exploited since April 13 to plant rogue admins

Wordfence has reported a sustained, opportunistic mass-exploitation campaign against CVE-2026-3300, an unauthenticated PHP code-execution flaw in the commercial Everest Forms Pro WordPress plugin. The bug carries a CVSS score of 9.8. Wordfence published the full advisory and exploit telemetry on June 5, and the GitHub Advisory Database entry mirrors the same range.

What's affected

All versions of Everest Forms Pro ≤ 1.9.12 are vulnerable. Vendor WPEverest shipped the fix in 1.9.13 on March 18, 2026, and Wordfence coordinated disclosure on March 30. The free everest-forms plugin on WordPress.org is not the affected SKU — the bug lives in the Pro-only Calculation Addon.

The vulnerable surface is the Complex Calculation feature inside that addon. The process_filter() function accepts values submitted through form fields, concatenates them into a PHP expression string, and hands the string to eval(). User input passes through sanitize_text_field(), which strips tags but does not escape single quotes — enough to close the wrapping string literal and inject arbitrary PHP.

Exploitation status

Wordfence telemetry, reproduced from the June 5 writeup:

• April 13, 2026. First in-the-wild exploitation observed, two weeks after public disclosure.
• May 16, 2026. Single 24-hour peak of 17,900+ blocked attempts.
• June 5, 2026. Running total of 29,300+ blocked attempts across the Wordfence install base.

The dominant payload submits a calculation field whose value closes the wrapping quote, calls wp_insert_user() to create a WordPress administrator named diksimarina with the email diksimarina@gmail.com, and comments out the trailing template fragment so the eval succeeds cleanly. Once the rogue admin exists, the second-stage payload uploads a PHP web shell via the standard plugin/theme editor or the media library.

The campaign has no public attribution. No threat-intel vendor has tied the diksimarina infrastructure to a named cluster at the time of writing.

Affected-site fingerprint

If you maintain a fleet and want to scope exposure, the readme banner shipped by the Pro addon is a stable string. A baseline Shodan-style query for unpatched fleets:

http.html:"Everest Forms" http.html:"Calculation Addon"

Run the same query in Censys or against your own asset inventory. Cross-reference hits against your plugin license records — the Pro SKU ships only via the WPEverest portal, so you should be able to enumerate licensed installs from the vendor side.

Action checklist

1. Update to Everest Forms Pro 1.9.13 today. The patch is staged in the WPEverest customer portal. If you cannot update within the day, disable the Calculation Addon in Plugins → Installed Plugins → Everest Forms → Add-ons — the rest of the form builder keeps working.
2. Hunt for the rogue admin. Run wp user list --role=administrator --field=user_login,user_email (or browse Users → All Users). Any account named diksimarina, registered to diksimarina@gmail.com, or created without a matching internal ticket is compromise-grade evidence. Delete the account, then keep its row in an offline copy for forensics.
3. Sweep for web shells. Look for .php files in wp-content/uploads/, recently-modified files under wp-content/themes/ and wp-content/plugins/, and unfamiliar entries in mu-plugins/. The Wordfence scanner flags the common variants.
4. Rotate everything reachable from WordPress. Database password, SMTP credentials, WP-API and JWT keys, any OAuth client secrets stored in plugin options. Assume wp_options was readable.
5. Treat the site as breached if exploitation predates the patch. The exposure window is April 13 to whenever you applied 1.9.13 — not "since the post was published." Anything written or downloaded from the site in that window should be considered tampered until verified.

Context

This is the second time a commercial WordPress form-builder plugin has produced a mass-exploited unauthenticated RCE via unsafe eval-on-form-input in a quarter, after the long tail of the Bricks Builder and WPForms Pro patterns earlier in the year. The shared root cause is identical: a "spreadsheet-like" calculation feature that compiles user input into a PHP expression and runs it. Until WordPress vendors abandon eval() for arithmetic — a math-only AST evaluator would have killed CVE-2026-3300 at the design stage — expect a steady stream of CVSS-9.8 disclosures against this same class of feature.

If you maintain a managed-WordPress fleet, this is a near-twin of the Drupal CVE-2026-9082 PostgreSQL SQLi shape from last month: a CMS-core or near-core extension exposes an unauthenticated injection sink, mass exploitation lights up within two weeks of disclosure, and the lag between vendor patch and customer apply is what's actually getting sites taken over. The patch dropped on March 18; sites still vulnerable in mid-June are sitting on an eight-week apply gap.