It was possible for a third party website to retrieve information about the currently logged in user via the Bitbucket API. This data included email addresses, SSH public keys, and repository information.
This vulnerability was first reported and patched in mid-2012. It was rediscovered and patched again in mid-2013.
What is JSONP?
I gave a presentation late last year which has a bit more information on JSONP and more examples of sites that had JSONP-related vulnerabilities in the past (including the original instance of this vulnerability).
Vulnerability Details: Mid-2012
Back in 2012, Bitbucket’s REST API was accessible at
The API at that URL was meant to use OAuth tokens for authentication.
In my investigation, I discovered that the API could also be accessed via a second URL,
https://bitbucket.org/!api/1.0/. The difference between the two was that
the second URL could authenticate requests using the browser’s cookies. Both forms of
the REST API supported JSONP via a
callback parameter passed in the URL.
As a result, it was possible for a third-party website to add a
<script> tag that would
pull in user information via JSONP API queries. To demonstrate the issue I built a
proof of concept page which would make simple queries to the API. Those queries
could uncover user information, email addressed, and SSH keys linked to an account.
More complicated queries (ie: those involving repositories that the currently logged
in user could access) were possible as well although not built in to the proof of concept.
I reported the issue to
email@example.com and it was patched approximately
six hours later.
Vulnerability Details: Mid-2013
In mid-2013 I retested the site and discovered, to my surprise, that the vulnerability had
reappeared. Looking at the API documentation, the main endpoint had been moved to
https://bitbucket.org/api/1.0. Now no matter which URL I used I was able to extract
user information via JSONP. In addition, although the API endpoints I used to fetch email
and SSH public key information were no longer documented, my existing proof of concept worked
without any modifications. I reported the issue to Atlassian again and it was patched again.
- May 30th, 2012 11:08 AM: Initial email with proof of concept sent
- May 30th, 2012 6:48 PM: Response from Atlassian, fix has been rolled out. Ask for confirmation that issue has been resolved.
- May 30th, 2012 6:58 PM: Reply to Atlassian confirming fix.
- June 11th, 2013 11:11 AM: Email sent to
firstname.lastname@example.org them that vulnerability has reappeared. Included previous correspondence, link to proof of concept.
- June 11th, 2013 8:36 PM: Reply from Atlassian, claim that vulnerability was patched last year and that patch was still in place.
- June 11th, 2013 8:56 PM: Email sent to Atlassian, disputing assertion that vulnerability is patched. Screenshots and additional information related to proof of concept attached.
- June 11th, 2013 9:09 PM: Reply from Atlassian, confirming that vulnerability has reappeared.
- Prior to June 26th, 2013: Testing confirms that vulnerability is patched in production.
- June 26th, 2013: Published blog post