In response to CVE-2021-44228, Atlassian has been diligently investigating the risk posed to our customers and partners. At this time, we can confirm that Atlassian’s Connect for Spring Boot (ACSB) is not vulnerable to this vulnerability. As a refresher, ACSB is one of Atlassian’s frameworks that handles tasks like JWT authentication and signing, persistence of host details, etc. We linked our public repository here.
Other services made available to partners to develop apps, such as Forge and Atlassian Connect for Node.js Express, are also not vulnerable.
We are continuing to monitor the situation for our apps, and we will provide updates as soon as we have them. In the meantime, Atlassian strongly recommends that all partners review each of their apps, specifically to confirm that you’re using the latest org.apache.logging.log4j:log4j-core to version 2.15.0 or higher. To check your repositories, you may choose to use Snyk’s public and free scanning tool, which we’ve linked here: Snyk | Developer security | Develop fast. Stay secure.
Out of curiosity: you seem to only discuss the impact of CVE-2021-44228 on the Atlassian Marketplace Partner infrastructure, mostly the apps and what we as partner can do.
Obviously, many of us are also wondering whether Atlassian host products (Jira, Confluence, etc) are vulnerable, and if such, which versions. We might be getting requests from customers (esp. the solution partners) and it would be great if we can point them to official Atlassian communications regarding the impact of this vulnerability.
I know of several divisions within my company that have their own deployment of Jira and Confluence (Data Center edition), and there are questions being raised about the impact of CVE-2021-44228.
Atlassian - would you kindly clarify if this vulnerability impacts any on-premise Atlassian products, and if so, which versions are affected and what can be done to mitigate the impact from this exploit?
is log4j:jar:1.2.17-atlassian-3 affected on the server / DC platform? I notice this package is included as a provided build dependency in com.atlassian.jira:jira-api:jar:8.20.0 .
According to Log4j – Apache Log4j Security Vulnerabilities, the affected log4j-core versions are >=2.0-beta9 and <=2.14.1 . So at first glance this package it is not affected, unless if introduced via the customization done for log4j:jar:1.2.17-atlassian-3?
Hi, everyone. We recently published an advisory that should answer ongoing questions about this vulnerability’s impact on our products. You can read it here.
As part of this advisory, we also included impact on apps. Importantly, we have started to notify apps vulnerable to CVE-2021-44228 via AMS. Given the severity of this situation, each vulnerable app must address the issue within 72 hours of being discovered. To ensure customer data is protected from this incident, Atlassian will pause cloud apps that do not address the issue, and inform customers who have vulnerable apps installed.
We encourage 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. You can contact Ecosystem Security via DEVHELP to coordinate.
In the official communication you mention that on on-premise, log4j version 1.2.17 is safe. We are currently using Atlassian’s provided version 1.2.16 in our on-premise apps. Can you confirm me that this fork is also not vulnerable to CVE-2021-44228?
@JakeComito If Atlassian scans an app and the result is “not vulnerable”, then the app vendor will not be notified, correct?
In other words, if the vendor doesn’t hear from Atlassian, then it is either because its app wasn’t scanned or it was scanned, but the vulnerability was not found in it?
(By the questions, I wanted to suggest that maybe Atlassian should notify the app vendor even if “we scanned your app and it looks OK”.)
Yes , 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
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.