General Information

Atlassian is aware of the current critical severity in multiple Atlassian products allowing a remote, unauthenticated attacker to bypass Servlet Filters used by first and third-party apps. The impact depends on which filters are used by each app, and how the filters are used. Atlassian has released updates that fix the root cause of this vulnerability but has not exhaustively enumerated all potential consequences of this vulnerability. Read more about Atlassian Server and Data Center - CVE-2022-26136/7 -Servlet Filter Dispatcher Vulnerability.

This page contains frequently asked questions and answers about this vulnerability. The Atlassian Security Team will continually update this page as new information becomes available.

Are Cloud instances affected by these vulnerabilities?

No, Atlassian cloud instances are not vulnerable and no customer action is required.

Are other Atlassian Server (DC) products affected by this vulnerability?

The following products have been identified as being affected:

• Bamboo Server and Data Center

• Bitbucket Server and Data Center

• Confluence Server and Data Center

• Crowd Server and Data Center

• Fisheye and Crucible

• Jira Server and Data Center

• Jira Service Management Server and Data Center

I don't use any third-party apps, am I safe?

These vulnerabilities affect the code included with each affected product. Systems are still affected even if they do not have any third-party apps installed.

How does Atlassian decide whom to send these emails to?

Atlassian sends a copy of all critical security advisories to the 'Alerts' mailing list for the product concerned, excluding Sourcetree. To ensure you are on this list, please update your email preferences at https://my.atlassian.com/email.

Can we determine if the instance has already been compromised?

Unfortunately, Atlassian cannot confirm if an instance has been compromised. Please involve the local security team or a specialist security forensics firm for further investigation.

Atlassian recommends checking the integrity of the application filesystem, for example, comparison of artifacts in their current state with recent backups to see if there are any unexpected differences.

All security compromises are different, and there is a risk that an attacker could hide their footprint and change important files such as (syslogs, audit logs, access logs, etc.) depending on the component that has been compromised.

My instance is NOT connected to the internet, what should I do? Should I still upgrade?

Yes, please upgrade! While ensuring instances are not exposed to the public internet greatly reduces the attack surface, we always recommend upgrading when security fixes are available. Additionally, attacks like cross-site scripting are still possible even if the instance is not accessible from the internet.

We try to provide as much information as possible so that customers can determine the scope and impact. It's ultimately up to each customer to consider this information when determining whether mitigating factors, like no external access to the instance, reduce the risk to their business enough to defer installing an upgrade.

Is it possible to mitigate this vulnerability by changing my proxy settings?

While this seems like a good idea at first, block lists are prone to bypass and therefore not reliable enough for us to suggest as a viable workaround for this type of vulnerability. There are too many encoding considerations to account for and it would be nearly impossible for us to be sure that we would have covered them all. In fact, we have tried to provide guidance on how to block malicious requests in the past, but unfortunately, this alternative has proven to be unreliable.

How do I know if the patch/update works?

You can verify whether your instances have been successfully updated by comparing their version number to the list of fixed versions in the security advisory.

How do we know there won't be another advisory in a month?

We are aware that having multiple advisories in such a short period presents a challenge. Although we cannot guarantee that there will be no further advisories in the near future, I can point you to our security advisory history. As you can see, this is an atypical situation and our priority is always to make your instance as secure as possible.

Why have there been so many advisories lately?

Atlassian uses multiple methods to identify critical security vulnerabilities in our products. When a critical vulnerability is discovered, it's our duty to notify you in a timely manner so that you can protect your systems.

I have just recently upgraded my instance, how do I know I won’t have to upgrade again in 2 weeks?

We are aware that having multiple advisories in such a short period presents a challenge. Starting in July 2022, Atlassian will publish critical security advisories once a month at most with the following exceptions:

• A critical vulnerability is publicly and widely known
• There are verifiable reports of exploitation in the wild

We use HTTPS/SSL, are we still vulnerable?

Yes. HTTPS is HTTP with encryption (SSL/TLS) which helps secure content traveling between two points. Whether or not encryption is used doesn’t have any effect on how the vulnerability can be exploited.

Product Specific

Jira Server/Data Center

I upgraded Jira/some affected third-party apps recently to fix Authentication bypass in Seraph - CVE-2022-0540, is my instance safe?

No, this is a different security vulnerability and the previous updates were specific to the CVE-2022-0540 vulnerability. You must upgrade to a fixed version specified in the security advisory in order to protect your Jira instance. 

In the prior CVE (Authentication bypass in Seraph - CVE-2022-0540) you were able to determine the affected third party apps, why weren't you able to do so in the case?

CVE-2022-0540 affected apps that used specific settings in their XML configuration, which made it possible for Atlassian to scan all Marketplace apps to determine which ones were affected. We can't understand the impact of CVE-2022-26136 and CVE-2022-26137 on each app without understanding the Servlet Filters used by each app and the business logic involved, which makes it infeasible to scan for.  

I upgraded Jira to fix  Full-Read Server Side Request Forgery in Mobile Plugin - CVE-2022-26135, is my instance safe?

If you've previously upgraded to a fixed version specified in the security advisory, your instance is safe. If you've only updated the Mobile Plugin for Jira as part of the mitigation for CVE-2022-26135, you must upgrade to a fixed version specified in this security advisory to protect your instance. 

I need help upgrading my Jira instance, what should I do?

For detailed information and step-by-step instructions related to upgrading, please see Upgrading Jira for more information. This is our recommended, supported method for upgrading Jira. It contains all the information in this comment as well as other helpful tips to be sure your upgrade is successful.

For upgrading Jira Data Center using with Zero Downtime, please see Upgrade Jira with Zero downtime for more information.

Testing

The most important step to take to avoid production outages is to follow change management best practices by testing the upgrade in a staging environment first. For more information on how to set up a staging environment, see Create a test environment for Jira.

If you still have questions or concerns, please raise a support request at https://support.atlassian.com/.

Confluence Server/Data Center

I upgraded my Confluence instance during the last advisory, what do I need to do now?

The code remediation for Servlet Filter Dispatcher Vulnerability was included in the same bug fix releases for Confluence Security Advisory 2022-06-02. This means your Confluence version is not vulnerable and no further action is needed.

Please note this information applies to Confluence only. Consult the support team if you have any questions regarding the other products involved in the advisory.

What if I mitigated in the last advisory instead of upgrading?

The Servlet Filter Dispatcher Vulnerability does not have remediation or mitigation steps for affected versions. This means it requires an upgrade to the fixed versions to protect the instance against exploit attempts.

I need help upgrading, what should I do?

For detailed information and step-by-step instructions related to upgrading Confluence, please see Upgrading Confluence or Upgrading Confluence Manually. This is our recommended and supported method for upgrading Confluence. It contains all the information in this comment as well as other helpful tips to be sure your upgrade is successful.

The most important step to take to avoid production outages is to follow change management best practices by testing the upgrade in a staging environment first. For more information on how to set up a staging environment, see Create a staging environment for upgrading Confluence.

If you still have questions or concerns, please raise a support request at https://support.atlassian.com/

Bamboo Server/Data Center

I need help upgrading my Bamboo instance, what should I do?

For detailed information and step-by-step instructions related to upgrading, please see Bamboo Upgrade Guide. This is our recommended, supported method for upgrading Bamboo and other helpful tips to ensure your upgrade is successful.

Testing

The most important step to take to avoid production outages is to follow change management best practices by testing the upgrade in a staging environment first. We highly recommend running the upgrade steps with latest production data to help catch any possible issues you may encounter during the production upgrade. 

 Fixed Versions

 Please refer to the following list of fixed versions that were released for Bamboo: 

• 7.1.x or 7.2.x >= 7.2.9

• 8.0.x >= 8.0.9

• 8.1.x >= 8.1.8

• 8.2.x >= 8.2.4

• Versions >= 9.0.0

If you still have questions or concerns, please raise a support request at https://support.atlassian.com/

Bitbucket Server/Data Center

I need help upgrading my Bitbucket Server/Data Center instance, what should I do?

For detailed information and step-by-step instructions related to upgrading, please see Bitbucket Data Center Upgrade Guide for more information, or if you are not running Bitbucket in a cluster, please follow the instructions under our Bitbucket Server upgrade guide. This is our recommended, supported method for upgrading Bitbucket Server, and it contains all the information in this comment as well as other helpful tips to ensure your upgrade is successful.

For upgrading Bitbucket Data Center using with Zero Downtime, please see Upgrade Bitbucket Data Center with Zero downtime for more information.

Testing

The most important step to take to avoid production outages is to follow change management best practices by testing the upgrade in a staging environment first. For more information on how to set up a staging environment, see How to establish staging server environments for Bitbucket Server.

 Fixed Versions

 Please refer to the following list of fixed versions that were released for Bitbucket Server: 

• 7.6.x >= 7.6.16 (LTS)
• 7.17.x >= 7.17.8 (LTS)
• 7.19.x >= 7.19.5
• 7.20.x >= 7.20.2
• 7.21.x >= 7.21.2 (LTS)
• 8.0.x >= 8.0.1
• 8.1.x >= 8.1.1
• Versions >= 8.2.0

If you still have questions or concerns, please raise a support request at https://support.atlassian.com/.

Why hasn't this bugfix been released for the version I'm using?

As per our Bug fix policy, we are committed to backporting critical security bug fixes to all LTS versions released in the last 2 years and to all feature versions released within 6 months of the fix release date, which means that any version below 7.19.x that is not an LTS (Long Term Support) version will not receive the fix for this or any other future security bug. If you want to ensure your version of Bitbucket gets bugfixes, we recommend ensuring you upgrade before your version reaches end of life.