CAPTCHA session reuse attack detected

I ran into the same exact issue after the 7.37 update on a client site. The client is using CRM core and CRM core donation with commerce. They received this error on their donation form after the update. The trigger was any change of payment method on commerce checkout form (embedded) - See file image (captcha session-reuse-error.png). below. There were no issues before the 7.37 update. That was the only change (core 7.36 to core 7.37). The above fix solved the problem and I did not have to remove the captcha from those pages. Please add this patch to the captcha module (on my version it is added to line 637).

Versions (relevant modules):
core - 7.37 *** this was the only change (from 7.36 to 7.37)
drupal commerce - 7.x-1.11
crm core - 7.x-0.980
crm core donation - 7.x-1.14
crm core profile 7.x-1.0-beta10
crm core profile commerce items - 7.x-0.4
entity api - 7.x-1.6
entity reference - 7.x-1.1

It works for me.
I'm using it with recaptcha and this patch : https://www.drupal.org/node/2449209
Thanks.

using hs + CAPTCHA , same problem. 1# patche works.

Patch #1 worked for me too on Drupal 7.39 using Captcha 7.x-1.3.
Can we get that commited to captcha 7.x-1.x-dev?

Fixed #1 to have another try with the testbot.

Forget #6. It includes the original patch in it too.
Fixed in #7.

I will need a test to check this scenario before committing, this is the sort of issue that we need to be safe before committing, could you update the patch to add the test scenario as well?

Cheers,
Fabiano

#7 applied cleanly and works for my situation which includes an ajax file upload component.

drupal-7.39, webform-7.x-4.11, captcha-7.x-1.3, hidden_captcha-7.x-1.0

Doesn't work for me.
Works but make me submit even with an erroneous captcha...
does this happen only to me ?

Have you tried the patch in #1395184: Forms with AJAX trigger "CAPTCHA session reuse attack detected." error?

I can confirm that the fix from #1395184: Forms with AJAX trigger "CAPTCHA session reuse attack detected." error does fix this error for me, and it's already been applied to the dev version of the module. This issue may be a duplicate.

It is working for me

if($form_state['submitted']){
db_update('captcha_sessions')
->fields(array('token' => NULL))
->condition('csid', $posted_captcha_sid)
->execute();
}

Thanks

I've just tried the -dev version and the error is still showing, so I think this issue and patch is still relevant.

The patch in #7 applies to the -dev version, so could do with going via the testbot again.

Otherwise, I'm happy to RTBC, as it works as expected for me.

Thanks.

Sorry, I'm a beginner level user and my interpretations may be wrong.

Recently (1-2 weeks ago), I've noticed that spam-bots have started to reuse old sessions somehow(?). According to logs, they gave answer (incorrect but close to) while the program reported about inconsistent correct solution (probably value of incorrect type), like this:

user_register_form post blocked by CAPTCHA module: challenge Image (by module image_captcha), user answered "6zmsety", but the solution was "07737bf0f10775e92eefc29ac22084dd".

In many cases, record of this type is followed by immediate successful registration of spam-bot.

This small patch (form state checking) have solved this problem and dramatically decreased log records about registration attempts from spam-bots.

Thank you!

Successfully applied the patch in #7 to the 7.x-1.3 version of the module.

We're using it on a webform with multiple pages and a multiple-file upload field. It looks good so far.

Does this also solve the problem? I improved the logic slightly around the variable check.

This problem also exists in D8. In our case it happens when trying to upload an image to a form(using the entity browser).

Attached patch is against the latest d8-dev. I have no idea if this solution is any good.

Guys . . . this thread has a versioning problem. The OP mentioned the stable release (1.3) but the issue metadata says dev.

I can confirm that upgrading to the latest dev version solves the problem.

We haven't had a stable release of this module since 2015, so hopefully we'll get one soon. In the mean time, I recommend marking this issue as fixed.

Attaching new patch that will work with version 1.4

Patch #23 doesn't include part of the if() statement from #19, so I suggest just sticking with #19.

captcha_session_reuse-2474959-7.patch

This worked for me......thanks

I don't want to RTBC my own patch, but we've had great success with #19 on several production sites.

Patch in #19 fixed the problems for us. I guess ill RTBC then

#19 seems ok but Wundo was after some tests to help detect the issue.

Could someone look at writing a test for this scenario?

In my installation the solution #19 fixed the problem. Thanks.