CVE-2026-1490: CleanTalk Anti-Spam Authentication Bypass via Reverse DNS Spoofing

Overview

CVE: CVE-2026-1490
Plugin: Spam protection, Honeypot, Anti-Spam by CleanTalk
Affected Versions: All versions <= 6.71
Patched Version: 6.72 or later
CVSS: 9.8 (Critical)
Authentication: None required (unauthenticated attacker)
Type: Authentication Bypass via Reverse DNS Spoofing + Arbitrary Plugin Installation

Spam protection, Honeypot, Anti-Spam by CleanTalk is a widely-deployed WordPress anti-spam plugin with approximately 200,000 active installs. In February 2026, a critical authentication bypass was discovered in its internal server-to-server communication handler. The plugin's fallback verification path, named checkWithoutToken, validates incoming requests by resolving the sender's IP address to a hostname via DNS PTR record and checking whether that hostname belongs to cleantalk.org. Because DNS PTR records can be set by anyone who controls an IP address, an attacker can impersonate a trusted CleanTalk server without possessing any cryptographic credential. Once authorization is bypassed, the attacker can install arbitrary plugins from the WordPress repository, creating a path to indirect remote code execution through a chained vulnerable plugin.

What Happened

The root cause is a fundamental design flaw in the checkWithoutToken function's authentication logic.

CleanTalk's plugin maintains an internal API endpoint to receive instructions from CleanTalk's cloud servers — for example, to update spam rules or trigger administrative actions. Two authentication paths protect this endpoint:

Normal flow: The request is authenticated using a cryptographic token that incorporates the site's API key.
checkWithoutToken fallback: Used when the configured API key is absent or invalid. Trust is determined solely by performing a PTR lookup on the sender's IP and checking whether the resolved hostname contains cleantalk.org.

The fallback path is the vulnerability. A PTR record does not prove that the IP address is owned or operated by CleanTalk. PTR records are configured by the ISP or hosting provider that controls the IP range, and many providers allow customers to set arbitrary PTR values. An attacker who controls a VPS or dedicated server can configure its PTR record to resolve to any hostname, including one containing cleantalk.org, without CleanTalk's knowledge or involvement.

Relying on a DNS lookup — an externally manipulable mechanism — rather than a cryptographic signature or HMAC reduced the authentication guarantee to zero. Any attacker who can set a PTR record on an IP they control can forge the identity of a CleanTalk server.

The fallback activates automatically on any site where the API key is missing or invalid. This includes fresh plugin installs where the administrator has not yet configured a key, accounts with lapsed subscriptions, or sites that were migrated without updating the API key. Given 200,000 active installs, a non-trivial fraction of sites will be in this state at any given time.

How the Attack Works

Attack flow:

Identify a vulnerable site: Locate a WordPress site running CleanTalk Anti-Spam. Plugin version information may be visible in the HTML source or via the readme.txt path. The vulnerability is only exploitable when the API key is absent or invalid, which can be inferred by probing the endpoint and observing whether the fallback path is active.
Configure a PTR record on an attacker-controlled IP: Using an ISP control panel, a cloud provider's reverse DNS setting, or a self-hosted authoritative DNS server, configure the PTR record for the attacker's IP to resolve to a hostname that includes cleantalk.org.

; PTR record configured for attacker-controlled IP (e.g., 198.51.100.7)
7.100.51.198.in-addr.arpa.  IN  PTR  trusted.cleantalk.org.

Many VPS and dedicated server providers allow customers to set PTR records directly from their control panel. No elevated access to CleanTalk's infrastructure is required.

Call the CleanTalk internal endpoint from the attacker's IP: Send a request from the attacker's IP to the target site's CleanTalk AJAX endpoint. The plugin performs a PTR lookup, receives trusted.cleantalk.org as the resolved hostname, and passes the authentication check.

POST /wp-admin/admin-ajax.php HTTP/1.1
Host: victim.example.com
Content-Type: application/x-www-form-urlencoded

action=cleantalk_check_without_token&plugin_action=install_plugin&plugin=some-plugin-with-cve

The vulnerable validation logic accepts the request: The checkWithoutToken function performs the following check with no cryptographic verification at any point:

// Vulnerable validation logic (conceptual reproduction)
function checkWithoutToken($ip) {
    $hostname = gethostbyaddr($ip);  // Reverse DNS lookup
    if (strpos($hostname, 'cleantalk.org') !== false) {
        return true;  // Authentication passes — no signature, no token
    }
    return false;
}

Because gethostbyaddr() queries external DNS infrastructure, it returns a result the attacker controls.

Install an arbitrary plugin from the WordPress repository: With authorization bypassed, instruct the plugin to install a WordPress repository plugin of the attacker's choosing. A practical target is any plugin with a known unpatched or historically exploited vulnerability — for example, an old version with a documented RCE or arbitrary file upload flaw.

plugin_action=install_plugin&plugin=contact-form-7&version=5.3.1

Chain to RCE via the installed vulnerable plugin: Use the known vulnerability in the newly installed plugin to deploy a web shell, execute OS commands, or dump the database. The CleanTalk authentication bypass serves as the entry point; the actual code execution happens through the secondary plugin.

No prior access to the target site is required. The only prerequisites are that CleanTalk Anti-Spam is active with an invalid or missing API key, and that the attacker controls an IP whose PTR record they can configure.

Real-World Impact

Approximately 200,000 active installs use this plugin; the subset with an invalid or absent API key is directly exploitable
The attack requires zero prior authentication — an external attacker with no account on the site can execute it
Arbitrary plugin installation is functionally equivalent to code execution on the server, particularly when a vulnerable plugin is the chosen payload
The anti-spam context makes detection counter-intuitive: administrators who installed CleanTalk for security reasons are less likely to scrutinize its own behavior as a threat vector
The attack flow is fully automatable: a scanner can iterate across large numbers of WordPress sites, probe for the vulnerable fallback condition, and install a payload plugin without any manual intervention
Installed backdoor plugins persist until actively removed, providing durable access even if the CleanTalk plugin is subsequently updated or deleted

Fix and Lessons

Fix: Patched in version 6.72. The PTR-based authentication in checkWithoutToken was removed and replaced with proper cryptographic token validation. The fallback path no longer accepts requests based on DNS resolution alone. All sites running CleanTalk Anti-Spam should update to 6.72 or later immediately and verify that a valid API key is configured.

Lessons:

DNS is not an authentication mechanism: PTR records do not prove IP ownership or server identity. DNS is external infrastructure that any attacker with a VPS can influence. Server-to-server authentication must be built on cryptographic primitives — HMAC, RSA signatures, or shared secrets delivered out-of-band — not on DNS lookups.
Fallback authentication paths must not weaken security guarantees: A design where "if the API key is invalid, use a weaker check" creates an authentication path that attackers can deliberately trigger. The correct behavior when authentication cannot be completed is to reject the request, not to substitute a less rigorous check.
Never trust gethostbyaddr() for authorization decisions: PHP's gethostbyaddr() and equivalent reverse DNS functions query external DNS servers whose results the caller cannot control. The returned hostname is fully attacker-influenced in any environment where the sender controls their IP's PTR record. Do not use reverse DNS results as a basis for granting privileges.
Plugin installation APIs demand the strictest access controls: Installing a plugin on a WordPress site is equivalent to deploying arbitrary PHP code. Any endpoint that can trigger plugin installation must be protected by strong, cryptographically sound authentication. Exposing this capability through a fallback path that can be triggered by an unauthenticated remote party is a critical design error.
Secure-by-default means the incomplete configuration state must be safe: A plugin that becomes more vulnerable when the API key is not configured fails the secure-by-default principle. The correct design is to disable or heavily restrict the affected functionality when no valid API key exists, and to prominently alert the administrator that setup is incomplete.

Detection with Nyambush

Nyambush automatically detects installed WordPress plugin versions and cross-references them against its vulnerability database. When CleanTalk Anti-Spam is detected at version 6.71 or earlier, Nyambush raises a Critical severity finding with CVSS 9.8 and flags it for immediate remediation.

Nyambush also analyzes plugin configuration signals: sites where the CleanTalk API key appears to be absent or misconfigured receive an additional risk flag indicating that the checkWithoutToken fallback may be active, elevating the practical exploitability of the finding.

Because this vulnerability does not require any prior access to the site, it is particularly well-suited to mass exploitation by automated scanners. In continuous monitoring mode, the Critical alert persists until Nyambush confirms the plugin has been updated to 6.72 or later, ensuring the remediation gap is visible to the site owner at all times.