Update - As per update by Atlassian some Bitbucket versions can be vulnerable through the bundled Elasticsearch component, please review: https://confluence.atlassian.com/security/multiple-products-security-advisory-log4j-vulnerable-to-remote-code-execution-cve-2021-44228-1103069934.html

A mitigation has been published by Atlassian – please apply to your installations if you feel they are affected.

The mitigation has been applied to our systems.

More information was published about CVE-2021-45046 as well – and you can expect updates in the base Atlassian products:
"A related, but much less severe, vulnerability was discovered in non-default configurations of Log4j 2.0-beta9 to 2.15.0 (inclusive), see CVE-2021-45046 (scored CVSS v3 3.7 low): https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046

Regardless of whether the vulnerable configuration is in use, Atlassian will be addressing CVE-2021-45046 by upgrading to log4j 2.16.0 (or greater) in line with the timeframes detailed in the Atlassian Security Bugfix Policy."
Dec 17, 11:16 NZDT

Update - We have been made aware of a 0-day security vulnerability affecting log4j library: https://www.lunasec.io/docs/blog/log4j-zero-day/

Summary:

Based on the information made available by Atlassian, our own investigations, and other sources available to us at this moment we conclude that:

- all TechTime apps on Cloud, Server, and Data Center are NOT affected by these vulnerabilities;
- our supporting and development systems are NOT affected by these vulnerabilities;
- our production Cloud hosting systems are NOT affected by these vulnerabilities;
- any Atlassian systems where logging configuration hasn't been modified from its default settings to relay log messages to the external sources via JMS are NOT affected by these vulnerabilities.

Please review (the language gets progressively more specific):
https://confluence.atlassian.com/kb/faq-for-cve-2021-44228-1103069406.html
Dec 15, 13:34 NZDT

Update - CVE-2019-17571

In our investigation of the version of org.apache.log4j being used within Atlassian products (v1.2.17), we also found a reference to an older vulnerability CVE-2019-17571, referenced here: https://www.lunasec.io/docs/blog/log4j-zero-day-mitigation-guide/#log4j-v1

https://www.cvedetails.com/cve/CVE-2019-17571/

"Included in Log4j 1.2 is a SocketServer class that is vulnerable to deserialization of untrusted data which can be exploited to remotely execute arbitrary code when combined with a deserialization gadget when listening to untrusted network traffic for log data. This affects Log4j versions up to 1.2 up to 1.2.17."

Internal investigations have found that the vulnerable classes have been removed from the packages included in Atlassian products.

As per notice on the FAQ for CVE-2021-44228, Atlassian products are using a fork of log4j 1.2.17 maintained by Atlassian themselves.

We have found the following reference about work done to mitigate this in Fisheye: https://jira.atlassian.com/browse/FE-7344

We have requested clarification from Atlassian and it has been confirmed that the affected classes have indeed been removed by Atlassian as part of the preparing their forked version of the package.
Dec 14, 11:15 NZDT

Monitoring - CVE-2021-44228
https://www.cvedetails.com/cve/CVE-2021-44228/

This vulnerability is related to version of log4j from v2 to v2.14.1 (inclusive).

As per advice from Atlassian their products are not affected in their default configuration, see: https://confluence.atlassian.com/kb/faq-for-cve-2021-44228-1103069406.html
Dec 13, 15:15 NZDT

Update - We do not include any log4j dependencies into our packages.

All TechTime products on Cloud, Server, and Data Center are using log4j library versions that are provided by the underlying Atlassian products, e.g., Jira, Confluence, Bitbucket, Bamboo, and Fisheye/Crucible.
Dec 10, 17:00 NZDT

Investigating - We have been made aware of a 0-day security vulnerability affecting log4j library: https://www.lunasec.io/docs/blog/log4j-zero-day/
Dec 10, 16:45 NZDT