CVE-2024-10542: Critical Authorization Bypass in CleanTalk Anti-Spam Plugin Lets Attackers Install Any Plugin (200,000+ Sites)

In November 2024, security researchers disclosed a critical vulnerability in one of WordPress’s most widely used spam-fighting tools: the Spam protection, Anti-Spam, FireWall by CleanTalk plugin. Tracked as CVE-2024-10542, the flaw carries a near-maximum CVSS score of 9.8 and affects more than 200,000 active installations. The irony is hard to miss: a plugin installed specifically to keep bad actors out contained a hole that let unauthenticated attackers install any plugin they wanted, paving the way to a complete site takeover. If you run CleanTalk on your site, this is one to understand and act on.

CVE Details at a Glance

• CVE ID: CVE-2024-10542
• Plugin: Spam protection, Anti-Spam, FireWall by CleanTalk
• CVSS Score: 9.8 (Critical)
• Vulnerability type: Authorization bypass leading to unauthenticated arbitrary plugin installation (and potential remote code execution)
• Affected versions: All versions up to and including 6.43.2
• Patched version: 6.44 fixes this specific flaw; upgrade to 6.45 to also close the closely related CVE-2024-10781
• Active installations: 200,000+

How the Vulnerability Works

To understand this flaw, it helps to know how CleanTalk talks to its own cloud service. The plugin communicates with CleanTalk’s servers to coordinate spam filtering, and some of the plugin’s internal actions are meant to be triggered only by CleanTalk’s own infrastructure. To decide whether an incoming request is legitimate, the plugin tried to verify where the request came from rather than requiring a proper secret or signed token.

Specifically, a function named checkWithoutToken attempted to authorize requests by checking the originating IP address and its associated domain name using a reverse DNS lookup. The logic essentially said: “If this request appears to come from a CleanTalk-owned host, trust it.” The problem is that both of the checks used to confirm the source were spoofable. An attacker could craft requests that made the plugin believe they originated from a trusted IP and a trusted subdomain, when in reality the attacker controlled both.

This is a classic case of trusting the network instead of verifying identity. Reverse DNS records and the apparent source of a request are not reliable proof of who is really making it. By setting up DNS records that resolve in a way the plugin expected, or by manipulating the values the plugin inspected, an attacker could satisfy the authorization check without possessing any legitimate credential or API token.

Once past that check, the attacker could reach privileged functionality the plugin exposed, including the ability to install and activate plugins. No login, no valid token, no administrator account required. That is what makes this an unauthenticated vulnerability, and why it scores so high.

Real-World Impact

Being able to install an arbitrary plugin on someone else’s WordPress site is, for practical purposes, game over. A plugin is just PHP code that WordPress executes with full server privileges. An attacker who can install and activate one can:

• Upload a plugin that contains a backdoor or web shell, giving them remote code execution on the server.
• Create hidden administrator accounts to maintain persistent access even after the original hole is patched.
• Exfiltrate sensitive data, including customer records, form submissions, and database credentials.
• Inject spam, SEO poisoning, or malicious redirects that damage your search rankings and reputation.
• Pivot to defacement, ransomware-style lockouts, or use the site as a launchpad to attack visitors.

The vulnerability’s official description notes that arbitrary plugin installation “can be leveraged to achieve remote code execution if another vulnerable plugin is installed and activated.” In plain terms: even if the plugin an attacker installs is not malicious on its own, they can deliberately install a known-vulnerable plugin and then exploit it. Either path ends in the same place. Because attacks against high-value WordPress plugins are frequently automated at scale, a flaw like this is typically probed by bots within days of public disclosure.

How to Check If You’re Affected

You are potentially affected if your site runs the CleanTalk anti-spam plugin at version 6.43.2 or earlier. Here is how to confirm:

• Log in to your WordPress dashboard and go to Plugins → Installed Plugins.
• Look for Spam protection, Anti-Spam, FireWall by CleanTalk and note the version number shown beneath it.
• If the version is 6.43.2 or lower, your site is vulnerable and needs to be updated immediately.
• If you manage multiple sites, check each one. The plugin’s large install base means it is easy to forget where it is deployed.

If you cannot access the dashboard, you can also confirm the version by checking the plugin’s readme file on the server, typically located at /wp-content/plugins/cleantalk-spam-protect/readme.txt, where the “Stable tag” line reflects the installed version.

How to Fix It

The fix is straightforward: update the plugin. CleanTalk patched CVE-2024-10542 in version 6.44. Because a second, closely related authorization weakness (CVE-2024-10781) was patched shortly afterward in version 6.45, the safest move is to update all the way to 6.45 or later.

• Go to Plugins → Installed Plugins, find the CleanTalk plugin, and click Update Now. If you see no update prompt, click Dashboard → Updates and check again.
• After updating, confirm the version reads 6.45 or higher.
• Enable automatic updates for the plugin so future security releases apply without manual intervention.

Beyond patching, take a moment to harden and verify, because a site running a vulnerable version may already have been probed:

• Audit your installed plugins. Look for any plugin you do not recognize or did not install yourself, and remove it. Arbitrary plugin installation is the whole point of this exploit.
• Review administrator accounts. Delete any unfamiliar admin users and rotate passwords for the ones you keep.
• Scan for malware and web shells, especially unexpected PHP files in wp-content/uploads or the plugins directory.
• Check your logs for suspicious plugin installation or activation events around and after the disclosure date.
• Run a web application firewall so that even zero-day authorization bypasses can be blocked at the edge before they reach vulnerable code.

Takeaway

CVE-2024-10542 is a textbook reminder that authorization based on network location is not authorization at all. IP addresses and reverse DNS records can be spoofed, so any security decision that hinges on them is fragile by design. The lesson for site owners is less about this one plugin and more about the habits that keep WordPress safe: keep everything updated, enable automatic updates where you can, remove plugins you no longer use, review your admin accounts regularly, and run a firewall as a safety net for the days between a vulnerability being discovered and your site being patched. A spam plugin turning into an entry point is exactly the kind of surprise that good security hygiene is meant to catch.