Support » Plugin: Contact Form 7 » reCaptcha v3 Circumvention

  • Hello,
    We setup Google reCaptcha v3 on Contact Form 7 (v 5.1). It has not stopped all the spam. We are logging form submissions and when we test the form, we get a POST variable(g-recaptcha-response) like the one at the end of this message. However, when we review the spam submissions, we notice that there is no g-recaptcha-response variable posted yet it still lets the form submission go through. Does anyone know how this could be possible or if there is some setting I am missing?



    The page I need help with: [log in to see the link]

Viewing 15 replies - 1 through 15 (of 16 total)
  • It looks like there is a logic issue where failing to provide the g-recaptcha-response allows the submission through.

    This is a _very_ unofficial change on my part, but it seems to work for me.

    Edit line 114 of modules/recaptcha.php (version 5.1)

    It reads:

    return $spam;

    Change it to:

    return true;

    This will change it so that any submission that does not attempt the Recaptcha V3 validation will be rejected.

    @peterupfold Good workaround, though I am loathe to alter the base code of any plugins. I hope dev patches this shortly as we’re experiencing a great deal of additional spam since upgrading to v3 keys across all sites this morning.

    Same here. Though I must have made a mistake in setting up recaptcha v3, but maybe it’s not me. I’ve had my site for a couple of years and had no spam till today.

    I don’t mind altering source code since a future fix should overwrite it. I’m going to give it a shot too.

    @peterupfold, have you gotten any more spam since you implemented the:

    return true;

    I was using Recaptcha V2 until yesterday afternoon, never any spam, but I have had 3 spams in the last 12 hours since updated to V3. I will implement the workaround, and hopefully that stops the spams until there is an update.

    Thank you for the info @peterupfold.

    Same, I have just implemented the fix, version 5.1 but on line 112:

    111 	if ( ! $token ) {
    112		return true;
    113 	}


    • This reply was modified 11 months, 1 week ago by jbkt.

    The solution suggested by @peterupfold is extremely poor practice and should be avoided.

    He says:

    This is a _very_ unofficial change on my part, but it seems to work for me.

    I have reported this to Forum Moderation for examination.

    @buzztone can you elaborate? Is it a poor practice because he’s editing plugin code or was the specific change a poor practice?

    The specific change is poor practice.

    Moderator Ipstenu (Mika Epstein)


    🏳️‍🌈 Plugin Review Team Rep

    I’ve removed the modlook request. While it’s poor practice, there’s nothing that needs a moderator review.

    I STRONGLY recommend no one ever edit code directly, though. The next update will blast it away.

    Hopefully it’s still OK to explain my reasons for saying the solution suggested is extremely poor practice. I’m sorry that my comments are still not addressing the original question.

    Editing of code & loss of that code at the next update was not my main concern, though I’m of course aware of that.

    Rather the code change itself:

    1. Was not based on a clear understanding of all CF7 code
    2. Just disables ReCAPCTHA without really dealing with the original question
    3. Does so without deeper consideration of further consequences in CF7 functionality

    @peterupfold sort of says that as well:

    This is a _very_ unofficial change on my part, but it seems to work for me.

    The change suggested is a temporary hack, not a fix. The OP attempted to make that clear at the very start. Mr. Murray’s objections are valid even if slightly over the top in tone.

    The point of open source projects is to enable individuals to deal with situations just like this. That the next update will overwrite it is inconsequential except for those who apply the hack.

    Hopefully, the next update will resolve the problem. It must. My site clients will not tolerate this error in the current release for long. I have already been asked to replace C7.

    So, all the posturing aside, I ask the WP/C7/recaptcha maintainers, what is the ETA for a proper fix?

    Oh gawd. Some of us are dealing with a business crisis here. I manage high end clients who get a lot of business through contact forms. I could care less about your developer nerd etiquette right now. We need a fix, ASAP, even if it’s sloppy.

    • This reply was modified 11 months, 1 week ago by jazzartdesign.

    I ask the WP/C7/recaptcha maintainers, what is the ETA for a proper fix?

    @takayukister is the only person that can do that.

    The only alternative I can suggest is to watch the SVN version of CF7 for upcoming changes.

    @peterupfold has given a detailed explanation of his hack.

    Takayuki Miyoshi, the plugin author, has given his thoughts on the hack.

    The hack appears to deal with a bug in the CF7 5.1 code, but Takayuki is concerned with the hack creating false negatives i.e. rejecting form submissions that are not spam.

    The hack does not just disable ReCAPCTHA, as I thought, and does deal with the original question.

Viewing 15 replies - 1 through 15 (of 16 total)
  • The topic ‘reCaptcha v3 Circumvention’ is closed to new replies.