A WordPress Form Plugin Fed Your Input Straight Into eval(). CVE-2026-3300 Is a 9.8, It's Being Exploited 29,000 Times, and the Payload Just Wants an Admin Named 'diksimarina'.
- Patrick Duggan
- 1 minute ago
- 4 min read
There is a specific category of vulnerability we keep writing about because WordPress keeps shipping it, and Everest Forms Pro is this month's entry. The bug, CVE-2026-3300, is a 9.8 — unauthenticated remote code execution — and the mechanism is almost insultingly direct. Everest Forms Pro is a commercial form builder with roughly four-thousand active installations, and its Calculation Addon has a function, process_filter(), whose job is to do math on the numbers a visitor types into a form. To do that math, it takes the user-submitted field values, concatenates them into a string of PHP code, and hands that string to eval() — the function that executes whatever PHP you give it. The only thing standing between a form submission and code execution is a call to sanitize_text_field(), which strips some HTML but does not escape single quotes or the other characters that let an attacker break out of the intended string and write their own PHP. So a form built to add two numbers will instead run whatever the attacker types, with the privileges of the web server. The form is the door. eval() is the room behind it. And the lock was a function that was never designed to be a lock.
If this sounds familiar, it should, because it is the third time in about a month we have documented the same family of mistake. In May we wrote up CVE-2026-7458, where a WordPress plugin called User Verification authenticated you as anyone if you submitted the literal value "true" for the one-time passcode, because PHP's loose comparison treats true and a valid code as equal — an authentication bypass born from weak typing. We wrote up CVE-2026-3844, a 9.8 that Cloudways shipped to four-hundred-thousand sites. And now Everest Forms feeds form input into eval(). The connective tissue is PHP's footguns meeting the WordPress plugin economy: a language with eval(), loose comparison, and silent type juggling, wired into thousands of small commercial add-ons written under deadline by shops with no security team, each one running with full application privilege inside sites that handle real data. The core platform is not the soft surface anymore. The plugins are. And the same primitive — unescaped user input reaching a dangerous sink — produces a fresh 9.8 every few weeks because the conditions that produce it never change.
The exploitation is not theoretical, and the timeline is the part defenders need. Wordfence telemetry shows the attacks started on April 13, roughly two weeks after public disclosure — the standard interval between a patch landing and the mass-scanning crews weaponizing it, because a published fix is a published diff, and a diff is a treasure map. Wordfence's firewall has since blocked more than twenty-nine-thousand-three-hundred exploit attempts against this single flaw, with a single-day surge on May 16 accounting for over seventeen-thousand-nine-hundred of them. That shape — a long tail with one enormous spike — is what automated, opportunistic exploitation looks like once a working payload gets shared into a botnet's toolkit. And the payload itself tells you what the attackers want: the leading exploit attempt registers a new administrator account named "diksimarina." Not subtle, not stealthy — just a fresh admin on your site, which is the cheapest possible path from code execution to durable control. If that account exists on your WordPress install, you were not almost-breached. You were breached.
The protective read is mercifully simple, which is the upside of a bug this mechanical. WPEverest patched it in version 1.9.13; every release up to and including 1.9.12 is exposed, so update now, tonight, not at the next maintenance window — a 9.8 with thirty-thousand logged attempts does not respect your change calendar. Then hunt, because patching forward does not evict an attacker who already walked in: look for an administrator account named "diksimarina" specifically, and more broadly for any admin user you did not create, then look for unexpected PHP files dropped under wp-content, unfamiliar scheduled tasks, and modified theme or plugin files with recent timestamps. If you do not use the Calculation Addon, the exposure is narrower, but the safe assumption on a form plugin under active mass-exploitation is to patch regardless and verify the addon's status second. And the standing advice that would have blunted all three of this month's plugin 9.8s: run a web application firewall in front of WordPress, keep the plugin count to what you actually use, and treat every commercial add-on as privileged third-party code inside your trust boundary — because that is exactly what it is.
The honest 95%: we cannot tell you the four-thousand-install figure captures every exposed site, because it counts the commercial Pro plugin's active installs and does not account for sites that disabled telemetry or run bundled copies, so the real exposed population is a floor, not a ceiling. We cannot promise "diksimarina" is the only payload; it is the leading one in the telemetry, but a flaw that hands an attacker arbitrary PHP is a flaw that runs whatever the attacker decides to run tomorrow, and the admin-account trick is just the cheapest first move. What we can tell you is that the bug is real, the exploitation is mass-scale and dated to April 13, the fix is one version bump away, and the indicator of compromise is a username you can grep for in the next five minutes. Patch to 1.9.13, search for the admin you did not make, and add Everest Forms to the running list of reasons the WordPress plugin is the part of your stack most likely to get you owned this quarter.
The threat feed this post is built on
1.14M+ IOCs, STIX 2.1, precursor signals, supply-chain detection. Free API key in 30 seconds.