133 vulnerabilities rewarded
8 days average response time
$589.10 average payout (last 12 weeks)
Latest hall of famers
In 2002, our founders, Scott Farquhar and Mike Cannon-Brookes, set conventional wisdom on its ear by launching a successful enterprise software company with no sales force. From Australia. Our first product, JIRA, proved that if you make a great piece of software, price it right, and make it available to anyone to download from the internet, teams will come. And they'll build great things with it. And they'll tell two friends, and so on, and so on.
Today a lot has changed. We're over 1,400 Atlassians (and growing), in six locations, with products to help all types of teams realize their visions and get stuff done. But the fundamentals remain the same. We're for teams because we believe that great teams can do amazing things. We're not afraid to do things differently. And we're driven by an inspiring set of values that shape our culture and our products for the better.
JIRA and Confluence are web applications, written primarily in Java, and use soy & velocity templates to render web content. More technical information about our products can be found here. The goal of this program is to ensure that our products are being constantly tested for security vulnerabilities, so that our customers trust that our products are secure. More information about our trust program can be found at https://trust.atlassian.com.
To ensure the best experience for security researchers, researchers will be able to self-signup onto our BugBounty cloud instance as non-administrative users, and will be able to start testing immediately. Please note that your @bugcrowdninja.com email address must be used to create your account. All other accounts will be deleted and blocked from the instance.
Due to the collaborative nature of Atlassian products, we are not interested in vulnerabilities surrounding enumeration and information gathering (being able to work effectively as a team is the purpose of our products). Instead, we're more interested in traditional web application vulnerabilities, as well as other vulnerabilities that can have direct impact. Below is a list of some of the vulnerability classes that we are seeking reports for:
- Cross Instance Data Leakage/Access**
- Server-side Remote Code Execution (RCE)
- Server-Side Request Forgery (SSRF)
- Stored/Reflected Cross-site Scripting (XSS)
- Cross-site Request Forgery (CSRF)
- SQL Injection (SQLi)
- XML External Entity Attacks (XXE)
- Access Control Vulnerabilities (Insecure Direct Object Reference issues, etc)
- Path/Directory Traversal Issues
Ensure you review the out of scope and exclusions list for further details.
** Cross Instance Data Leakage/Access refers to unauthorized data access between instances.
Out of scope
Any domain/property of Atlassian not listed in the targets section is strictly out of scope (for more information please see the out of scope and exclusions sections below). Researchers should use the "bugbounty-test-<bugcrowd-name>.atlassian.net" namespace provided in the instructions below. Please do not create additional instances outside of this namespace for testing.
All resources within your instance is in scope (see below for exclusions), this includes the JIRA and Confluence REST APIs. The documentation for JIRA Cloud can be found here. The documentation for Confluence Cloud can be found here. To ensure that the platform stays as fresh as possible, Atlassian reserves the right to wipe, remove, and/or otherwise modify an instance (e.g. putting it back to factory default settings) at any time. This may cause downtime on the instance.
As well as the instance itself, there are several services that interact with our products. These services are hosted using the .atlassian.io domain and are in scope *provided* that you can demonstrate a direct link between your exploit and the target instance you are exploiting. Any *.atlassian.io service that cannot be shown to directly link (or is accessible through) a target instance, will not be eligible for a reward (see below for more details).
Applications Eligible for Tier 1 Rewards (See 'Rewards' Section)
JIRA Service Desk
Confluence Cloud Mobile App for iOS
Confluence Cloud Mobile App for Android
Jira Cloud Mobile App for iOS
Jira Cloud Mobile App for Android
Any associated *.atlassian.io domain that can be exploited DIRECTLY from the *.atlassian.net instance
Jira Service Desk
Applications Eligible for Tier 2 Rewards (See 'Rewards' Section)
Confluence Team Calendars
HipChat Data Center
HipChat Mobile Client
HipChat Desktop Client
Creating Your Instance
JIRA + Confluence
To access the instance and start your testing (after you've read and understood the scope and exclusions listed below, of course) you can follow the below steps:
- Navigate to the checkout page here
- Click "Next"
- Complete the form, using the following format: bugbounty-test-<bugcrowd-name> Note that <bugcrowd-name> should be replaced with your own bugcrowd username
- Click "Start now"
- Once your instance has been completed that's it - you can test away.
- Navigate to https://bitbucket.org/ and select "Log In"
- Select "Sign Up" and create an account with your @bugcrowdninja.com email address.
- Start testing
Atlassian Server Products
To access the target and start your testing (after you've read and understood the scope and exclusions listed below, of course) you can follow the below steps:
- Navigate to www.atlassian.com
- Download the server version of the product you want to test,
- Install the product,
- (if required) Generate a trial license for the product,
- Start testing
Note: After the trial period expires you can generate another evaluation license and continue researching. Please remember to check that you are still on the latest version.
More information can be found at https://www.atlassian.com/software/jira/mobile-app and https://www.atlassian.com/software/confluence/mobile-app.
Jira Cloud Download:
Confluence Cloud Download:
Anything not declared as a target or in scope above should be considered out of scope for the purposes of this bug bounty. However to help avoid gray areas, below are examples of what is considered out of scope.
- Any Atlassian product that is not JIRA Cloud or Confluence Cloud (e.g. Bitbucket, Hipchat, Sourcetree et al)
- Any Atlassian website (e.g. www.atlassian.com) is out of scope for this bounty unless it is directly accessible from one of the targets or any associated services attached to the instance.
- Customer cloud instances are explicitly out of scope.
- Any Atlassian billing system. However, specific endpoints that are used inside of a target are in scope. For example, if a REST endpoint is proven to be called from one of the targets, then that endpoint is considered to be in scope. However, all other endpoints are not considered to be in scope, as they are not called from the instance at any stage.
- Any repository that you are not an owner of - do not impact Atlassian customers in any way.
- Only the latest version of a server product is eligible for a reward. All vulnerabilities/exploits must be proven to work in the latest version of the Atlassian server product.
** There are some exceptions to this rule, the following third party plugins are in scope:
The following finding types are specifically excluded from the bounty
- The use of Automated scanners is strictly prohibited (we have these tools too - don't even think about using them)
- Descriptive error messages (e.g. Stack Traces, application or server errors).
- HTTP 404 codes/pages or other HTTP non-200 codes/pages.
- Fingerprinting / banner disclosure on common/public services.
- Disclosure of known public files or directories, (e.g. robots.txt).
- Clickjacking and issues only exploitable through clickjacking.
- CSRF on forms that are available to anonymous users (e.g. the contact form).
- CSRF attacks that require knowledge of the CSRF token (e.g. attacks involving a local machine).
- Logout Cross-Site Request Forgery (logout CSRF).
- Content Spoofing.
- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.
- Lack of Secure/HTTPOnly flags on non-sensitive Cookies.
- Lack of Security Speedbump when leaving the site.
- Weak Captcha / Captcha Bypass.
- Login or Forgot Password page brute force and account lockout not enforced.
- OPTIONS HTTP method enabled.
- Username / email enumeration.
- Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.
- Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP.
- Cache-Control and Pragma
- HTTP/DNS cache poisoning.
- SSL/TLS Issues, e.g.
- SSL Attacks such as BEAST, BREACH, Renegotiation attack.
- SSL Forward secrecy not enabled.
- SSL weak/insecure cipher suites.
- No Load testing (DoS/DDoS etc) is allowed on the instance.
- This includes application DoS as well as network DoS.
- Self-XSS reports will not be accepted.
- Similarly, any XSS where local access is required (i.e. User-Agent Header injection) will not be accepted. The only exception will be if you can show a working off-path MiTM attack that will allow for the XSS to trigger.
- Vulnerabilities that are limited to unsupported browsers will not be accepted (i.e. "this exploit only works in IE6/IE7"). A list of supported browsers can be found here.
- Known vulnerabilities in used libraries, or the reports that an Atlassian product uses an outdated third party library (e.g. jQuery, Apache HttpComponents etc) unless you can prove exploitability.
- Missing or incorrect SPF records of any kind.
- Source code disclosure vulnerabilities.
- Information disclosure of non-confidential information (e. g. issue id, project id, commit hashes).
- The ability to upload/download viruses or malicious files to the platform.
- Email bombing/Flooding/rate limiting
- You must ensure that customer data is not affected in any way as a result of your testing. Please ensure you're being non-destructive whilst testing.
- In addition to above, customer instances are not to be accessed in any way (i.e. no customer data is accessed, customer credentials are not to be used or "verified")
- If you believe you have found sensitive customer data (e.g., login credentials, API keys etc) or a way to access customer data (i.e. through a vulnerability) report it, but do not attempt to successfully validate if/that it works.
- Use of any automated tools/scanners is strictly prohibited and will lead to you being removed from the program (trust us, we have those tools too).
- Reports need to be submitted in plain text (associated pictures/videos are fine as long as they're in standard formats). Non-plain text reports (e.g. PDF, DOCX) will be asked to be resubmitted in plain text.
- Grants/awards are at the discretion of Atlassian and we withhold the right to grant, modify or deny grants. But we'll be fair about it.
- Tax implications of any payouts are the sole responsibility of the reporter.
- Do NOT conduct non-technical attacks such as social engineering, phishing or unauthorized access to infrastructure.
- Do NOT test the physical security of Atlassian offices, employees, equipment, etc.
- This bounty follows Bugcrowd’s standard disclosure terms.
- Any vulnerability found in a JIRA or Confluence server product is not eligible for a reward in JIRA/Confluence cloud, and vice versa (i.e. no double dipping).
Before disclosing an issue publicly we require that you first request permission from us. Atlassian will process requests for public disclosure on a per report basis. Requests to publicly disclose an issue that has not yet been fixed for customers will be rejected. Any researcher found publicly disclosing reported vulnerabilities without Atlassian's written consent will have any allocated bounty withdrawn and disqualified from the program.
|Category||Tier 1||Tier 2|
Note: Atlassian uses CVSS to consistently score security vulnerabilities. Where discrepancies between the VRT and CVSS score exist, Atlassian will defer to the CVSS score to determine the priority.