Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

CVE-2021-44228 Atlassian using log4j 1.2.17


A Major vulnerability has been published named CVE-2021-44228, and looking into our Atlassian products, a fairly old version of log4j is used all across the different products.

What actions does Atlassian recommend to mitigate this vulnerability?

11 answers

BitBucket server bundles elasticsearch, which does have the affected log4j artifacts present.

In the FAQ for this CVE Atlassian is saying that Bitbucket Server & Data Center are not affected but I was just thinking the same. Elasticsearch in Bitbucket 7.6.10LTS comes with log4j-core-2.11.1.jar. And according to Apache this version is vulnerable. Should Atlassian not recommend the replacement of this lib?

Like # people like this

I wonder the same thing.  For example, we also use SonarQube, which is not vulnerable per the vendor, but it uses ElasticSearch and so they recommended a change to the JVM arguments to mitigate.

Like # people like this

Here's what I've done in the absence of any official confirmation/guidance.


In the BitBucket home directory there's a file called shared/search/jvm.options

Change this:

# log4j 2
-Dlog4j2.disable.jmx=true this:

# log4j 2
# CVE-2021-44228 mitigation

This next one may be unnecessary, but just to be safe, I edited bitbucket/7.5.0/bin/ and changed this:



Like # people like this

Thanks, @andrewbrock, this has been so far the most useful information related to potential vulnerability in ElasticSearch embedded in Bitbucket.

Regarding this vulnerability in Bitbucket, you can also check dedicated thread:

Has anyone found a way of upgrading the log4j2 package instead? We're trying to remove all copies of the jar with the vulnerability in it (but it's definitely needed for the elasticsearch service to start).

At it is, the elasticsearch service that comes with bitbucket only listens on the loopback address, so it can't be access externally.  At worst, somebody might be able to interactively login to the bitbucket server as a low-privileged user, send a message to the elasticsearch service and execute code in the context of that service's credentials, but there's no good reason to have any low-privilege users that allow interactive login to the bitbucket server anyway.  

I've read the FAQ at but I'm not clear whether plugins for Data Center/Server could be affected.  We have a ton of plugins.  Anyone know?  It seems plugins would just leverage the main log4j component installed with Jira/Confluence, but I'm not sure.

+1, good question. I think we both are assuming, that plugins just leverage the main loh4j component, but it would be nice if someone from Atlassian would acknowledge that. 

Atlassian !?

Like # people like this

In the newly released document, Multiple Products Security Advisory - Log4j Vulnerable To Remote Code Execution - CVE-2021-44228 | Atlassian Support | Atlassian Documentation (accessed, 14-Dec-2021, 12:30 AM PST)

Atlassian mentions that they have “...identified third-party apps that are vulnerable”.


Atlassian is also scanning and reviewing data center and server apps. Similar to cloud apps, Atlassian has yet to discover apps developed by Atlassian that are vulnerable to CVE-2021-44228, but have identified third-party apps that are vulnerable. Each vulnerable DC or server app will be given the same expedited deadline as cloud apps. DC and server apps that fail to address the vulnerability within this expedited timeframe will be removed from the marketplace, and then Atlassian will inform customers who have vulnerable apps installed.

Finally, Atlassian is encouraging all cloud, DC and server apps vulnerable to CVE-2021-44228 to rotate their shared secret, and to directly communicate with customers themselves about their efforts to mitigate the situation.

Like # people like this
6 votes
Daniel Eads Atlassian Team Dec 10, 2021

Hi all,

Daniel from Atlassian Support here. I'd just like to provide you with this preliminary FAQ related to the log4j zero-day. Our Security team is currently investigating the impact of the Log4j remote code execution vulnerability (CVE-2021-44228) and determining any possible impacts. In the meantime, hopefully this FAQ will help address some initial questions you may have.

Daniel Eads | Atlassian Support

We do not have JMS Appender enabled in our configuration and were still hit by a malware attack on our Confluence server yesterday.

It was the same malware that hit us in August due to this vulnerability:

Obviously we have since upgraded, currently on 7.13.0


Given that log4j 1.2 was end of life in 2015 and has other security vulnerabilities logged against it, I'm shocked that it's still in use.

Like # people like this

Hi @Daniel Eads,

Is there any official way to follow this topic? I am already watching some pages in the community, but it is not possible to watch the initial faq,


How it is assumed we can be aware of any update related Atlassian investigation?

Thank you

Like Ian Chan likes this

Has there been any updates yet from the Security Team at Atlassian? Curious if it will be something minor (replace log4j-1.2 jar file) or a full upgrade is required.

Like # people like this
3 votes

Hi all,

Daniel with Atlassian Support here to let you know our security team has finished its investigation. We have an official response statement here on Community, which you can access at this link.

Additionally there is more information available on our advisory page, as well as the previously-published FAQ:

Daniel Eads | Atlassian Support


Is there a reason why BitBucket Server isn't mentioned anywhere in either of those links? What about the bundled elasticsearch product?

Like # people like this

@Daniel Eads - "Atlassian has yet to discover apps developed by Atlassian that are vulnerable to CVE-2021-44228, but have identified third-party apps that are vulnerable"

Can you share which third party apps are vulnerable?

Like # people like this

AS the third party has their own legal rights and perview over their response to the matter, I am not sure this will be possible but will be happily surprised if this can be provided, at least, to assure that Plugins are or are not affected, which I am taking the inference to mean that "third-party apps" refers to plugins which deployments may or may not be using.

Daniel Eads Atlassian Team Dec 15, 2021

@andrewbrock The advisory has been updated with additional information about Bitbucket Server and the bundled elasticsearch:

Like Christian Bär likes this

You need to check-in <installation directory>\lib\log4j-1.2.17-atlassian-3.jar.

Jira 8.13.x is using log4j version 1.2.17.

CVE-2021-44228 is affected with version 2 of log4j between versions 2.0-beta-9 and 2.14.1. It is not present in version 1 of log4j and is patched in 2.15.0.

btw i am talking Jira Server version.

Like # people like this

Mh for log4j v1.2.17 there exists a RCE vulnerability since 2019:

Like # people like this

Just to note.... 2.15 has another vulnerability.  2.16 is minimum version (for now).

2.16. is also not enough at all, there was another vulnerability found:

Apache already released version 2.17.0 - as a reference of @Vijay Sv there is an existing vulnerability wat @Leon Lehmann already mentioned. Furthermore the support for the version 1.x already ended in August 2015.


So what will Atlassian do in the future? Do you as Atlassian team assume responsibility for a possible attack? @Daniel Eads 

Hi @Tobias , please refer to the Atlassian advisory for impact on Atlassian products, and then elastic's announcement for more impact information related to the bundled elasticsearch product in Bitbucket Server. Both these articles take the information from the initial CVE-2021-44228 and follow-up CVE-2021-45046 into consideration.

Edit: Our security team has updated the FAQ (not the advisory itself) to explicitly include CVE-2021-45105 and indicate no impact.

2 votes
Clark Everson Community Leader Dec 10, 2021


Honestly there was a more recent security incident than that:

The only path for it is to upgrade to the recommended versions. If you want to have an easier path forward then using LTS version (for Confluence it would be 7.13.x as the latest) would be the easiest path as these are supported for 2 years.

Upgrading will take care of all security issues that are currently known but as the CVE from November has no other path this would be the best path for any old ones you have as well as the newest ones.

CVEs can be tracked here:

Usually they have a temporary fix but in general the long term fix is upgrade. LTS's make that easier as security issues are patched on them for two years as long as you install the patch, which usually involves much less testing then full version upgrades as they are designed that you can just install the patch and be safe.




Clark Everson Community Leader Dec 10, 2021

Hi @Christian Elsner 

Thanks for the information, honestly I couldn't find any documentation on it when I looked. However, for this user, the upgrade path to LTS would still be the recommended route because when they have a fix an LTS just requires you to do the patch upgrade and will continue to do so for two years from release.

Mitigations are only temporary and usually cause loss of features, Keeping LTS's updated resolves these issues.




Like # people like this

The fix for the unicode bidirectional threat does not address CVE-2021-044228.  It does mitigate CVE-2021-42574. Per another thread, Atlassian products are not affected by log4j issue because it is running on version 1 not version 2.  Upon further research, Atlassian is still gathering information on using log4j 2.

There is a jar (\Atlassian\JIRA\atlassian-jira\WEB-INF\lib\log4j2-stacktrace-origins-2.2-atlassian-2.jar) that apparently refers to the version 2.x

Like # people like this

Same in our version of Jira v8.13 LTS.  Do we know if the JMSAppender vulnerability applies to log4j v2 versus 1.2?

Like Espen Sandall likes this

How do we know what is the version of log4j used by Atlassian DC servers especially Jira , Bitbucket and Confluence. Does it display in the UI of the server properties? 

Hello together, 

now I think Atlassian has to investigate fast because there are new findings that V.1.x is not safe enough. 

This is the CVE which is the main reason for 2.16.0.
For this kind of attack, either the "log4j2.noFormatMsgLookup" property nor the 2.15.0 helps.

0 votes
Bill Bailey Community Leader Dec 10, 2021

There is another thread related to this topic/ 

Seems the version Atlassian is using is not impacted.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published in Confluence

Watch 4 Confluence apps compete for Best App Demo in September's Appy Hours

Calling all collaborators! Appy Hours on the Atlassian Community is a monthly event where 4 Partner and app vendor presenters go head-to-head with 5-minute demos for the title of Best App Demo. I...

520 views 0 12
Read article

Atlassian Community Events