CVE-2023-33996: A Nonce Is Not an Authorization Check
Anti-Spam by CleanTalk 6.10 and earlier registers its spam-checking and settings-template handlers on wp_ajax_* hooks, which WordPress dispatches to every logged-in user, including subscribers. Each handler then ran only check_ajax_referer('ct_secret_nonce') — and that nonce is not a secret. The plugin localizes wp_create_nonce('ct_secret_nonce') into every wp-admin page as ctAdminCommon._ajax_nonce with no capability gating, so any subscriber who loads their profile page holds a valid token. Scripted POSTs to /wp-admin/admin-ajax.php then drive sinks such as UsersChecker::ctAjaxDeleteAllUsers looping wp_delete_user over flagged accounts, CommentsChecker ctAjaxTrashAll and ctAjaxSpamAll, wp_set_comment_status on arbitrary comments, and settings-template import or reset that overwrites stored plugin options. Net impact: unauthorized data modification with limited information disclosure, CVSS 6.3.
BitFire FREE Bot Protection Stops the Exploit Delivery
The whole attack is automated cross-account invocation: a script, not a person, POSTing restricted admin-ajax actions with a scraped nonce. That is precisely the traffic BitFire FREE Bot Protection is built to stop. Unknown or restricted clients cannot call sensitive APIs or probe exploit paths, and a client presenting as a browser must pass lightweight JavaScript verification that scripts and fake browsers fail. Bot Protection therefore kills this exploit at delivery — before WordPress loads a single vulnerable handler, there is no nonce use and no sink. Stated limitation: an explicitly allowed bot or a fully verified real browser is not categorically stopped, which is exactly why BitFire layers runtime enforcement underneath.
BitFire PRO RASP Blocks the Privileged Database Changes
If a request survives delivery, BitFire PRO RASP enforces authorization at the protected operation. Here the modifying code is the plugin itself — not WordPress core and not an approved membership or commerce plugin — so the database guard applies: when a non-admin subscriber request triggers the ajax_delete_all_users wp_delete_user loop, user insertion, or bulk wp_trash_comment and wp_spam_comment calls, BitFire PRO RASP blocks the account-related database write. The flagged users are not deleted and the comments are not trashed. RASP neither sanitizes the request nor needs to recognize CVE-2023-33996; it simply refuses the unauthorized privileged outcome, which is exactly where this vulnerability's impact lives.
Update to 6.11 and Enforce the Fix
CleanTalk 6.11 closes the flaw by routing every one of the seventeen handlers through a new helper, apbct__check_admin_ajax_request(), which keeps the nonce check and adds current_user_can('manage_options'), dying with a 403 otherwise. Update to 6.11 or later now. Note that the nonce-disclosure code itself remains in place — nonce secrecy was never the defense; the capability check is. While you patch, BitFire holds the line: delivery blocked at the request layer, privileged writes blocked at runtime.
If Your Site Was Affected, Investigate for Persistence
Patching closes the known path; it does not undo a compromise that already succeeded. An abuser of this flaw could rewrite plugin settings and destroy or reshape user and comment data, so treat any site that ran 6.10 or earlier as suspect. Run BitFire Threat Hunter to sweep for backdoor administrator accounts, hidden database triggers, long-running PHP processes, and droppers that can restore malware or reinfect the site. Remove every persistence mechanism it finds and rotate your WordPress and database credentials. The absence of an obvious malicious file is not proof of a clean site.
Protect the Site You Patch
CVE-2023-33996 turns 200,000 CleanTalk installations into soft targets through one missing capability check. BitFire's answer is layered and decisive: BitFire FREE Bot Protection stops the scripted admin-ajax delivery before WordPress runs, and BitFire PRO RASP blocks the unauthorized user and comment database changes at the protected operation. Update to CleanTalk 6.11 or later, put BitFire in front of your site, and run Threat Hunter if the vulnerable version was ever live. Install BitFire today and make this exploit class irrelevant to your WordPress stack.
