General Information

This page contains frequently asked questions and answers about our recently published security advisory Multiple Products Security Advisory - Log4j Vulnerable To Remote Code Execution - CVE-2021-44228 related to the vulnerability affecting Log4j, CVE-2021-44228. In addition, we have guidance about the related vulnerabilities, CVE-2021-45046 and CVE-2021-45105.

Are Cloud instances affected?

No, Atlassian customers are not vulnerable, and no action is required. This vulnerability has been mitigated for all Atlassian cloud products previously using vulnerable versions of Log4j. To date, our analysis has not identified compromise of Atlassian systems or customer data prior to the patching of these systems. 

Is my on-premises Server/Data Center instance affected?

Our Security team investigated the impact of the Log4j remote code execution vulnerability (CVE-2021-44228) and have determined that no Atlassian on-premises products are vulnerable to CVE-2021-44228.

Some on-premises products use an Atlassian-maintained fork of Log4j 1.2.17, which is not vulnerable to CVE-2021-44228. We have done additional analysis on this fork and confirmed a new but similar vulnerability that can only be exploited by a trusted party. For that reason, Atlassian rates the severity level for on-premises products as low. Specifically, Atlassian products that use Log4j 1.x are only affected if all of the following non-default configurations are in place: 

• The JMS Appender is configured in the application's Log4j configuration
• The javax.jms API is included in the application's CLASSPATH (e.g. for Jira the <install>/WEB-INF/lib sub-directory)
• The JMS Appender has been configured with a JNDI lookup to a third party. Note: this can only be done by a trusted user modifying the application's configuration, or by trusted code setting a property at runtime 

The following products use the Atlassian-maintained fork of Log4j 1.2.17:

• Bamboo Server and Data Center
• Confluence Server and Data Center
• Crowd Server and Data Center
• Fisheye / Crucible
• Jira Server and Data Center

You can check if you are vulnerable by inspecting the Log4j configuration file. If you find a line containing the org.apache.log4j.net.JMSAppender, you may be vulnerable. If you do not find a line containing the org.apache.log4j.net.JMSAppender, you do not have this specific vulnerable configuration.

How can I mitigate this vulnerability?

If you're using the functionality provided by JMS Appender we recommend you mitigate the vulnerability as soon as possible by temporarily disabling any configured appenders utilizing org.apache.log4j.net.JMSAppender by commenting out the relevant lines in your Log4j configuration file and restarting the application. In a Data Center environment, a rolling restart of the nodes is sufficient after updating affected configuration files. 

The default location of the Log4j configuration file for each product is listed in the table below:

<install-directory>/crowd-webapp/WEB-INF/classes/log4j.properties
<install-directory>/crowd-openidclient-webapp/WEB-INF/classes/log4j.properties
<install-directory>/crowd-openidserver-webapp/WEB-INF/classes/log4j.properties

I see Bitbucket Server/Data Center isn't in the list of products using Log4j but I can see Log4j JAR files in my installation directory, is my instance vulnerable?

Neither Bitbucket Server nor Data Center use Log4j, they use Logback. The files exist to allow Log4j components to be used for the logging framework which isn't vulnerable.

We have updated our security advisory on 16 Dec 2021 to highlight that Bitbucket Server and Data Center are vulnerable due to usage of Elasticsearch which is bundled with Bitbucket. Learn more about upgrading to a fixed version and how to mitigate the vulnerability in the interim in the advisory: Multiple Products Security Advisory - Log4j Vulnerable To Remote Code Execution - CVE-2021-44228

Still referring to Bitbucket Server/Data Center, should I delete the JAR files?

No, do not delete the JAR files. While deleting the JARs won't impact core Bitbucket functionality, other apps may be impacted, including apps in the Atlassian ecosystem. The apps that use our Log4j's APIs (v1 or v2) in product actually log with Logback. 

How can I tell if my system has been compromised?

Unfortunately, Atlassian cannot confirm if your instance has been compromised. All security compromises are different, and we strongly recommend involving your local security team or a specialist security forensics firm for further investigation.

Are Atlassian products impacted by the related CVE-2021-45046 and CVE-2021-45105 vulnerabilities?

Two related vulnerabilities were discovered in non-default configurations of Log4j:

• 2.0-beta9 to 2.15.0 (inclusive) are affected by CVE-2021-45046
• 2.0-alpha1 through 2.16.0 (excluding 2.12.3) are affected by CVE-2021-45105

The Atlassian security team has not identified any vulnerable configurations in use by Atlassian products or services for either of these vulnerabilities. Neither vulnerability applies to Atlassian's Log4j 1.x maintained fork as outlined in this FAQ page.

Regardless of whether the vulnerable configuration is in use, Atlassian will be addressing CVE-2021-45046 and CVE-2021-45105 by upgrading to log4j 2.17.0 (or greater) in line with the timeframes detailed in the Atlassian Security Bugfix Policy.

Are Atlassian products impacted by CVE-2021-44832?

CVE-2021-44832 does not affect the Atlassian-maintained fork of Log4j 1.2.17.

Elasticsearch bundled with Bitbucket (or your standalone Elasticsearch instance for DC) is not affected by CVE-2021-44832 according to Elastic Security Advisory ESA-2021-31.

Please note, exploiting CVE-2021-44832 requires an attacker to have elevated permissions to modify the log4j configuration file in order to exploit it. It is not a critical vulnerability like CVE-2021-44228. It has been assigned a CVSSv3 base score of 6.6 (medium) by the National Vulnerability Database.

Is the Atlassian Plugin SDK vulnerable to CVE-2021-44228 or CVE-2021-44832?

The Atlassian Plugin SDK uses Log4j 1.x and is therefore not affected by CVE-2021-44228 or CVE-2021-44832.