A remote code execution vulnerability in Everest Forms Pro (CVE-2026-3300) has generated over 29,300 exploitation attempts between April 13 and June 6, while a parallel campaign uses Stripe payment infrastructure as command-and-control infrastructure to exfiltrate checkout data from WooCommerce stores, according to security analyses published by Wordfence and Sansec. The convergence marks a tactical shift in WordPress attacks: exploiting plugin vulnerabilities to create persistent access while using whitelisted services to bypass content security policies.
TL;DR: Attackers exploit a critical WordPress forms plugin vulnerability (CVSS 9.8) while separate skimmer campaigns hide malicious code inside Stripe customer metadata fields, treating the payment processor as free hosting infrastructure that evades most CSP filters.
Everest Forms Pro Exploitation Delivers Unauthenticated Remote Code Execution
The Everest Forms Pro vulnerability affects all plugin versions through 1.9.12 and was patched in version 1.9.13 on March 18, 2026. The flaw resides in the plugin's Calculation Addon, which concatenates form field values into a PHP code string and passes the result to eval() without context-appropriate sanitization, Wordfence disclosed. Attackers can inject malicious payloads through text, email, URL, select, or radio form fields—no authentication required.
Wordfence firewall telemetry recorded 16 exploitation attempts in the 24 hours preceding June 8, with attackers consistently attempting to create a rogue administrator account labeled "diksimarina" using a specific email address. The persistence tactic mirrors patterns observed in prior WordPress plugin compromises targeting admin account creation, where initial access serves as a beachhead for web shell deployment or database exfiltration.
The vulnerability carries a CVSS score of 9.8, indicating critical severity. Once exploited, attackers gain the ability to execute arbitrary PHP on the hosting server, escalating from a plugin-level flaw to full infrastructure compromise. Agency operators managing white-label WordPress deployments face compounded liability: a single vulnerable plugin on one client site can become the entry point for lateral movement across shared hosting environments or multisite networks.
Stripe Metadata Fields Repurposed as Command-and-Control Hosting
The second attack vector operates independently but targets the same WooCommerce ecosystem. Sansec identified skimmer campaigns that embed obfuscated JavaScript inside Stripe customer metadata fields, then load that code onto checkout pages via Google Tag Manager containers. The malicious scripts execute on every page rendering the compromised GTM container, harvesting payment card data, billing addresses, email addresses, and phone numbers before exfiltrating them back to Stripe-hosted endpoints.
The tactic exploits two infrastructure realities: Google Tag Manager is ubiquitous in e-commerce analytics stacks, and Stripe endpoints appear in nearly every site's content security policy whitelist. By treating Stripe as free code hosting and data storage, attackers bypass blocklist-based defenses that would flag traditional C2 domains. The skimmer extracts itself from Stripe metadata, writes to localStorage, and operates without triggering CSP violations or network anomaly alerts calibrated to flag external domains.
Sansec's analysis documented the technique across Magento and Adobe Commerce installations, but the architectural pattern applies to any WordPress site integrating Stripe via WooCommerce or custom checkout implementations. For agencies managing client portfolios, the implication is stark: standard WooCommerce checkout integrations become attack surfaces when trusted third-party services are weaponized.
Patch Discipline and Content Security Policy Gaps
The Everest Forms Pro patch shipped March 18, yet exploitation attempts continued through early June—a 10-week window indicating slow update adoption. White-label agencies operating maintenance contracts across dozens of client sites face a logistics problem: plugin vulnerabilities require coordinated, time-sensitive updates across portfolios that may span multiple hosting providers, staging protocols, and client approval workflows.
The skimmer campaigns surface a separate operational gap. Most WooCommerce sites implement content security policies permissive enough to allow Google Tag Manager and Stripe JavaScript execution, treating both as trusted infrastructure. Hardening CSP rules to restrict inline script execution or metadata-based code loading requires testing against legitimate analytics and payment flows—a cycle that stretches patch-to-production timelines when agencies lack isolated staging environments for each client.
Wordfence recommended immediate updates to Everest Forms Pro version 1.9.13 or later, along with user account audits for unauthorized administrator entries matching the "diksimarina" indicator. For skimmer mitigation, Sansec advised integrity monitoring of GTM container contents and periodic audits of Stripe metadata fields for non-business data—both manual processes that scale poorly across agency portfolios without automation.
What This Means for Agency Owners
Agencies operating white-label WordPress delivery models carry direct liability for plugin security posture on client sites, particularly when those sites process financial transactions. The Everest Forms Pro RCE demonstrates that critical-severity patches can sit unapplied for months across production environments, exposing agencies to breach notifications, payment card industry compliance failures, and client litigation. The operational answer is automated patch monitoring with client-side notification protocols, not quarterly manual audits.
The Stripe-as-C2 tactic reveals a second pressure point: whitelisting trusted services without behavioral monitoring creates blind spots that static security tools miss. Agencies shipping WooCommerce implementations should audit content security policies for script-src and connect-src directives, restricting inline execution and implementing subresource integrity checks on GTM containers. The skimmer campaigns also validate the case for staging environment parity—malicious code inserted via GTM metadata won't surface in development environments that use separate analytics properties.
For white-label partners, this dual-threat scenario underscores the need to treat security maintenance as partner infrastructure, not a client-side responsibility. When a single unpatched plugin or a compromised GTM container can cascade across dozens of live sites, agencies must deploy centralized vulnerability scanning, automated patch deployment workflows, and real-time monitoring of third-party script behavior—capabilities that typically require dedicated security tooling, not per-client WordPress dashboards.