Atlassian Marketplace Apps
On this page you will find information about Marketplace Apps for which an assessment of vulnerability CVE-2021-44228 has been published and our support team was able to retrieve from public sources or the vendor.
The information may be outdated or incomplete, so please always check the original source for the most up-to-date information.
Atlassian is also scanning and reviewing Data Center and Server apps. Atlassian has yet to discover apps developed by Atlassian that are vulnerable to CVE-2021-44228, however they have identified third-party apps that are vulnerable.
Each vulnerable Data Center or Server app will be given an expedited deadline. Data Center and Server apps that fail to address the vulnerability within this expedited time frame will be removed from the marketplace, then Atlassian will inform all customers who have vulnerable apps installed.
Vendor link to | Note and/or vendor comment | Source |
|---|---|---|
| https://help.k15t.com/k15t-apps-and-log4shell-cve-2021-44228-193401141.html | |
Adaptavist's apps on the Atlassian Marketplace are not directly impacted by this issue and there are no actions needed to address the vulnerability. | https://www.adaptavist.com/blog/the-log4shell-vulnerability-heres-what-you-need-to-do-next | |
Midori Apps are not affected | https://midori-global.com/blog/2021/12/15/cve-2021-44228-log4shell-midori-apps-are-not-affected? | |
Service Rocket Apps are not affected | https://docs.servicerocket.com/support/knowledge-base/knowledge-base-for-cve-2021-44228 | |
| ||
Innovalog apps are not impacted by the Log4J vulnerability | https://innovalog.atlassian.net/servicedesk/customer/portal/8 | |
See comment #4 Can confirm that it has no impact on eazyBI | https://community.eazybi.com/t/statement-regarding-log4j-vulnerability-cve-2021-44228/8449/4 | |
META-INF can confirm that for our apps Email this issue, Content Exporter anf ACDC are not affected. Email this issue uses the previous version of Log4j where this vulnerability is not present and the two other apps does not use Log4j. Our Glass app uses the Log4j v2 in question, but not the aspect that is being exploited. Bug Watcher does not use Log4j, it is not affected in any way by the recent vulnerabilities. | https://metainf.atlassian.net/wiki/spaces/PLUG/pages/563085316/Security+Advisories customer support via ticket SD-16608 | |
Our add-on does not use Log4j directly we have no dependency to it. In short, If your Jira is NOT vulnerable, our add-on is also NOT vulnerable. | ||
The Read Confirmations / Plant UML for Confluence app not affected by the Log4Shell vulnerability. | https://avono-support.atlassian.net/wiki/spaces/RECO/pages/2231271431/Security+Advisories https://avono-support.atlassian.net/wiki/spaces/PUML/pages/2230976513/Security+Advisories | |
Stiltsoft Cloud customers are not affected, and no action is required. Stiltsoft Cloud apps are not vulnerable. We use the logback.qos.ch framework in all our Cloud apps based on JVM. | https://docs.stiltsoft.com/pages/viewpage.action?pageId=83100302 | |
Log4j remote code execution vulnerability (CVE-2021-44228)Based on our internal and the research done on Atlassian's side, our current position regarding the recent CVE in the Log4J JSM Appender is that our xApps are NOT affected on any platform. So there is no current need to take any actions to ensure security when using our xApps. | ||
Digital Rose has reviewed and confirmed that the eSign App is not vulnerable to the Log4J security issue (CVE-2021-44228). The implicated log4J library is not included in any client side or server side components. | https://digitalrose.atlassian.net/wiki/spaces/ESIGN/pages/28672001/eSign+Recent+News+and+Updates | |
We want to assure our customers that the recently discovered Apache Log4j vulnerability does not directly impact the Structure product family. | https://almworks.com/blog/apache-log4j-vulnerability-no-impact-on-structure-product-family.html | |
We don’t see any impact on any of our products.
| https://marketplace.atlassian.com/vendors/5137/snapbytes-limited-an-appfire-company | |
Gliffy is not affected by the Log4j vulnerability. Learn how Perforce is addressing the issue across other brands. | ||
Our Elements On Premise apps are using Log4J library provided by Atlassian who confirmed in this FAQ for CVE-2021-44228 that their library is not vulnerable. This vulnerabilities were mitigated for all Elements Cloud apps previously using the vulnerable version of Log4j. | https://doc.elements-apps.com/security-announcement-for-log4j-vulnerabilities | |
We'd like to assure our customers that JSU app is not impacted by the Log4J vulnerability (CVE-2021-44228). Please refer to the Atlassian Support Documentation - FAQ for CVE-2021-44228 for latest details. | https://beecom-products.atlassian.net/servicedesk/customer/portals you must login to see the announcement | |
Our plugin(s) do not bundle any vulnerable versions of the log4j libraries and as such are not affected by the CVE. | ||
Bobswift (Appfire) | We'd like to assure you that most Bob Swift apps are not impacted by the Log4J vulnerability (CVE-2021-44228). In specific We would like to inform you that none of the mentioned Bobswift apps are impacted by the mentioned log4shell vulnerability, and you can continue using the apps.
| customer support via ticket-8902 |
We have so far processed the following apps and can confirm that they are not affected by the vulnerability. | https://communardo.atlassian.net/wiki/spaces/KB/pages/1874493441/Log4J+Vulnerability+CVE-2021-44228 | |
Seibert Media apps from Atlassian's Marketplace including all joint venture apps. Data Center and Server Apps
Cloud Apps
| https://info.seibert-media.net/pages/viewpage.action?pageId=78938959 | |
When using Refined, the Refined apps in turn are using log4j via the bundled version included in Jira/Confluence. This means that Refined cannot impact what is being used as Refined accesses it via Atlassian. | https://support.refined.com/space/FAQ/4397858848/FAQ for CVE-2021-44228%2C log4j | |
We would like to inform you that the app SIL Engine for Power Suite, SIL Excel Reporting, SIL Groovy Connector, SIL TableGrid Next Generation Connector, SIL Tempo Connector is not impacted by the mentioned log4shell vulnerability, and you can continue using the app. | customer support via ticket CADS-10591 | |
We assessed all of our apps in the Atlassian Marketplace and none of our Server, Data Center or Cloud apps are affected by CVE-2021-44228. | https://livelyapps.com/blog/2021/12/log4shell-cve-2021-44228/ | |
…that our apps are not impacted by this issue. Our Cloud apps do not use Log4J, and our Server/Data Center apps use a version of Log4J that is not affected by the vulnerability. | customer support via ticket SUPPORT-12848 | |
After a careful review by our experienced IT security experts, we can give you a definite all-clear at this point. We are sure that Log4Shell does not impact our products at all. | Actonic via Newsletter (16 DEC 2021) | |
We have verified that we do not bundle the Log4j library in our Jira/Confluence apps. We are using the Log4j library that is provided by Jira/Confluence. Hence we are safe. | https://www.akeles.com/is-my-jira-apps-affected-by-log4j-cve-2021-44228/ | |
We have received many support requests asking us if our #Jira Apps were impacted by the log4j vulnerability. The answer is NO ☺️ If you are using @Atlassian products, check the security advisory (link in comment). | via Twitter https://twitter.com/ApwideApps/status/1471750308179202051 | |
The results of our investigation is that Exalate is NOT affected by this vulnerability as Exalate is using ch.qos.logback on all Exalate products (except for Exalate for Jira On Premise) There might be a risk for 'Exalate for Jira On Premise', which is using the logging framework provided by Jira. | ||
None of our Server or Data Center apps have their own logger. They all use the default Jira/Confluence logger. Any changes you make to Jira/Confluence, regarding this vulnerability, will automatically be applied to our apps. | ||
All Utoolity Server apps use the SLF4J facade as provided by the respective Atlassian host product via OSGi and do not introduce Log4j on their own. They would thus only be indirectly affected if the Atlassian host product uses a vulnerable version of Log4j – this does not seem to be the case by default, see the Atlassian FAQ for CVE-2021-44228 for details. All Utoolity Cloud apps do not use Log4j and are thus not affected. | ||
We completed an assessment of our Data Center and Server apps. We do not bundle log4j and so our apps are not impacted by CVE-2021-44228. We rely entirely on the logging facility provided by Atlassian Jira which they have indicated is not subject to CVE-2021-44228. Our cloud services are not written in Java and so are not impacted by CVE-2021-44228. | customer support via ticket RS-15530 | |
We confirm that none of our apps (Pivot Charts, Plan Chart2D and Excel Importer) in all available deployment option (Server, Datacenter, Cloud) are not affected by log4j vulnerability issue (CVE-2021-44228). Log4j packages are not being included in our app. | ||
Our server/dc apps were not affected and cloud apps were patched immediately the vulnerability got published. | ||
We'd like to assure our customers that patches have been made for the Mohami apps impacted by the Log4J vulnerability (CVE-2021-44228).  | https://mohamicorp.atlassian.net/servicedesk/customer/portals | |
We do not bundle a version of Log4j in any of our apps. Our apps use the one provided by the respective Atlassian application. Therefore, our apps are not affected by CVE-2021-44228. | customer support via ticket SUPPORT-369 | |
We have looked into the issue outlined by the "CVE-2021-44228" zero-day vulnerability. Specifically the Log4j library in question, and we have concluded that it poses no danger to any of our products. While we do use the library, the vulnerability is only present in 2.x.x versions. All our products, including the SAML SSO for Jira add-on, use the fork of 1.x.x versions of the library which is not vulnerable to CVE-2021-44228. | customer support via ticket MOHELP-2675 | |
we've already scanned all our apps to verify if they can be affected by the vulnerability found in Log4J … we use loggers covered by Log4j, nevertheless, it is Jira provided. As mentioned in their official announcement (here), Jira is not impacted, therefore, I’d like to confirm that the app itself is vulnerability-free. In other words, the version we use depends on what version of Jira you are working on, but Atlassian has issued a statement that their versions are also not vulnerable, and therefore our applications are not. | customer support via ticket SUPPORT-53608 | |
| https://support.tmatesoft.com/t/svnmirror-plugin/2737/2 https://support.tmatesoft.com/t/is-subgit-affected-by-log4j-exploit-cve-2021-44228/2740/2 | |
We'd like to assure our customers that no Bolo Software apps have been impacted by the Log4J vulnerability (CVE-2021-44228).  | https://bolosoftware.atlassian.net/servicedesk/customer/portal/2 | |
None of our listed marketplace apps are vulnerable in regards to CVE-2021-44228. The apps make use of the underlying logging infrastructure of the Atlassian host products. None of our cloud apps are vulnerable in regards to CVE-2021-44228.  | https://avisi-support.atlassian.net/servicedesk/customer/portal/6 | |
We'd like to assure our customers that no Artemis apps have been impacted by the Log4J vulnerability (CVE-2021-44228).  | ||
Agile Cards, it’s not affected by the security vulnerability of Apache Log4j2. | customer support via ticket SUP-15153 | |
We concluded that these OBSS products are NOT exposed to Log4Shell vulnerability. You are not required to take any action specific to these products.
Affected Products The products listed below are thought to be exposed to this vulnerability.
If you are using at least one of these products, please follow the instructions in the following page: Security Advisory for Log4Shell vulnerability in OBSS apps on Jira Server and Jira Data Center | https://dev.obss.com.tr/jira/servicedesk/customer/kb/view/338460747 | |
WBS Gantt-Chart for Jira Cloud is not affected by CVE-2021-44228. WBS Gantt-Chart for Jira Server/Data Center is not dependent on Log4J version 2.x and is therefore not affected by CVE-2021-44228. | https://ricksoft-support.atlassian.net/servicedesk/customer/portal/3/article/4070801425 | |
We are not using log4j so our apps including Space Hierarchy is not impacted by log4shell issue. | vendor support answer | |
All Xray/Xporter Server/DC and Cloud products and Xray Exploratory Testing (XEA) - Our investigation confirmed there are no exposed instances of the Apache Log4j library within the version range that contains this vulnerability. Therefore, the investigation confidently concludes all product versions are not impacted by the Apache Log4j vulnerability. | https://docs.getxray.app/display/ProductKB/Security+Bulletin+Update+-+Log4J | |
All apps are safe. Check source for detailed report. | ||
JEditor is not affected by this vulnerability. JEditor uses Jira's logging facade which in turn uses Atlassian's fork of Log4j v1.2.x which is not vulnerable to CVE-2021-44228. | ||
Rixter do not bundle a version of Log4j and use for their applications the one provided by the respective Atlassian application. Therefore Rixter are not affected by CVE-2021-44228 | customer support via ticket RIX-48 | |
Please update the Capture for Jira plugin to the latest version we have fixed the same issue on the latest version. https://marketplace.atlassian.com/apps/306183/capture-for-jira?hosting=datacenter&tab=versions | customer support via ticket 00504447 | |
We analyzed all of our apps that used log4j (Via the following linkhttps://confluence.atlassian.com/kb/faq-for-cve-2021-44228-1103069406.html ) and the results are:
As a result, we can deduce that this vulnerability has no effect on our add-ons | customer support via ticket VS-915 | |
Our stack is java-free so there is no room for this issue to surface in our apps. | vendor customer support via email Thu Jan 20 2022 | |
All our Jira/Confluence apps including SuggestiMate rely on the log4j library supplied by the Jira/Confluence instance, so using them doesn't increase your clients' exposure to CVE-2021-44228. | vendor customer support via email Thu Jan 13 2022 | |
We reassure that we used the library SLF4J version 1.6.6 which is the API of the log4j and it’s safe with respect to CVE-2021-44228 because the vulnerability exists from 2. x onwards. | customer support via ticket SAS-184 | |
Our apps are not directly impacted by this issue. Our Server and Data Center products use the logging libraries provided by the host application and do not provide their own logging libraries. For more information on this subject please consult the following link https://kostebekteknoloji.atlassian.net/l/c/GJcXTEtj | customer support via ticket KSP-154 | |
We are using the provided Log4j version that is shipped with the Atlassian host product in all our Server/DC products, and as such are only vulnerable to the CVEs to the extend that the Atlassian host product is vulnerable, and any mitigations applied to the host product will also mitigate our exposure. | customer support via ticket CS-662 | |
Our apps are not affected by log4shell. | customer support via ticket CS-23 | |
Bulk Clone app is not affected since we base it on an earlier version 1.2 | customer support via email Thu Jan 13 2022 |
updated , information can be outdated or incomplete * please always check original source