[policy] Treat CAPTCHA bypasses as non-security bugs

Malfunctioning CAPTCHAs do not represent a security risk on their own.

Wouldn’t a Captcha be classified as part of Authorization under AAA and bypassing it be an Authorization Bypass?

There is a dedicated CWE for easily guessable captchas that specifically calls out that a bot being able to perform actions more frequently is itself a risk https://cwe.mitre.org/data/definitions/804.html. If being guessable (which means still going through the entire process just with the process not providing useful protection) is a flaw why wouldn’t complete bypass be a flaw?

Amend policy to make CAPTCHA bypass bug reports public.
CAPTCHA bugs that open attack vectors remain private.

Sounds contradictory, if a captcha bypass is an authorization bypass it would itself be an attack vector.

Yes, of course, I understand that passing a CAPTCHA authorizes some further action, but think of that authorization completely differently than, say, a role or a permission in a security system.

I believe Captchas fall under a form of Attribute Based Access Control (ABAC) rather than Role Based Access Control (RBAC) where "has passed Captcha validation = true" is intended to be enforced as part of the Authorization check when one deploys Captcha protection (be it for every page for specific pages).

But if CAPTCHA has been officially categorized as a form of authorization by those who have thought about this more than I have, or if it's been legally designated as such, we should close this issue. Also, I may just be wrong.

Does this list of CVE's that reference Captcha Bypass provide any guidance to sway your opinion one way or the other?
https://github.com/search?q=repo%3ACVEProject%2FcvelistV5+captcha+bypass...

Note: Captcha being easily solvable (which may become more common in the future with AI becoming better at passing Captcha)
If the modules use 3rd party Captcha providers and the Captcha itself is easily solvable he vulnerability would not be in the Drupal module it would be in the 3rd party provider. This is already covered under a "not distributed from D.O" lack of scope.

Interesting discussion. I get the motivation (if I'm understanding correctly) to reduce the work load of CAPTCHA-related CVEs given the points cilefen makes.

At the same time, CAPTCHA workarounds are currently widely treated as vulnerabilities. Why would that be when they are so often found on forms that must also be defeated?

I took a look at some of the CAPTCHA related vulnerabilities in the list that cmlara linked to and in all the cases I looked at (ok, just 3) the CAPTCHA was used as an adjunct to a form. In these cases, defeating the CAPTCHA in whatever way then presents the attacker with another obstacle, such as brute-forcing.

For example:

• for D-Link DIR-615 routers, bypassing the login-page CAPTCHA enables brute-force attacks on credentials
• SureMDM: CAPTCHA bypass enables username enumeration via error messages (CWE-203)

In one instance I checked, it led to code execution:

• Liferay Portal/DXP: a CAPTCHA-check bypass that then lets attackers run scripts in the Gogo shell (i.e., escalates to code execution)

The Liferay folks did use the CAPTCHA as an adjunct to their existing permission check and they still treated it like a security vulnerability (though that could just be inertia, of course).

I was curious if one would ever find a CAPTCHA that isn't tied to some other mechanism that must also be defeated. What if the only thing on a form were the CAPTCHA? I stopped looking before I found an instance of that in the list above; it does seem like it would be rare—but that's not the same as saying it is impossible to find in the wild.

In fact, we can't possibly know how a CAPTCHA will be used and whether it gets help from any other test such as regular auth. The maker of the module (and us, too) must assume that the standalone case is possible.

So this exploration leads me to conclude:

• We can't possibly know what exactly is being protected and the danger that might arise
• We can't possibly know if it's doing all the protecting; we must assume that use case is possible

Thus it seems to me that we should continue to treat vulnerabilities of CAPTCHAs as full-fledged security issues.

That being said, the work load concern is legitimate. Unfortunately, I don't have a good suggestion to help mitigate that.

is an ineffective CAPTCHA that is working as designed a security bug?

Its certainly a weakness that can become a vulnerability:
CWE-804: The product uses a CAPTCHA challenge, but the challenge can be guessed or automatically recognized by a non-human actor.

The CVE Program definition of a vulnerability is:

An instance of one or more weaknesses in a Product that can be exploited, causing a negative impact to confidentiality, integrity, or availability; a set of conditions or behaviors that allows the violation of an explicit or implicit security policy.

https://www.cve.org/ResourcesSupport/Glossary?activeTerm=glossaryVulnera...

(I chose the CVE program version as the Drupal Association as a CNA is bound to adhere to the CNA rules, even if the DST didn't publish the Drupal CNA might have to.+

For a Captcha to me that means:
This design choice might let me bypass Captcha = weakness (a true theoretical attack however no one can find a way to make it happen yet).
This design choice has a proven (or is well understood to be technical possible even if extremely hard or unlikely ) method that can be used to bypass the Captcha with this tool that does not require human interaction = likely vulnerability.

Captchas are a bit fun in the modern world that we are starting to think of them as less fool proof, though for example the Cloudflare Turnstile for example I'm still not aware of a way to automatically bypass that doesn't require some form of human solver in the backend indicating there is still an ability to have secure Captchas, for now.

All CAPTCHAs are ineffective eventually.

Indeed, that is why, just like cryptography, they need to adjust over time and improve. We periodically increase our cryptographic key sizes, captchas periodically need to increase their challenge hardness.

I will note that if the concern is developers creating poor captcha (trying to do the old obfuscated text system) that should IMO be discussed in a more narrow scope, you wouldn't want to exclude all captcha related bypasses to solve that issue.

There is maybe a slim amoutn of room, if a captcha says "This is for fun, its not intended to provide any validation that the respondent is a human,", that its made abundantly clear during download and configuration that there is neither an implicit or explicit security policy involved. in which case its a DST training users it gives the ability to opt into security advisory coverage how to determine if the custom captcha they have designed is secure. Again noting that if they don't develop the captcha itself and instead use an API to call it, like reCaptcha, that is found to be ineffective the flaw likely is out of scope as 'not hosted on D.O.'.

I wonder what our cutoff would be for when to issue a CVE? If a CAPTCHA can be bypassed 100% of the time by spending a week writing a custom script should that get a CVE? If it takes 10 tokens per request to bypass it does that constitute a vulnerability (or 100 tokens per request, or 1,000)?

And I wonder about another scenario for the need to keep up over time: Consider a captcha tht is released and is effective 90% of the time. It can have no code changes, but new bot techniques are released over time that defeat it 100% of the time. Would we issue a CVE for that scenario? I can see a case for treating that as a feature to harden the captcha rather than a bug or vulnerability.

Was the original concern for this issue intended to focus on modules that try and create their own captcha service rather than relying on commercial vendors? I went into this initially thinking more about "module implements reCaptcha however it fails to validate the return token causing a bypass" rather than "Unskilled Drupal developer tried to create a captcha module using techniques that haven't worked in a decade".

I wonder what our cutoff would be for when to issue a CVE? I

That indeed will be a bit subjective. I would refer back to the CWE "The product uses a CAPTCHA challenge, but the challenge can be guessed or automatically recognized by a non-human actor." there is no lower threshold. The question is when is it being bypassed vs when is it just being guessed.

I'll admit I grapple with that a little bit when its in the low bypass range as I know most technologies are not fool proof, its much easier to determine when its the 0% and 100% sides of the scales.

I would also add its not just the guess rate, one would want to analyze the ones that do pass to determine if this is actually the generation routine is weak and its 1 in X are 'weak enough' that the attacker system is able to process it. Especially true if the system allows refreshing the Captcah to find a weak prompt.

That part is going to have to fall into CNA discretion when issuing a determination, with a reminder that generally if the threat risk requires input from a site owner that a CNA should error on side of considering it a vulnerability and publish in order to allow a site owner to evaluate the actual threat for their system.

Cost is not generally a factor to consider, the Security Team needs to assume the funding is available to find even the smallest weakness, and as a site owner I need to know of these previous flaws so that I can quickly patch and go back through my logs to look for indicators of compromise. For large hacking rings funding is not an issue, the question for them is return on investment which depends upon who is running the vulnerable component a factor the Security Team doesn't have access to.

It can have no code changes, but new bot techniques are released over time that defeat it 100% of the time. Would we issue a CVE for that scenario? I can see a case for treating that as a feature to harden the captcha rather than a bug or vulnerability.

Newer captchas (Cloudflare Turnstile, reCaptcha 3.0) tend to run on analysis that are outside the control of the attacker making it less a vulnerability and more a false negative.

Unfortunately part of providing a captcha is providing security, once technology evolves to 100% bypass rate, based on an attacker taking explicit action, it is clearly no longer providing the security claimed. Think of this in terms of cryptography, you have to keep bumping your algorithm every so often, either by increasing key sizes or choosing a new one, if you wait until the current choice provides little or no protection you have already reached the point your not providing security.

As a side note: Hosted captchas (eg Turnstile or reCaptcha) are generally excluded from CVE's as the vendor never distributes the captcha generating code or the API server. The flaw is consider "internal" to the Captcha provider. These instead fall under Breach of Contract when the captcha provider falls below its agreed capture rate. That muddies the water a bit on finding out how many times have commercial captchas been bypassed.

What I'm seeing so far in the conversation is:

1. There is a legitimate question as to whether a CAPTCHA that can almost always eventually be defeated is worth considering as a vulnerability.
2. At the same time, the bar to reach keeps increasing over time. It's possible that the bar keeps increasing for the foreseeable future always a little but out of reach. That means that, as long as there is at least some difficulty, a CAPTCHA challenge is still worthwhile.
3. At this point in time, the industry still widely considers CAPTCHA workarounds as a vulnerability and continues to provide patches and CVEs.
4. This behavior seems to be consistent with the wording that cmlara found in the glossary.
5. Until the definition materially changes, HeroDevs will continue to treat these circumstances as vulnerabilities.
6. HeroDevs needs CVEs and their IDs for its business process, not least of which is the vulnerability directory we publish (it's our primary key). If getting a CVE through this mechanism isn't possible, it's almost certain we will issue our own CVE. (Which is not a problem, just noting it.)
7. But I am reluctant to step out of the process we have established since it's working well.

If this is a fair summation, I move to decline the proposal and retain the existing process for CAPTCHA circumstances.

I think that in the year of the cat 2026 there are many CAPTCHA solutions which are known to be readily breakable, I think we might want to narrow the community's responsibility by retiring some of these so that we can focus our efforts on solutions that are generally reliable. While not an answer to cilefen's request, I think retiring some modules (& submodules) might make life a little easier for us.

I also see two distinct issues around CAPTCHAs, and I think we should separate them:

1. CAPTCHA formula/logic, i.e. what the CAPTCHA is trying to do in order to prevent bots. Many of these become weaker over time as computational power increases, algorithms improve for code breaking & pattern detection. For example, the basic math CAPTCHAs have been around for decades, but nobody would reasonably consider them to be viable today. This is similar to how encryption algorithms are replaced over time and easily crackable ones are no longer used, e.g. you wouldn't use basic DES on a new system today, and you'd update or replace software that was still using it. A vulnerability in this logic would affect all implementations rather than a single implementation, so the solution would be to replace the logic.
2. CAPTCHA implementation - this is how the specific CAPTCHA logic is implemented in the code. For example, with a math CAPTCHA is the logic handled on-page with JS, or with dynamic server-side logic that works off the form token and session? A vulnerability in how the logic is implemented would affect the individual module, and so should be fixed.

I hope considering the two pieces of CAPTCHA solutions as separate pieces might help us reach an agreement.

I also see two distinct issues around CAPTCHAs, and I think we should separate them:

I'm not against separating them (and partly why I asked in comment #9 to see what the scope we actually wanted was).

Do we want to do so before we provide any further input so we can keep the discussions scoped and avoid more intermingling of the two scenarios?

In short, we are saying that bugs that work around solving the CAPTCHA at all would be considered distinct from CAPTCHA techniques. Do I understand?

For discussion purposes only at the moment IMO.

I can make some arguments they need to be treated both as vulnerabilities however one of them I can see requiring far less discussion than the other (thought don’t want to presume it’s 100% agreed by all here to say we don’t even need to discuss it).

In short, we are saying that bugs that work around solving the CAPTCHA at all would be considered distinct from CAPTCHA techniques. Do I understand?

That's what I propose, yes.

Since this issue hasn’t been split:

For example, the basic math CAPTCHAs have been around for decades, but nobody would reasonably consider them to be viable today

This gets back the the definition of a vulnerability

…that allows the violation of an explicit or implicit security policy.

For your less skilled users I believe all they may potentially know (from some random article) is you need to deploy a Captcha service to protect your site, they search Drupal and they find XYZ that’s a math captcha that requires no third party paid service and yet still claims to be a Captcha.

The site owner I would contend has a valid belief that module is providing an implicit security policy of protecting the site from automated attacks by just the fact it claims to be a Captcha.

If the Captcha module claims any of the following Drupal.org categories that implicit policy is further reinforced

• Access Control
• Security

(These are real categories I’ve seen Captcha modules use on a 60 second cursory review of the Drupal Ecosystem)

At the very least you need to be nullifying the implicit securtiy policy and saying “this module does not fulfill the role of a Captcha service, it is novelty module” and not claiming any security related categories.

That can’t be done by the DST declining to publish advisories, if anything it’s a reason the DST needs to be more willing to publish, to make sure maintiners know “if I develop a Captcha module I’m expected to keep it up to date with the modern threat landscape, I need to learn from this other module and not make the same mistakes”.

cmlara: That's fair. I would propose we request CAPTCHA module maintainers to distinguish between solutions/algorithms that are expected to actually stop bots from ones that do not, and update d.o policies to require security-related modules (including CAPTCHAs) be required to clearly distinguish between the two categories.

But this all goes back to the fact that no, we can't just not cover CAPTCHA modules at all.

It seems to me that everyone in the world of security is coming to grips with this new AI reality:
if there is a vulnerability in the code, a bot somewhere can find it and write an exploit within minutes.

This accelerates the need to get vulnerabilities patched and made public. The chatter out there includes answering the question, "how fast can we get vulnerabilities handled given the deluge of previously unknown vulnerabilities being submitted to OSS projects?" (Not to mention triaging all the reports that turn out not to be accurate; there are still valid vulerabilities being submitted, though.)

At first it seems that this would argue for not covering CAPTCHAs and that's where Damien's distinction comes in: Type 1 vulnerabilities aren't covered but Type 2 ones are.

But for Type 2 ones—when they are real vulnerabilities not AI slop—those need to get out there quickly. Response time is a more important factor than ever now.

So, cilefen: does this refinement to your proposal work for you?

Comment 17/18 technically means all bypasses are still vulnerabilities unless a module actively makes it clear (before the vulnerability report) that it is not intended to operate as a functional captcha module.

That would likley need documentation on project page, prohibition on using specific categories, and documentation inside the module.

I belive that is in conflict with the issue summary which to me implies some captcha bypasses in general would be excluded.

17/18 would be closer to “allow individual captcha modules to specify that captcha bypasses are not in their security scope”