Between July 14 and August 18, 2026, Wordfence blocked over 440,000 attempts to exploit two critical WordPress plugin vulnerabilities. More than 250,000 targeted CVE-2026-14894 in Super Forms, while another 190,000 went after CVE-2026-32475 in Elementor Pro. Both flaws allow unauthenticated attackers to upload PHP files and execute arbitrary code.
If you're running either plugin, you're facing active exploitation at scale.
Timeline
July 14, 2026: Exploitation begins against both vulnerabilities. Initial attempts are automated, targeting sites indiscriminately.
July-August 2026: Attack volume escalates steadily. Threat actors refine their payloads and expand their target lists.
August 18, 2026: Activity peaks at over 40,000 exploit requests in a single day.
Present: Exploitation continues. Both CVEs remain attractive targets for attackers scanning the internet for unpatched installations.
Which Controls Failed
The root cause differs between plugins, but the outcome is identical: unauthenticated remote code execution.
CVE-2026-14894 (Super Forms): The plugin failed to validate file uploads properly. An attacker can submit a malicious file through a form endpoint without authentication. No checks prevent uploading executable PHP files to the web root.
CVE-2026-32475 (Elementor Pro): This vulnerability exists only on sites with at least one published Elementor page containing a Form widget with a File Upload field enabled. The plugin doesn't restrict file types or validate upload contents before writing them to disk.
Both failures share a pattern: insufficient input validation on user-controlled data. The plugins trusted that uploaded files were safe. They weren't.
Here's what should have stopped these attacks but didn't:
Authentication checks: Neither plugin required authentication before accepting file uploads. An anonymous user could trigger the vulnerability.
File type validation: The plugins didn't enforce allowlists for permitted file extensions. PHP files sailed through.
Content inspection: No scanning of file contents before writing to disk. A file named
image.jpgcontaining PHP code would execute.Execution prevention: Files landed in web-accessible directories with execute permissions. The web server happily ran uploaded PHP.
Rate limiting: No throttling on upload endpoints. Attackers submitted thousands of requests without triggering defensive responses.
What Standards Require
These failures violate specific requirements across multiple frameworks.
PCI DSS v4.0.1 Requirement 6.4.3 mandates that custom and bespoke software is developed securely. This includes validating all inputs from untrusted sources. File uploads from anonymous users are untrusted sources. You must validate file type, size, and content before processing.
OWASP ASVS v4.0.3 Section 12.1.1 requires that uploaded files are stored outside the web root, or if stored within it, that the web server is configured to prevent execution. Section 12.1.2 demands validation of file types against an allowlist, not just checking extensions.
OWASP Top 10 2021 A03:2021, Injection covers this attack class. Unrestricted file upload is a form of injection where the payload is a file rather than a string. The mitigation is the same: validate and sanitize all untrusted input.
ISO 27001 Annex A.8.28 requires secure coding practices for software development. This includes input validation controls that prevent malicious file uploads from compromising the system.
The standards are clear. File upload functionality requires multiple layers of validation. A single missing control creates a critical vulnerability.
Lessons and Action Items
If you're running WordPress, here's what you do now:
Immediate actions (today):
Check your plugin versions. Super Forms and Elementor Pro have released patches. Update immediately. Don't wait for your maintenance window.
Review your Elementor pages. If you have Form widgets with File Upload fields, disable them until you've patched and verified the configuration.
Scan your web directories for unexpected PHP files. Look for recently created files in
/wp-content/uploads/and plugin directories. Check file creation timestamps against your deployment logs.Review web server logs for POST requests to Super Forms and Elementor endpoints. Filter for 200 responses with suspicious payloads. If you see successful uploads you didn't authorize, assume compromise.
This week:
Implement file upload restrictions at the web server level. Configure your server to block execution of PHP files in upload directories. Add this to your
.htaccessor nginx config:<FilesMatch "\.php$"> Deny from all </FilesMatch>Deploy a WordPress security plugin with real-time monitoring if you haven't already. Configure it to alert on plugin updates and suspicious file changes.
Create an inventory of all WordPress sites in your environment. Document which plugins each site uses. You can't patch what you don't know exists.
This month:
Build a patch management process for WordPress. Subscribe to security advisories for your plugins. Set SLAs: critical vulnerabilities get patched within 48 hours, high severity within 7 days.
Implement automated vulnerability scanning for your WordPress installations. Run weekly scans and flag sites running outdated plugins.
Establish file integrity monitoring for your WordPress directories. Alert when files are created or modified outside your deployment process.
Review authentication requirements for all form endpoints. No functionality that writes to disk should be accessible without authentication.
Ongoing:
Conduct quarterly audits of installed plugins. Remove unused plugins entirely. Every installed plugin expands your attack surface, even if it's inactive.
Test your backup and restore procedures. If you do get compromised, you need confidence you can recover without paying ransomware demands.
The pattern here isn't new. WordPress plugin vulnerabilities appear regularly because the ecosystem is vast and code quality varies. Your defense is systematic: maintain an inventory, patch aggressively, monitor continuously, and assume any plugin could be the next CVE.
These 440,000 exploit attempts happened because attackers knew most WordPress sites patch slowly. Don't be most sites.
