CVE-2024-10542 Exploit & Vulnerability Analysis

1. Vulnerability Background

What is this vulnerability?

• CVE-2024-10542 is an authorization bypass in the WordPress plugin "Spam protection, Anti-Spam, FireWall by CleanTalk".
• The bug exists in the remote call authorization flow used by the plugin’s checkWithoutToken() mechanism.
• The plugin attempts to trust incoming requests from CleanTalk infrastructure by inspecting the reverse DNS of the request source IP.
• In versions up to and including 6.43.2, this trust decision is vulnerable to reverse DNS spoofing and substring matching abuse.

Why is it critical/important?

• The vulnerability allows unauthenticated attackers to bypass normal token/API-key based authorization.
• Through this bypass, attackers can install and activate arbitrary plugins.
• Arbitrary plugin installation/activation can lead to remote code execution when combined with an already vulnerable or malicious plugin.
• The vulnerability affects the integrity of the WordPress installation and can lead to full site compromise.

What systems/versions are affected?

• CleanTalk WordPress plugin versions up to and including 6.43.2.
• Any WordPress site with this plugin active and with the remote call endpoint exposed to the public internet.

2. Technical Details

Root cause analysis

• The vulnerable code is in lib/Cleantalk/ApbctWP/RemoteCalls.php.
• Old logic used:
  • Helper::ipResolve(Helper::ipGet())
  • strpos(..., 'cleantalk.org') !== false
• This logic assumed that a resolved hostname containing cleantalk.org meant the request came from a legitimate CleanTalk server.
• The check was:
  • weak because it used substring matching
  • dependent on reverse DNS trust
  • vulnerable to reverse DNS spoofing or maliciously crafted PTR records
• checkWithoutToken() also allowed any remote call action when it returned true, meaning privileged operations could execute without a valid token.

Attack vector and exploitation conditions

• Attacker needs to send a request to the CleanTalk remote call endpoint with:
  • spbc_remote_call_action
  • plugin_name among expected values (antispam, anti-spam, apbct)
• If the request source IP resolves to a hostname containing cleantalk.org, the request is accepted.
• Because the hostname check is substring-based, names like:
  • evil.cleantalk.org.attacker.com
  • cleantalk.org.evil.net can pass.
• An attacker who controls an IP address or a DNS record can exploit this by ensuring the PTR record includes the target string, or by using a compromised host with a suitable reverse DNS.

Security implications

• Unauthorized remote actions can be executed without authentication.
• The plugin can be forced to install and activate arbitrary plugins.
• Remote code execution becomes possible if the attacker installs a backdoor plugin or enables an existing vulnerable plugin.
• The vulnerability undermines the assumption that CleanTalk-originated remote calls are safe simply because of reverse DNS content.

3. Patch Analysis

What code changes were made?

• In lib/Cleantalk/ApbctWP/RemoteCalls.php:
  • A fixed allowlist of trusted CleanTalk servers was added:
    • netserv3.cleantalk.org
    • netserv4.cleantalk.org
  • The authorization check was changed from:
    • strpos(Helper::ipResolve(Helper::ipGet()), 'cleantalk.org') !== false to:
    • in_array(Helper::ipResolve(Helper::ipGet('remote_addr')), $rc_servers, true)
  • The source IP retrieval was tightened from generic Helper::ipGet() to Helper::ipGet('remote_addr').
  • A new action whitelist was introduced via isAllowedWithoutToken($action).
  • Tokenless execution is now limited to only safe actions:
    • get_fresh_wpnonce
    • post_api_key

How do these changes fix the vulnerability?

• Exact hostname allowlist:
  • removes substring matching and reverse DNS content trust
  • only specific known CleanTalk server hostnames are accepted
• Source IP hardening:
  • remote_addr ensures the actual connection IP is evaluated instead of possibly spoofable header-derived values
• Action allowlist:
  • even if a trusted server check passes, only low-risk actions can execute without token authentication
  • prevents arbitrary privileged operations from being invoked

Security improvements introduced

• stronger validation of remote-call source
• removal of reverse DNS spoofing as an authentication factor
• reduced attack surface through action-level restrictions
• adherence to least privilege for unauthenticated or tokenless requests

4. Proof of Concept (PoC) Guide

Prerequisites for exploitation

• Target WordPress site running CleanTalk plugin version <= 6.43.2
• Remote call endpoint reachable from attacker-controlled network
• Ability to control or influence reverse DNS for the source IP used for the request
• Knowledge of the plugin’s remote-call parameters and action names

Step-by-step exploitation approach

1. Identify the target endpoint used by CleanTalk remote calls, typically via WordPress AJAX or a specific plugin API endpoint.
2. Prepare a source IP whose reverse DNS resolves to a hostname containing cleantalk.org.
3. Craft a request including:
   • spbc_remote_call_action=<desired_action>
   • plugin_name=apbct or one of the allowed names
   • other required parameters for the chosen action
4. Send the request from the attacker-controlled IP.
5. If the request is accepted, use it to trigger plugin installation or activation operations.

Expected behavior vs exploited behavior

• Expected behavior after fix:
  • request from non-allowed hostnames is rejected
  • only safe tokenless actions are permitted
  • arbitrary plugin installation/activation is blocked unless a valid token/API key is provided
• Behavior in vulnerable versions:
  • request passes the weak reverse DNS check
  • checkWithoutToken() returns true
  • action is executed without token authentication
  • arbitrary plugin management requests can succeed

How to verify the vulnerability exists

• Send a test request from a controlled IP with a reverse DNS containing cleantalk.org
• Attempt a non-sensitive remote action that still indicates success
• Observe whether the plugin accepts the request without a valid token
• Check plugin installation/activation status or application logs for unauthorized activity

5. Recommendations

Mitigation strategies

• Upgrade CleanTalk plugin to a patched version beyond 6.43.2
• If upgrade is not immediately possible:
  • restrict access to CleanTalk remote endpoints by IP
  • block inbound requests to admin-ajax.php and other plugin endpoints from untrusted sources
  • disable remote call features if not in use

Detection methods

• monitor for requests containing spbc_remote_call_action
• log and alert on unexpected remote calls from non-CleanTalk IP addresses
• inspect plugin activation and installation events for anomalies
• deploy WAF rules for suspicious CleanTalk remote call patterns

Best practices to prevent similar issues

• never rely on reverse DNS or substring matches for authentication
• validate remote source hosts using an exact allowlist
• use cryptographic authentication tokens for privileged operations
• implement action-level allowlists for unauthenticated or fallback flows
• ensure source IP decisions use the actual connection address, not client-controlled headers
• minimize the number of operations permitted without a valid token or key