CVE-2026-3300 and WordPress admin account abuse
Everest Forms Pro versions 1.9.12 and earlier are exposed here, and the flaw sits in a feature that should never have been left this close to executable code. The calculation path takes form input, drops it into generated PHP, and relies on sanitize_text_field() to keep things sane. It does not keep things sane.
The vulnerable path runs through Everest Forms Pro’s calculation feature
The failure starts with how the plugin builds code. Form values are inserted into a PHP string, then passed to eval(). If an attacker controls a field value, they control part of the code that gets executed.
Form input becomes PHP code before eval() sees it
The sanitisation is weak in the wrong place. sanitize_text_field() strips some noise, but it does not escape single quotes in a way that protects a PHP string literal. That leaves a narrow but reliable opening for code injection.
Why a single quote is enough to break the wrapper
A payload can begin with a single quote, close the wrapping string, and then add PHP that runs inside the generated calculation. A trailing // comment can hide the rest of the generated code, including the closing quote, so the parser does not choke on the mess left behind. It is ugly, but it works.
Account creation is the real payoff for attackers
Remote code execution on a WordPress site is bad enough. In practice, the more useful move is to create an administrator account and come back later with normal login access. That is the part defenders tend to notice too late.
wp_insert_user() turns code execution into admin access
The injected PHP can call wp_insert_user() to create a new administrator. Once that account exists, the attacker no longer needs the original exploit path for routine access. Plugin installation, theme edits, backdoors, and webshells all become easier.
The diksimarina account is a useful indicator, not the whole story
A visible account name can help with detection, but it should not become a comfort blanket. The presence of a diksimarina administrator account is a sign of exploitation, not a guarantee that every affected site will use the same username. Any unexpected admin account deserves the same treatment.
What to check on live sites before the compromise spreads
The immediate task is boring and practical: look for signs of compromise, then close the hole. Delay gives attackers time to add their own access paths and bury them under ordinary admin activity.
Review administrator accounts, plugin versions, and request logs
Check whether Everest Forms Pro is installed and whether the version is 1.9.12 or earlier. Review administrator accounts for anything unfamiliar, including diksimarina. Then inspect request logs around the form submission path for odd payloads, repeated hits, or bursts from the same source.
Block known attacker IPs and patch Everest Forms Pro without delay
Wordfence reported active exploitation and flagged 202.56.2[.]126 and 209.146.60.26 among the sources involved. Blocking those addresses is sensible, but it is only a containment step. Patch Everest Forms Pro straight away and treat any exposed site as a candidate for follow-up investigation.
