Erik

Hi @jackrus60,

I wanted to drop another quick update here! Your initial report actually sent me down a bit of a rabbit hole analyzing my server logs, and I ended up discovering some fascinating details that perfectly explain the exact type of spam you were dealing with.

After analyzing the attacks, I managed to isolate the two distinct types of bots currently targeting Contact Form 7:

1. The “Dumb” Scrapers (The Most Common) The first type exploits the fact that CF7 REST API endpoints are highly predictable out-of-the-box. These bots simply scrape the form ID and send a direct POST payload to the endpoint. They don’t even visit the visual website, load the HTML, or execute JavaScript. They are very common but relatively easy to block.

2. The Advanced Distributed Bots (What you experienced) The second type of bot—which is responsible for the single-word, high-entropy spam you reported—is much more advanced. They are using headless browsers (like Selenium or Puppeteer) to mimic real user behavior.

Looking at the logs, I saw a “distributed” attack pattern:

• The Scout: A single IP visits the page, fully renders the content, and executes the JavaScript. It actually requests the CF7 validation schema to map out exactly which fields exist and are required. To avoid getting banned, the Scout never submits the form.
• The Workers: The Scout then passes this data blueprint to “Worker” IPs. These workers rotate their IP addresses and blast the form with submissions using the random strings you noticed.

Because these advanced bots execute JavaScript and read the form schema perfectly, traditional frontend protections (like simple hidden fields or changing the endpoint via JS) often fail. This is exactly why the server-side High Entropy / Anti-Gibberish filter I added in the recent update is so critical—it catches them based on the unnatural math of their payload (like 6 consecutive consonants), regardless of how perfectly they faked the browser submission.

Anyway, I thought you might find this technical background interesting since your detailed report was the catalyst for figuring this out! Thanks again for helping me improve the plugin.

Hi Heiko,

Thank you so much for the kind words! I’m really glad to hear that you like the honeypot fix, I think it turned out to be a very robust approach.

Regarding your suggestion for the hook: you actually read my mind! Providing a developer-friendly hook is definitely the smartest and fastest way to handle this, rather than building a heavy UI tab just for this edge case.

However, instead of creating a specific cf7a_enable_b8 hook, I was thinking about doing something even more flexible. If you look at CF7_AntiSpam_Filters.php (around lines 54-78, where the active filters are loaded), my idea is to introduce a global filter right there that passes the entire array of active filters and the form ID.

This way, developers could selectively unset() not just the B8 filter, but any filter (like GeoIP, Language, etc.) on a per-form basis. It would look something like this:

PHP

add_filter( 'cf7a_active_filters', function( $filters, $form_id ) {
    // Disable B8 filter for form ID 123
    if ( 123 == $form_id && isset( $filters['b8'] ) ) {
        unset( $filters['b8'] );
    }
    return $filters;
}, 10, 2 );

I will definitely work on implementing this in one of the upcoming updates, as it adds a ton of flexibility for advanced users and agencies like yours.

Thank you again for all your testing and your brilliant suggestions! It really means a lot to me, and it’s feedback like yours that helps the plugin grow!

Best regards, Erik

Hi Heiko,

I just wanted to drop a quick message to let you know that the new update (version 0.7.6) is finally live!

Regarding the Honeypot issue, I think I’ve managed to implement a really nice solution. Instead of just removing the default names, the plugin now dynamically compares its internal honeypot list with the actual fields present in your specific form during creation. It only injects the honeypots that do not match your real fields. It does the exact same dynamic comparison during the submission validation and the Flamingo cleanup phases. This completely eliminates any false positives, while creating a seamless structure that is practically impossible for a bot to distinguish from legitimate fields!

As for the custom “per form” settings (like disabling the B8 filter on specific forms), I am currently researching the best technical approach to build that dedicated tab seamlessly into the CF7 editor. In the meantime, I have published a comprehensive list of the plugin’s Hooks, which you might find useful for some custom manual implementations: CF7 AntiSpam Wiki – GitHub

Since the honeypot and false-positive issues should be fully resolved with this release, I am going to go ahead and mark this thread as resolved. Of course, if you update and still experience any weird behavior, please feel free to reopen this thread or start a new one!

Thank you so much again for your incredible feedback, your debugging efforts, and your support.

Best regards, Erik

Hi Heiko,

I completely understand the issue about “per form” antispam configuration, and you make a great point.

To do exactly what you are asking in the best way possible, the ideal solution would probably be to create a dedicated “AntiSpam” tab directly inside the individual Contact Form 7 editor. Not only would this allow you to disable the B8 filter on a per-form basis, but it would also solve the current hassle of having to manually specify which fields the B8 filter should evaluate.

I will definitely think about how to implement this! While it won’t make it into the very next release, I have officially added it to my roadmap for future improvements.

Thanks again for the great feedback. Suggestions and real-world use cases from users like you are always incredibly useful for making the plugin better.

Hallo @khoehne,

Thank you so much for taking the time to run these tests and for sharing the detailed logs! They are incredibly helpful and point exactly to the root cause of the issue.

As you can clearly see in the logs (honeypot: [phone] and honeypot: [zip, phone]), the plugin is blocking the submissions because it thinks those fields are honeypots. This is actually due to a bug in the plugin’s code (which another user also just reported) where standard field names like “phone”, “zip”, and “email” are forcefully checked as honeypots by default, conflicting with your actual form fields.

Because the system registered multiple “spam” attempts from your IP due to these false positives, it eventually put your IP on the blocklist—which explains why it stopped working on your phone as well.

I am already working on a fix to completely remove these forced default names, and it will be included in the very next release.

Your current workaround—disabling the Honeypot and Browser Language checks—is absolutely perfect for now. Alternatively, if you want to re-enable the honeypot, you could simply rename your form fields (e.g., from phone to your-phone and zip to your-zip).

Thank you again for your patience, your thorough debugging, and for helping me improve the plugin. I really appreciate your support!

Best regards, Erik

Hi Heiko,

First of all, thank you so much for using the plugin on so many of your projects! It truly makes me incredibly happy and proud to have such an awesome community supporting my work.

Regarding the false positives with the “email” and “zip” fields: to help me properly investigate and reproduce the issue, could you let me know exactly which multi-step plugin you are using? Sometimes, multi-step plugins manipulate the form’s hidden data or the DOM as users transition between steps. I want to run some tests to verify if that’s creating a mess with how the honeypot validation is processed.

As for your second question about storing different configurations for different forms: currently, the settings apply globally to the whole website. However, it’s a great feature request and something I can definitely consider for future updates!

Let me know about the multi-step plugin, and we’ll figure this out.

Best regards, Erik

Hallo,

I’m marking this topic as resolved as I haven’t heard back from you in a while.

If you are still experiencing the issue or need further assistance, please feel free to open a new support thread.

When you do, I kindly ask you to follow the instructions at this link: https://wordpress.org/support/topic/how-to-report-bugs-and-troubleshoot-issues/.

This will provide me with the necessary context and debug information to help you much more effectively.

Thank you!

Hallo @khoehne! Vielen Dank, dass du dich gemeldet und uns diese Konsolenwarnung mitgeteilt hast.

Ich habe mir den Code angesehen, und du hast Recht. Das Problem wird durch den Canvas-Fingerprinting-Test ausgelöst, der in Desktop-Browsern wie Chrome, Edge und Firefox strenge Sandbox-Sicherheitswarnungen verursacht.

Ich habe den Code meinerseits bereits korrigiert. Da dies definitiv auch andere Nutzer betreffen kann, werde ich sehr bald ein neues Release mit der Korrektur veröffentlichen!

Ehrlich gesagt glaube ich nicht, dass diese spezielle Iframe-Warnung der eigentliche Grund dafür ist, dass deine E-Mails nicht versendet werden. Als schnelle Übergangslösung kannst du jedoch versuchen, die Bot-Fingerprinting-Funktion in den Plugin-Einstellungen zu deaktivieren. Dadurch wird der problematische Canvas-Test komplett umgangen und deine Desktop-Formulare sollten wieder funktionieren.

Um mir bei der weiteren Untersuchung des Problems mit der E-Mail-Zustellung zu helfen, könntest du mir bitte eine Liste der anderen Plugins schicken, die du derzeit installiert hast? Ich würde gerne prüfen, ob es irgendwo im Hintergrund zu einem Konflikt kommen könnte.

Nochmals vielen Dank für deine Hilfe und Geduld!

PS: Dies ist ein englischsprachiges Forum, und Englisch wäre die bevorzugte Sprache, danke!