In early 2024, one of the most widely sold content-automation plugins for WordPress was found to contain a flaw so severe that attackers began weaponizing it within days of disclosure. The plugin, WP-Automatic (also known as WordPress Automatic Plugin) by ValvePress, is a premium tool sold on CodeCanyon with more than 40,000 sales. It is used to automatically scrape and post content from external sources into WordPress. Tracked as CVE-2024-27956, the vulnerability is an unauthenticated SQL injection that carries a near-maximum CVSS score of 9.9. Security researchers observed millions of attack attempts against it in the wild, making it one of the most aggressively exploited WordPress plugin vulnerabilities of the year.
If you run a site that uses WP-Automatic to aggregate or republish content, this vulnerability deserves your immediate attention. Below we break down exactly what the flaw is, how attackers abuse it, and the concrete steps to confirm whether you are exposed and lock your site down.
CVE Details at a Glance
- CVE ID: CVE-2024-27956
- Plugin: WP-Automatic / WordPress Automatic Plugin by ValvePress
- Vulnerability type: Unauthenticated SQL Injection (SQLi)
- CVSS score: 9.9 (Critical)
- Affected versions: All versions up to and including 3.92.0
- Patched version: 3.92.1 and later
- Public disclosure: March 2024
- Exploitation status: Actively exploited in the wild (millions of attempts observed)
How the Vulnerability Works
To understand this vulnerability, it helps to know two concepts: authentication bypass and SQL injection. WP-Automatic ships with a feature that lets it accept requests to a specific endpoint (the plugin’s csv.php handler) that performs work on behalf of the site. The problem is twofold. First, the authentication mechanism protecting that endpoint could be bypassed, meaning an attacker did not need a valid username or password to reach the vulnerable code. Second, once inside, user-supplied input was passed into a database query without being properly sanitized or parameterized.
SQL injection happens when an application builds a database query by directly stitching together user input and SQL commands. Normally a query is meant to be a fixed instruction with a few safe placeholders for data. But when input is not escaped, an attacker can smuggle their own SQL commands into the query. Instead of the database treating the input as a harmless value, it interprets it as executable instructions. In the case of CVE-2024-27956, an unauthenticated attacker could append additional SQL statements to the query that WP-Automatic runs, effectively executing arbitrary commands against the site’s database.
What makes this especially dangerous is the combination: no login required, and full read/write access to the database. An attacker does not need to trick an administrator into clicking anything, does not need stolen credentials, and does not need any foothold on the site. A single crafted HTTP request is enough to begin extracting data or making changes.
Real-World Impact
Because the WordPress database holds everything that defines a site, arbitrary SQL access is close to total control. In the attacks observed against CVE-2024-27956, adversaries followed a consistent playbook. They used the injection to read the wp_users table and extract administrator password hashes, then went a step further by creating brand-new administrator accounts directly in the database. With an admin account in hand, they could log into wp-admin normally and do anything a site owner could do.
From there, the typical progression included uploading malicious PHP files (web shells) to maintain persistent access, installing additional backdoors, and often renaming the vulnerable csv.php file so that other attackers could not use the same door — a sign of how contested compromised sites become. Downstream consequences for site owners included defacement, injection of spam and malicious redirects, theft of customer and user data, use of the server to attack other sites, and blocklisting by Google and hosting providers once the malicious activity was detected.
The scale was significant. Security vendors reported millions of blocked exploit attempts in the weeks following disclosure, driven by automated tooling that scanned the internet for any site still running a vulnerable version.
How to Check If You’re Affected
Work through the following checks to determine your exposure:
- Confirm the plugin is installed. In your WordPress dashboard, go to Plugins > Installed Plugins and look for “WordPress Automatic Plugin” or “WP-Automatic” by ValvePress. Because it is a premium CodeCanyon plugin rather than a wordpress.org listing, it will not appear in the official plugin directory.
- Check the version number. The version is shown beneath the plugin name on the Plugins screen. Any version at or below 3.92.0 is vulnerable. Version 3.92.1 or newer contains the fix.
- Look for signs of prior compromise. Because this flaw was exploited so heavily, an unpatched site may already be affected. Review Users > All Users for administrator accounts you do not recognize. Search your installation for unexpected PHP files, particularly recently modified or renamed files in the plugin directory. Check server access logs for suspicious POST requests to the plugin’s endpoints.
How to Fix It
The essential fix is to update the plugin, but if your site was exposed for any length of time you should also assume possible compromise and verify integrity.
- Update immediately. Upgrade WP-Automatic to version 3.92.1 or later. Because it is a premium plugin, updates may need to be pulled through the plugin’s own update mechanism or downloaded from your CodeCanyon account rather than the standard WordPress update screen.
- Audit your administrator accounts. Remove any admin users you did not create, and reset passwords for all legitimate administrator accounts. Rotate your database credentials and any API keys stored on the site.
- Scan for malware and backdoors. Use a reputable security scanner to check for web shells, injected code, and unfamiliar files. Pay special attention to modified core files and the plugin’s own directory.
- Add hardening layers. Deploy a web application firewall (WAF) to block malicious requests, restrict access to plugin endpoints where possible, and keep automatic updates enabled going forward. Regular off-site backups mean that if the worst happens, you can restore a clean copy.
If you find clear evidence of compromise, the safest path is to restore from a known-clean backup taken before the intrusion, then apply the update before bringing the site back online. Simply deleting a rogue admin account is not enough if a web shell remains in place.
Takeaway
CVE-2024-27956 is a textbook example of why unauthenticated SQL injection ranks among the most dangerous classes of web vulnerability: no credentials, no user interaction, and a direct line to your database. It also illustrates a recurring theme in WordPress security — premium plugins distributed outside the official repository can be slower to update because they do not always flow through the familiar one-click update path, leaving windows of exposure open longer. The defenses are the same ones that protect against most plugin flaws: patch quickly, keep an inventory of what you have installed and where updates come from, run a firewall, monitor for unexpected admin accounts, and maintain clean backups. Treat every plugin as part of your attack surface, and the next critical CVE becomes a routine update rather than an incident.