CVE-2026-8705 in Total Plugin
Summary
by MITRE • 06/24/2026
The ClearSale Total plugin for WordPress is vulnerable to SQL Injection via the `pagseguro[metodo]` POST parameter of the `clearsale_total_push` AJAX action in all versions up to, and including, 3.4.2. The handler is registered for unauthenticated users (`wp_ajax_nopriv_clearsale_total_push`), and although a `wp_verify_nonce()` check exists, the failing branch's `die()` is commented out so execution continues regardless of nonce validity. On PHP < 8.0 the attacker-supplied `$metodo` value bypasses the `switch ($metodo) { case 4: ... }` guard via loose type juggling (the string `"4 AND SLEEP(5)"` compares equal to integer `4`), reaching an unquoted `UPDATE wp_cs_total_dadosextras SET metodo=$metodo, ...` query. This makes it possible for unauthenticated attackers to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database. Exploitation requires the target server to be running PHP < 8.0.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 06/24/2026
The ClearSale Total plugin for WordPress presents a critical SQL injection vulnerability that affects all versions up to and including 3.4.2, creating a significant risk for WordPress installations. This vulnerability resides within the `clearsale_total_push` AJAX action which is registered to accept unauthenticated requests through the `wp_ajax_nopriv_clearsale_total_push` hook, fundamentally undermining the security model of the plugin by allowing any remote attacker to submit malicious payloads without authentication. The vulnerability manifests specifically through the `pagseguro[metodo]` POST parameter that flows into the SQL query execution path, creating a dangerous attack surface where database integrity is compromised.
The technical flaw stems from inadequate input validation and flawed security controls within the plugin's AJAX handler implementation. Although the code includes a `wp_verify_nonce()` check designed to prevent unauthorized access, the developers have commented out the `die()` function call that should terminate execution when nonce verification fails, allowing malicious requests to proceed regardless of authentication status. This design error transforms what should be a robust security control into a mere illusion of protection, enabling attackers to bypass authentication requirements entirely.
The vulnerability exploits PHP's loose type comparison behavior present in versions prior to PHP 8.0, where string values can be implicitly converted to integers during comparisons. When an attacker supplies a value like `"4 AND SLEEP(5)"` as the `metodo` parameter, PHP's type juggling causes this string to compare equal to integer `4`, successfully passing the switch statement guard and allowing execution to continue into the SQL query construction phase. This type coercion bypasses the intended control flow and enables attackers to inject arbitrary SQL fragments into the database query.
The operational impact of this vulnerability is severe, as it allows unauthenticated attackers to perform data extraction operations through time-based blind SQL injection techniques. The vulnerable UPDATE query `wp_cs_total_dadosextras SET metodo=$metodo, ...` directly incorporates attacker-controlled input without proper sanitization or parameterization, enabling attackers to append additional SQL commands that can retrieve sensitive information from the database. This includes but is not limited to user credentials, personal data, and potentially system configuration details that could be leveraged for further attacks.
The vulnerability aligns with CWE-89 which specifically addresses SQL injection flaws in software applications, representing a classic example of how improper input handling creates dangerous attack vectors. From an ATT&CK framework perspective, this vulnerability maps to T1071.004 (Application Layer Protocol: DNS) and T1566 (Phishing) as attackers could use the compromised data for credential theft or further social engineering campaigns. The fact that exploitation requires PHP < 8.0 creates a specific environment condition that security teams must monitor, as PHP 8.0 introduced stricter type checking that would prevent this particular attack vector.
Mitigation strategies should prioritize immediate plugin updates to versions beyond 3.4.2 where the vulnerability has been addressed through proper input validation and SQL query parameterization. Organizations should also implement network-level protections such as web application firewalls to detect and block suspicious SQL injection patterns, while conducting thorough security audits of all WordPress plugins to identify similar vulnerabilities. Additionally, administrators must ensure their hosting environments are running PHP 8.0 or later versions to eliminate the type coercion attack vector, and perform regular database backups to protect against potential data exfiltration attempts that could occur through this vulnerability.