Vulnerability Information - What are we looking for?

When submitting an issue, please provide a technical description that allows us to assess exploitability and impact of the issue.

  • Provide steps to reproduce the issue, including any URLs or code involved.
  • If you are reporting a cross-site scripting (XSS), your exploit should at least pop up an alert in the browser. It is much better if the XSS exploit shows user's authentication cookie.
  • For a cross-site request forgery (CSRF), use a proper CSRF case when a third party causes the logged in victim to perform an action.
  • For a SQL injection, we want to see the exploit extracting database data, not just producing an error message.
  • HTTP request / response captures or simply packet captures are also very useful to us.

Please refrain from sending us links to non-Atlassian web sites, or issues in PDF / DOC / EXE files. Image files are OK. Make sure the bug is exploitable by someone other than the user (e.g. "self-XSS").

We are unable to respond to generic scanner reports. If you have had a security practitioner examine a generic scan report and they have isolated specific vulnerabilities that need to be addressed, you can report the issues through our bug bounty program, or via our support team.


What we are not looking for

Auto-complete enabled or disabled : "Since early 2014 most major browsers will override any use of autocomplete="off" with regards to password forms and as a result previous checks for this are not required and recommendations should not commonly be given for disabling this feature." This is an accepted risk across the industry.

Clickjacking on pages that only contain static content or currently in JIRA Server : for more details see -

Cookies not used for authentication or CSRF protection not being marked as Secure and or HTTPOnly : "Atlassian products enforce the HttpOnly flag on session ID cookies by default, as a means to minimise the risk of common XSS attacks. However, if required Tomcat can be configured to add the HTTPOnly flag in all response headers." Please refer to this link for more details.

Presence or absence of HTTP headers (X-Frame-Options, CSP, nosniff and so on) : These are considered security best practices and are not vulnerabilities. While we are always improving our security posture, we can't apply a SLA to this type of request. Read through our current security practices.

Stack traces : We do not consider stack traces alone to be a security issue. If you find that a stack traces details personally identifiable information or user generated content, please submit a report detailing the issue.

Content spoofing : We allow html injection in specific areas of a few products as a feature for customization. We allow html injection in specific areas of a few products as a feature for customization. However, please report HTML injection performed by a limited or unauthenticated user.


PGP Information

Atlassian Security PGP details can be found here.


Public disclosure

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. 

Public disclosure requests will only be considered once the reported vulnerability is fixed.