Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


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

Atlassian's Response to Log4j (CVE-2021-44228)

On December 9, Atlassian became aware of the vulnerability CVE-2021-44228 - Log4j.

Impact on Cloud Products

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. Atlassian customers are not vulnerable, and no action is required.

Impact on On-Premises Products

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.


For further detailed information, please visit;


Dave Liao Community Leader Dec 13, 2021

Thank you for sharing this!

Like Jodie Vlassis likes this

What about the elasticsearch recommended by atlassian for bitbucket datacenter (ElasticSearch 6.8.6)?

Like # people like this

@license management we will have an update soon on this. 

Hi @Jodie Vlassis 

Our on-prem instance contains this JAR: 


This other thread has some findings/questions from other community users as well.


Based on their findings, this log4j2-stacktrace-origins-2.2-atlassian-2.jar appears to be a fork of log4j2. Is it therefore vulnerable?

Please confirm, thanks!

Like # people like this

Hi @Jodie Vlassis ,

Thank you for your notice. However, not all users follow the posts in the community in real time.

As a user, is there any way to subscribe to these latest notifications from Atlassian Support's Security?

Hi @Ollie Guan_携程_ 


You can track all things products and incidents via Atlassian Statuspage -

Hi @Jodie Vlassis ,

Thanks for your quick response ^_^.These seem to be services for the cloud. Is there an entrance to the data center?

"We have done additional analysis on this fork and confirmed a new but similar vulnerability that can only be exploited by a trusted party". 

Is it possible to have more informations about this vulnerabilty ? In this case, what's a trusted party ? 


Like Ruben Nuredini likes this

@julien roynette 

There are indeed 3 vectors. the ldap query that you currently can spot everywhere in the wild. The two others seem to be DNS and RMI. More info here:


As for elasticsearch 6.8.6, i can confirm they are vulnerable to the attack, but it can be mitigated by simply adding a "-Dlog4j2.formatMsgNoLookups=true" flag to its java env until a better solution is provided.


Kind regards


Jonas Andersson

Like # people like this

Hi Does this also cover trello?

@Jodie Vlassis the updated advisory does not explicitly state whether log4j2-stacktrace-origins-2.2-atlassian-2.jar is covered by the vulnerability or not. Can we please get an explicit statement for this module?

Like # people like this

If the cloud products not vulnerable how do they explain these jndi ldap emails that someone sent from our JIRA cloud admin page to our entire company.

That the email headers say originated from Atlassian themselves (dmarc pass, spf pass, etc) apparently from our company jira portal instance that is hosted.  I reported this in a ticket nearly a day ago they didn't respond.


My organization is mandating a minimum version of log4j, currently 2.17.1.  Even if the log4j vulnerability is handled in the Atlassian-forked 1.2.17 version, it is still 1.2.17 -- the official 1.2.17 is very old and out of support and has other concerns, so this continues to be identified as a problem.  Are there any plans to update versioning for this Atlassian-forked variant?

Like # people like this

Representing the "gov" agencies, the mandate from DHS security is to upgrade all software's that has bundled log4j with older versions needs to be updated . The vulnerability tool is flagging any log4j not in v2.x.  

What would be the recommendation by Atlassian to upgrade the log4j 1.2.17 bundled within Jira 8.x package? 

Like Michael Kingsbury likes this

Similar question from our side. We run big Jira/Confluence/Bitbucket/Crowd instances and got a security advisory related to this CVE: 

Unfortunately we have only one week to implement a solution to this issue, as the CVE is rated with 10. Can you give us any information, if and when you plan to switch to the actual version of log4j? Is there a workaround, we can implement in the meantime? We run on actual LTS Server/Data Center licenses. 

We are using the Jira and Confluence Data Center Edition. Can Atlassian confirm if the log4j issue has been fixed in any new release yet? And if not, is it planned in coming releases?

We are using Atlassian-renderer 9.0.2 (Maven Repository: com.atlassian.renderer » atlassian-renderer » 9.0.2 (, which is inbuilt have dependency on log4j 1.x version which is vulnerable. 

If i upgrade the dependency externally to 2.x version, then the default methods inside atlassian-renderer does not work, gives class not found exception. (Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/log4j/Logger).

is there a workaround/solution present for this issue, please help.


Log in or Sign up to comment

Atlassian Community Events