At Adaptavist we always want to provide our customers with the best and most secure app experiences. While no software company can ever be 100% secure, it is important for us to react to the latest security findings, check our apps, and advise our customers.
CVEs everywhere!
Over the last few years, we have seen increasing numbers of serious vulnerabilities impacting software companies worldwide.
Log4Shell
An example of a serious CVE is this critical vulnerability. Log4Shell has a CVSSv3 score of 10 out of 10 in the popular Log4j2 logging library used by many Java (and other languages that use the Java Virtual Machine) applications. The vulnerability allows Remote Code Execution (RCE) and information leakage from servers that use vulnerable versions of Log4j.
Adaptavist's apps were not directly impacted by this issue, but as with any security issue, customers were advised to upgrade as soon as possible.
Recent CVEs
On 20 July 2022, two CVEs (CVE-2022-26136 and CVE-2022-26137) were found to be impacting Atlassian Products and potentially some vendor apps.
These two CVEs impact Java code and therefore Server + DC instances of Atlassian Products and any Atlassian Marketplace apps installed on them.
As a trusted app vendor, we have carried out appropriate investigations into our apps, with the main purpose of seeing if any of our code used Java Servlet Filters (which were vulnerable) in any security mechanisms.
Overall we found our apps have No to Low Risk, as below:
- Our ScriptRunner for Jira/Bitbucket/Confluence/Bamboo apps do use Servlet Filters, but not associated with security mechanisms - No Risk
- Our Forms for Confluence app does not use Servlet filters - No Risk
- Our ThemeBuilder app does use Servlet Filters but not associated with security mechanisms - No Risk
- Our Community Forums for Confluence app does use Servlet Filters with some functionality around Locked pages - Low Risk
undefined - Our Content Formatting Macros app does use Servlet Filters, but not in any relevant security mechanisms. Filters are used to push some data to a legacy analytics platform which will soon be removed - Low Risk
- Our Ratings app does use Servlet Filters, but not in any relevant security mechanisms. Filters are used to push some data to a legacy analytics platform which will soon be removed - Low Risk
- Our Attachment Download app does use Servlet Filters, but not in any relevant security mechanisms. Filters are used to push some data to a legacy analytics platform which will soon be removed - Low Risk
Patch / upgrade vs long investigations?
Can we patch our apps anyway to eliminate any risk?
As the suggested fix is to upgrade Atlassian instances and nothing directly related to Java or App development, the best course of action is the former.
As an app vendor, what else could we do?
We could go through our apps and remove any use of Servlet filters, but this would be a high-risk and time-consuming activity resulting in (at least) several days of work, follow-up testing, and security checks to ensure the vulnerability had been mitigated. This would leave the vulnerability in place and potentially lead to a loss of functionality.
What is the best course of action?
As with most security issues, it is often better to patch / upgrade as quickly as possible, rather than conduct lengthy investigations and attempts to re-create the vulnerability. Providing you have carried out appropriate checks and impact analysis of any upgrade, this is almost always the most efficient way of solving the security issues and reducing the security risk.
We hope this explains how we look into CVEs at Adaptavist–such as the two announced this week–and how we take a common sense approach to the issues raised. This once again shows how critical it is to keep your Atlassian instances up to date.
If you need any further help with vulnerabilities, please visit our support portal.
