Spam protection & Antispam add-on. CAPTCHA free Anti-Spam by CleanTalk 3.1.0

[CleanTalk Team]

This morning I woke up to find my site offline.

I logged in and found I have run out of drive space.

I did a check and there was over 1 TB error_log file in my xenforo directory.

I took a look at it and it was filled with the following error.

CleanTalk Firewall is not loaded: MySQL statement prepare error [1146]: Table 'satelliteguys_xenforo.xf_cleantalk_sfw' doesn't exist

I uninstalled and reinstalled the plugin and am still getting it. How do I fix this?

Thanks!

Hello SatGuyScott,
Could you please create a ticket in our private ticket system so we can gather some more information from you concerning this issue?
While we are investigating, you can disable the SpamFireWall option in the Anti-Spam add-on settings.
Thank you in advance!

 

[ES Dev Team]

Sorry, dumb question.

Does this also filter PMs and contact forum messages?
We have a lot of nonsense coming through both lately.

 

[CleanTalk Team]

Sorry, dumb question.

Does this also filter PMs and contact forum messages?
We have a lot of nonsense coming through both lately.

Hello.

In the plugin settings, there is an option called "Check private messages in conversations." It allows you to check the first 3 messages from a user for spam.
Submissions from the "Contact Us" form are also checked by our plugin.

Please check your anti-spam log. If it contains the spam messages you’re referring to and they were missed by our service, please mark these records according to this guide: https://cleantalk.org/help/feedback-spam. Write to us after. We will analyze these requests.

 

[ES Dev Team]

Thank you!

 

[BobHarbison]

Getting the following error:
Disabling the add-on makes the error stop.

Cannot modify container while locked

• LogicException: Cannot modify container while locked
• src/XF/Container.php:325
• Generated by: Unknown account
• Sep 14, 2026 at 2:19 PM

Stack trace​

#0 src/XF/Container.php(111): XF\Container->assertNotLocked()
#1 src/XF/Container.php(68): XF\Container->set('options', Object(XF\Options))
#2 src/XF/App.php(2923): XF\Container->offsetSet('options', Object(XF\Options))
#3 src/XF/Repository/OptionRepository.php(176): XF\App->__set('options', Object(XF\Options))
#4 src/XF/Entity/Option.php(729): XF\Repository\OptionRepository->rebuildOptionCache()
#5 src/XF.php(697): XF\Entity\Option->XF\Entity\{closure}()
#6 [internal function]: XF::triggerRunOnce()
#7 {main}

Request state​

array(4) {
["url"] => string(41) "/forum/index.php?whats-new/media/5930926/"
["referrer"] => bool(false)
["_GET"] => array(1) {
["whats-new/media/5930926/"] => string(0) ""
}
["_POST"] => array(0) {
}
}

 

[CleanTalk Team]

Getting the following error:
Disabling the add-on makes the error stop.

Cannot modify container while locked

• LogicException: Cannot modify container while locked
• src/XF/Container.php:325
• Generated by: Unknown account
• Sep 14, 2026 at 2:19 PM

Stack trace​

#0 src/XF/Container.php(111): XF\Container->assertNotLocked()
#1 src/XF/Container.php(68): XF\Container->set('options', Object(XF\Options))
#2 src/XF/App.php(2923): XF\Container->offsetSet('options', Object(XF\Options))
#3 src/XF/Repository/OptionRepository.php(176): XF\App->__set('options', Object(XF\Options))
#4 src/XF/Entity/Option.php(729): XF\Repository\OptionRepository->rebuildOptionCache()
#5 src/XF.php(697): XF\Entity\Option->XF\Entity\{closure}()
#6 [internal function]: XF::triggerRunOnce()
#7 {main}

Request state​

array(4) {
["url"] => string(41) "/forum/index.php?whats-new/media/5930926/"
["referrer"] => bool(false)
["_GET"] => array(1) {
["whats-new/media/5930926/"] => string(0) ""
}
["_POST"] => array(0) {
}
}

Hello,

Thank you for your feedback!

Please allow us 2–3 business days to investigate this matter. We will follow up with you as soon as we have an update.

Kind regards,

 

[BobHarbison]

Hello,

Thank you for your feedback!

Please allow us 2–3 business days to investigate this matter. We will follow up with you as soon as we have an update.

Kind regards,

Upon further investigation, my server is currently over-run with spam bots. That may be why it's giving problems.

 

[CleanTalk Team]

Upon further investigation, my server is currently over-run with spam bots. That may be why it's giving problems.

Thank you for the additional details.

 

[CleanTalk Team]

Getting the following error:
Disabling the add-on makes the error stop.

Cannot modify container while locked

• LogicException: Cannot modify container while locked
• src/XF/Container.php:325
• Generated by: Unknown account
• Sep 14, 2026 at 2:19 PM

Stack trace​

#0 src/XF/Container.php(111): XF\Container->assertNotLocked()
#1 src/XF/Container.php(68): XF\Container->set('options', Object(XF\Options))
#2 src/XF/App.php(2923): XF\Container->offsetSet('options', Object(XF\Options))
#3 src/XF/Repository/OptionRepository.php(176): XF\App->__set('options', Object(XF\Options))
#4 src/XF/Entity/Option.php(729): XF\Repository\OptionRepository->rebuildOptionCache()
#5 src/XF.php(697): XF\Entity\Option->XF\Entity\{closure}()
#6 [internal function]: XF::triggerRunOnce()
#7 {main}

Request state​

array(4) {
["url"] => string(41) "/forum/index.php?whats-new/media/5930926/"
["referrer"] => bool(false)
["_GET"] => array(1) {
["whats-new/media/5930926/"] => string(0) ""
}
["_POST"] => array(0) {
}
}

Hello,

We've fixed the issue. Please install the plugin from the attached archive.

Does this fix the errors?

 

[CleanTalk Team]

Hello,

1. We are planning to add notifications about the expired access key in the next release. We'll let you know as soon as it's released.
2. You can find the statistics here: Logs → Statistics. Also, you can create a separate CleanTalk account for your moderators and grant access to your website for them via the delegation option: https://cleantalk.org/help/delegation
   Also, you can find the anti-spam logs here: Logs → Spam trigger log. It's described in our guide here: https://cleantalk.org/help/install-xenforo2
3. At this time, we have no plans for such a feature. We'll let you know if something like that is added to the plugin.

Thank you.

@Alpha1, we have made some fixes. You can try the attached version.

 

[CleanTalk Team]

CleanTalk Team updated Anti-Spam & CAPTCHA free spam protection by CleanTalk with a new update entry:

Compatible to latest XenForo

Hello everyone,

A couple of updates:

1. We tested the current stable version 3.1.0 with the latest XenForo release 2.3.13, and confirmed that they are fully compatible.
2. We’re planning to release a new add-on version soon. It will include updated front-end code designed to improve anti-spam protection against modern spam bots.

Please check back here for updates.

View attachment 346909

Read the rest of this update entry...

 

[Alpha1]

When CleanTalk flags a registration, XenForo places the user in the approval queue. The moderator sees “CleanTalk matched” and our own block message, but not what matched: the email address or the IP address. They also cannot see what kind of IP it is or whether it is still listed. Moderators have no access to the CleanTalk dashboard or the admin logs, so they have no way to find this out.

Why this matters
A CleanTalk hit can mean very different things:

• The email address was used by spammers. This is a strong reason to reject.
• The IP address is shared by many people (Tor exit node, VPN, mobile carrier) and was used for spam once by someone else. It may no longer be listed. This says nothing about the person who registered.

Because the moderator cannot see which case it is, they have two choices:

1. Reject every registration with a CleanTalk hit. Then genuine users are rejected because of an IP address they share with many others. On our forum many members use a VPN or Tor for privacy, so this affects a lot of genuine users.
2. Approve registrations with a CleanTalk hit when nothing else looks wrong. Then the CleanTalk check has no effect, and spammers whose email address is listed are approved too.

Example from our queue this week: a registration was held because of a CleanTalk hit. When we checked it manually, the hit came from a Tor exit node, and neither the IP address nor the email address is listed now.


What we ask from CleanTalk (API, check_newuser response)
At the moment the response gives allow, codes and blacklisted, but not which field matched or what kind of IP it is. Please add, per checked field:

1. email_listed and ip_listed (yes/no), so it is clear which one caused the hit;
2. ip_type: Tor exit node, VPN/proxy, hosting/datacenter, mobile carrier, or residential;
3. for each listed field: the number of reports, the date of the last report, and whether it is listed now or only was in the past.

What we ask from the XenForo add-on

1. Write these fields into the spam log of the registration, the same way XenForo’s own StopForumSpam check does it (logDetail() with a phrase and data). XenForo already shows these log lines as a warning on the user in the approval queue, to everyone who can approve or reject users. No new page or permission is needed. For example: “CleanTalk: IP listed (Tor exit node, 1 report, last 16 Oct 2026, not listed now). Email not listed.”
2. An admin setting to choose the action per reason, using XenForo’s normal spam decisions (allow, moderate, reject). For example: reject on an email match, send to the approval queue on an IP match, allow on an IP match that is no longer listed.
3. Optional: a “Check again” button on the queued user, with the same permission as approve/reject, that shows whether the email or IP is still listed now.

 

[CleanTalk Team]

When CleanTalk flags a registration, XenForo places the user in the approval queue. The moderator sees “CleanTalk matched” and our own block message, but not what matched: the email address or the IP address. They also cannot see what kind of IP it is or whether it is still listed. Moderators have no access to the CleanTalk dashboard or the admin logs, so they have no way to find this out.

Why this matters
A CleanTalk hit can mean very different things:

• The email address was used by spammers. This is a strong reason to reject.
• The IP address is shared by many people (Tor exit node, VPN, mobile carrier) and was used for spam once by someone else. It may no longer be listed. This says nothing about the person who registered.

Because the moderator cannot see which case it is, they have two choices:

1. Reject every registration with a CleanTalk hit. Then genuine users are rejected because of an IP address they share with many others. On our forum many members use a VPN or Tor for privacy, so this affects a lot of genuine users.
2. Approve registrations with a CleanTalk hit when nothing else looks wrong. Then the CleanTalk check has no effect, and spammers whose email address is listed are approved too.

Example from our queue this week: a registration was held because of a CleanTalk hit. When we checked it manually, the hit came from a Tor exit node, and neither the IP address nor the email address is listed now.


What we ask from CleanTalk (API, check_newuser response)
At the moment the response gives allow, codes and blacklisted, but not which field matched or what kind of IP it is. Please add, per checked field:

1. email_listed and ip_listed (yes/no), so it is clear which one caused the hit;
2. ip_type: Tor exit node, VPN/proxy, hosting/datacenter, mobile carrier, or residential;
3. for each listed field: the number of reports, the date of the last report, and whether it is listed now or only was in the past.

What we ask from the XenForo add-on

1. Write these fields into the spam log of the registration, the same way XenForo’s own StopForumSpam check does it (logDetail() with a phrase and data). XenForo already shows these log lines as a warning on the user in the approval queue, to everyone who can approve or reject users. No new page or permission is needed. For example: “CleanTalk: IP listed (Tor exit node, 1 report, last 16 Oct 2026, not listed now). Email not listed.”
2. An admin setting to choose the action per reason, using XenForo’s normal spam decisions (allow, moderate, reject). For example: reject on an email match, send to the approval queue on an IP match, allow on an IP match that is no longer listed.
3. Optional: a “Check again” button on the queued user, with the same permission as approve/reject, that shows whether the email or IP is still listed now.

Thank you for your suggestions. We will discuss them with our team and get back to you. It may take up to 3 business days.