Report A Vulnerability
If you believe you have found a security issue that meets Atlassian’s definition of a vulnerability, please submit the report to our security team via one of the methods below.
We are unable to respond to bulk reports generated by automated scanners. If you identify issues using an automated scanner, it is recommended that you have a security practitioner review the issues and ensure that the findings are valid before submitting a vulnerability report to Atlassian.
If you are a customer:
- Submit a ticket to our support team
If you are a security researcher:
- Submit a report through our bug bounty program; or
- Email security@atlassian.com
Only vulnerabilities submitted through our bug bounty program are eligible to receive a bounty payment.
Please include the following information in your report:
- Type of issue (cross-site scripting, SQL injection, remote code execution, etc.)
- Product and version with the bug or a URL if dealing with a cloud service
- The potential impact of the vulnerability (i.e. what data can be accessed or modified)
- Step-by-step instructions to reproduce the issue
- Any proof-of-concept or exploit code required to reproduce
If you wish to encrypt your submission with our PGP key, please download it here.
Definition of a Vulnerablity
Atlassian considers a security vulnerability to be a weakness in one of our products or infrastructure that could allow an attacker to impact the confidentiality, integrity, or availability of the product or infrastructure.
We do not consider the following types of findings to be security vulnerabilities:
- Presence or absence of HTTP headers (X-Frame-Options, CSP, nosniff, etc.). These are considered security best practices and therefore we do not classify them as vulnerabilities.
- Missing security-related attributes on non-sensitive cookies. Atlassian products may set certain security-related attributes on cookies used on our applications. The absence of these headers on non-sensitive cookies is not considered a security vulnerability.
- Exposed stack traces. We do not consider stack traces by themselves to be a security issue. If you find that a stack trace details personally identifiable information or user generated content, please submit a report detailing the issue.
- Content spoofing by administrative users. We allow administrators to inject HTML into specific areas of our products as a customization feature and do not consider that functionality to be a vulnerability.
- Clickjacking on pages in Jira Server or pages that only contain static content. For more details see - https://jira.atlassian.com/browse/JRASERVER-25143.
- Auto-complete enabled or disabled
Definition of a Vulnerablity
Atlassian considers a security vulnerability to be a weakness in one of our products or infrastructure that could allow an attacker to impact the confidentiality, integrity, or availability of the product or infrastructure.
We do not consider the following types of findings to be security vulnerabilities:
- Presence or absence of HTTP headers (X-Frame-Options, CSP, nosniff, etc.). These are considered security best practices and therefore we do not classify them as vulnerabilities.
- Missing security-related attributes on non-sensitive cookies. Atlassian products may set certain security-related attributes on cookies used on our applications. The absence of these headers on non-sensitive cookies is not considered a security vulnerability.
- Exposed stack traces. We do not consider stack traces by themselves to be a security issue. If you find that a stack trace details personally identifiable information or user generated content, please submit a report detailing the issue.
- Content spoofing by administrative users. We allow administrators to inject HTML into specific areas of our products as a customization feature and do not consider that functionality to be a vulnerability.
- Clickjacking on pages in Jira Server or pages that only contain static content. For more details see - https://jira.atlassian.com/browse/JRASERVER-25143.
- Auto-complete enabled or disabled
Definition of a Vulnerablity
Atlassian considers a security vulnerability to be a weakness in one of our products or infrastructure that could allow an attacker to impact the confidentiality, integrity, or availability of the product or infrastructure.
We do not consider the following types of findings to be security vulnerabilities:
- Presence or absence of HTTP headers (X-Frame-Options, CSP, nosniff, etc.). These are considered security best practices and therefore we do not classify them as vulnerabilities.
- Missing security-related attributes on non-sensitive cookies. Atlassian products may set certain security-related attributes on cookies used on our applications. The absence of these headers on non-sensitive cookies is not considered a security vulnerability.
- Exposed stack traces. We do not consider stack traces by themselves to be a security issue. If you find that a stack trace details personally identifiable information or user generated content, please submit a report detailing the issue.
- Content spoofing by administrative users. We allow administrators to inject HTML into specific areas of our products as a customization feature and do not consider that functionality to be a vulnerability.
- Clickjacking on pages in Jira Server or pages that only contain static content. For more details see - https://jira.atlassian.com/browse/JRASERVER-25143.
- Auto-complete enabled or disabled
Bug Bounty Program
Atlassian operates a public bug bounty program for our products via our partner, Bugcrowd. Security researchers can receive cash payments in exchange for a qualifying vulnerability report submitted to Atlassian via our bounty programs.
Public Disclosure
Atlassian makes it a priority to resolve any security vulnerabilities in our products within the timeframes identified in our Security Bugfix Policy. Atlassian follows coordinated vulnerability disclosure and requests, to protect our customers, that anyone reporting a vulnerability to us does the same.