CVE-2026-3300: Everest Forms Pro Runs Arbitrary PHP from a Form Field

BLOG: Linux Server Security

CVE-2026-3300: Everest Forms Pro Runs Arbitrary PHP from a Form Field. No Login Required

WHAT HAPPENED

Your site takes inquiries through a contact form. Someone fills in the Name field — and arbitrary PHP code runs on your server. Not because the database was breached, not because a password was guessed. Because the plugin took whatever the user typed and fed it straight into PHP’s eval().

That’s CVE-2026-3300 — a critical remote code execution vulnerability in the Everest Forms Pro WordPress plugin, CVSS 9.8. All versions up to and including 1.9.12 are affected. The patch shipped on March 18, 2026 — version 1.9.13. Active exploitation began on April 13. By early June, Wordfence’s firewall had blocked over 29,300 exploit attempts, with more than 17,900 of those hitting in a single day on May 16. The attacks are ongoing.

WHAT IS EVEREST FORMS PRO

Everest Forms Pro is a commercial plugin from WPEverest, built on top of the free Everest Forms. It fills a specific gap: when a basic contact form isn’t enough — you need a multi-step application with conditional fields, a booking form with time slot selection, or a price calculator that works right inside the form without pushing the user to a cart page. The typical customer is a small e-commerce store, a service business, or an agency that needs dynamic pricing logic built into their forms. Roughly 4,000 active installations according to Wordfence — not a huge number, but it offers no protection: botnets don’t filter targets by plugin popularity; they scan everything.

The vulnerable piece is a Pro-specific feature called Complex Calculation — an addon that lets you build math formulas using form field values. Quantity times price, promo code discount applied, shipping cost added to the total. All of this runs server-side when the form is submitted — PHP computes the result and sends it back to the user. Right there, between user input and server-side computation, someone left a hole the size of a truck.

HOW THE VULNERABILITY WORKS

When a form with Complex Calculation enabled is submitted, field values land in the plugin’s process_filter() function. There they’re concatenated into a PHP code string, which then gets passed to eval(). The intent makes sense: dynamically evaluate a formula built from user input. The problem is that before any of this happens, the input only passes through sanitize_text_field().

That WordPress function strips HTML tags and extra whitespace — it removes <script> tags and similar constructs. But single quotes and other characters that matter in PHP syntax? It leaves those alone. In the context of generating PHP code, that’s catastrophic: input that looks perfectly “clean” from an HTML perspective can be a fully working PHP injection. The Everest Forms Pro developers used the wrong tool for the job — an HTML sanitizer applied where PHP escaping was needed.

The result: an attacker submits a crafted PHP payload through any string-type form field — text, email, URL, select, or radio — on any form that uses Complex Calculation. No account needed. No login. Any visitor to the site can trigger it. The server receives the request, process_filter() assembles the string, and eval() executes it as PHP code under whatever user the web server runs as.

REAL-WORLD ATTACK CHAIN

It starts with automated scanning. Bots crawl WordPress sites looking for Everest Forms Pro by its characteristic CSS classes and form attributes — signatures the plugin injects into every page it renders. This is fully automated: specialized crawlers sweep millions of sites hunting for specific plugin fingerprints. Once a form with Complex Calculation is found, the bot fires a POST request with a crafted payload in a text field. That payload creates a PHP file on the server — a web shell. From discovery to shell placement, the whole thing takes seconds.

After that, the attacker shifts to manual work. Through HTTP requests to the web shell, they read wp-config.php — that’s where the database credentials live. With the database password in hand, they connect to MySQL and create a new WordPress administrator account — the exact pattern Wordfence observed in confirmed attacks. In parallel, they browse the filesystem: other config files, SSH keys in home directories, .env files, log files that might contain credentials. If the server runs multiple sites in the same PHP-FPM pool, every one of those sites’ files is now reachable — not just the one with the vulnerable form. One site compromised, ten exposed. Classic lateral movement.

Wordfence identified a specific compromise marker: the string diksimarina appearing in logs and in files created by the attacker. The heaviest attack traffic originates from two IP addresses: 202.56.2.126 and 209.146.60.26. Wordfence publishes a full IOC list, but these two are the most active. Changing IPs takes the attacker minutes, so blocking specific addresses is a useful temporary measure — not a permanent fix.

TIMELINE

February 2026: researcher h0xilo reported the vulnerability through the Wordfence Bug Bounty program. March 18: WPEverest released the patch — version 1.9.13. March 30: Wordfence published the CVE and technical details. April 13: active exploitation began — 26 days after the patch dropped.

That 26-day window between patch and exploitation is par for the course with WordPress plugins. Most sites don’t auto-update. Some owners never check plugin changelogs at all. In those 26 days, attackers studied the patch, reconstructed the vulnerable code, built an exploit, and started mass scanning. May 16 was the peak: 17,900 attempts in a single day — a number that points to someone adding CVE-2026-3300 to an automated mass-scanning toolkit.

WHY IT MATTERS

Four thousand installations sounds modest compared to plugins like Contact Form 7 or Yoast SEO. But WordPress attacks aren’t targeted campaigns — they’re wide nets. Botnets scan continuously and hit everything that matches. If your site runs Everest Forms Pro and hasn’t been updated, it’s already in the attacker’s list, regardless of how small or “not worth targeting” it seems.

The more important point: RCE through a form means full server access at the web process level. This isn’t a SQL injection where the attacker gets database reads — it’s arbitrary code execution. That means web shells, reading any file PHP can touch, modifying site code, stealing credentials from wp-config.php. If other sites share the same PHP-FPM pool on that server, they’re all exposed. One vulnerable form, and shared hosting becomes a single point of failure.

There’s a less obvious risk too. The pattern behind this bug — user input flowing into eval() — isn’t unique to Everest Forms Pro. The WordPress plugin ecosystem is enormous, and plenty of plugins implement similar dynamic calculation logic. CVE-2026-3300 is a useful reminder that any plugin with “smart” forms, price calculators, or dynamic fields might be doing something similar under the hood. As a sysadmin you can’t audit every plugin’s code — but you can keep them updated, monitor Wordfence Intelligence, and set up alerts for new PHP files appearing in your site directory. That narrows the exposure window from “until someone breaks in” to “until the patch ships.”

WHAT TO DO

Start by checking the plugin version. In the WordPress admin panel: Plugins → Installed Plugins → find Everest Forms Pro and check the version. It needs to be 1.9.13 or higher. If it’s lower, update immediately through the standard WordPress update mechanism.

You can also check the version from the command line via WP-CLI:

wp plugin get everest-forms-pro --fields=name,version,status

If the version is below 1.9.13, update it. A successful update looks like this: Success: Updated 1 of 1 plugins.

wp plugin update everest-forms-pro

If the plugin isn’t actively in use, deactivate and delete it. An inactive plugin with vulnerable code sitting on disk still carries risk in certain server configurations:

wp plugin deactivate everest-forms-pro
wp plugin delete everest-forms-pro

Next, check whether the site has already been compromised. Attacks have been running since April — if the plugin was unpatched all that time, the logs and filesystem need a look. Start with nginx access logs, looking for POST requests to form endpoints from the known attacker IPs:

grep -i "POST" /var/log/nginx/access.log | grep -i "everest\|evf_" | grep "202.56.2.126\|209.146.60.26"

Check for PHP files created or modified in the past two months — that’s how long active exploitation has been running. The output will include legitimate files from routine WordPress and plugin updates, which live in wp-admin/, wp-includes/, and plugin directories under wp-content/plugins/. Flag anything in wp-content/uploads/ (PHP files should never end up there), anything in the site root with a strange name — random letters, numbers — and anything outside WordPress’s standard directory structure:

find /var/www/html -name "*.php" -mtime -60

Search for the compromise marker Wordfence identified in the attacks:

grep -r "diksimarina" /var/www/html/

Check the WordPress administrator list for accounts you don’t recognize:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

If suspicious PHP files turn up, unknown admin accounts appear, or diksimarina shows up anywhere — the site is compromised. Restoring from a backup taken before April 13 is more reliable than trying to scrub malware by hand: the attacker may have planted multiple backdoors across the filesystem.

Blocking the attacker IPs at the nftables level reduces log noise. This works if your nftables configuration already includes a set named blocklist in the inet filter table — as set up in the nftables course:

nft add element inet filter blocklist { 202.56.2.126, 209.146.60.26 }

If Cloudflare WAF sits in front of WordPress, you can block requests containing PHP injection patterns in the POST body via a Custom Rule. But none of this replaces updating the plugin — that’s the only thing that closes the attack vector completely, rather than just blocking IPs the attacker can swap out in minutes.

CONCLUSIONS

CVE-2026-3300 is a textbook example of how one misapplied function turns a contact form into a full server takeover. CVSS 9.8, unauthenticated RCE, active exploitation since April, 29,300 blocked attempts. The patch has been out since March 18 — version 1.9.13.

If Everest Forms Pro is on your server: check the version now. If it’s below 1.9.13, update and review logs from April 13 onward. If you don’t need the plugin, delete it.