The Super Forms RCE takes two requests, and the first one just asks the site for a nonce

Wordfence has blocked over 440,000 exploit attempts against two WordPress plugin vulnerabilities. The more severe flaw requires only two unauthenticated HTTP requests to achieve code execution. The first request triggers the Super Forms plugin's submit_form AJAX handler, which contains a critical flaw: it fails to verify file types or check user capabilities.

This oversight allows attackers to upload a webshell without any authentication. The second request is even more troubling. Super Forms includes a hidden AJAX action called super_create_nonce, which generates a valid nonce and session cookie for any anonymous visitor. By combining the nonce from the first request with a Base64-encoded PHP payload disguised as an image file, attackers can post a malicious code snippet to admin-ajax.php.

This payload can be saved with any .php filename, allowing the attacker to execute arbitrary commands and even create admin accounts on the compromised site. The vulnerability is present in both Super Forms and Elementor Pro plugins. However, the latter is scored lower (9.0) due to additional validation steps required for exploitation.

It's essential to note that the site must have a published page featuring a Form widget with a File Upload field for this exploit to work. Many contact and quote forms are susceptible to this attack. The exploit can be executed using a simple curl command, making it relatively easy to automate attacks. Wordfence monitored campaigns targeting both plugins simultaneously, with tens of thousands of requests per day directed at Super Forms alone.

Unfortunately, no site remained immune, as every host running the vulnerable plugin was a potential target. While premium customers receive new firewall rules promptly, free tier users are often left unprotected for up to 30 days after the release. Even with a properly configured firewall, the damage may have already been done if a webshell was dropped before the rule was implemented.

The key takeaway is clear: patch the vulnerabilities immediately, and then conduct a thorough search for any existing webshells. Run grep commands to locate suspicious files and check for unauthorized user accounts created during the attack. Once you've identified compromised hosts, isolate them, restore from a backup taken before the suspicious activity started, and change all credentials on the affected system.

If you spot a shell, take immediate action: isolate the host, restore from a backup, and rotate all credentials. Although a firewall rule blocks the initial exploitation attempts, it does not remove the webshell, so patching the vulnerability is the only reliable solution. It's worth questioning whether security plugins should provide firewall rules to free tier users at the same time as paying customers, as the 30-day delay may be seen as an unfair business practice.