Critical Vulnerability in Everest Forms Pro Plugin Exploited to Compromise WordPress Sites
A critical security flaw in the Everest Forms Pro WordPress plugin has been actively exploited by threat actors, leading to complete site compromises. The vulnerability, identified as CVE-2026-3300 with a CVSS score of 9.8, affects all versions up to and including 1.9.12. A patch was released on March 18, 2026, with version 1.9.13.
The issue stems from the Calculation Addon’s `process_filter()` function, which concatenates user-submitted form field values into a PHP code string without proper escaping before passing it to the `eval()` function. The `sanitize_text_field()` function applied to input does not escape single quotes or other PHP code context characters, allowing unauthenticated attackers to inject and execute arbitrary PHP code on the server by submitting crafted values in any string-type form field (text, email, URL, select, radio) when a form uses the ‘Complex Calculation’ feature.
Exploitation of this vulnerability enables attackers to execute arbitrary PHP code on the server, potentially leading to the creation of rogue administrator accounts, deployment of web shells, and establishment of persistent footholds within the server.
WordPress security company Wordfence observed exploitation of this flaw beginning April 13, 2026, blocking over 29,300 exploit attempts to date. In the last 24 hours alone, 16 attack attempts were recorded. A common payload involves creating an administrator account named diksimarina with the email address [email protected] on compromised sites.
The attacks have originated from the following IP addresses:
– 202.56.2.126
– 209.146.60.26
– 15.235.166.18
– 2402:1f00:8000:800::40db
– 185.78.165.153
In a related development, Sansec reported multiple skimmer campaigns, including one that utilizes Stripe as a command-and-control (C2) server and data exfiltration sink. This campaign exploits the reputation of Stripe to bypass Content Security Policy rules and network filters.
The attacker leverages Stripe as free infrastructure, using it as a writable database for stolen cards and a code-hosting endpoint for the skimmer, both behind a domain that CSP rules and network filters trust by default.
The campaign relies on Google Tag Manager (GTM) and Stripe domains—googletagmanager.com and api.stripe.com—which are both implicitly trusted by online stores. Malicious code is loaded from a GTM container and executed on every page that loads it.
On Magento and Adobe Commerce checkout pages, the skimmer extracts an obfuscated script from a Stripe customer account’s metadata field and saves the financial information, billing and email addresses, and phone numbers entered by unsuspecting users to localStorage. The captured data is then exfiltrated back to the attacker’s Stripe account.
Every stolen card becomes a ‘customer’ in the attacker’s account. On success, the loader deletes the localStorage entry to prevent duplicate records. The attacker can later list their stolen cards by calling the same API with the same key, effectively using Stripe’s customer database as a free, durable exfiltration sink.
