This page contains our advice and analysis of CVE-2021-44228. Note that it will we updated regularly as we learn new details about the vulnerability. In most cases, we refer to Atlassian’s documents about Log4j: (https://confluence.atlassian.com/security/multiple-products-security-advisory-log4j-vulnerable-to-remote-code-execution-cve-2021-44228-1103069934.html || https://confluence.atlassian.com/kb/faq-for-cve-2021-44228-1103069406.htmlMultiple Products Security Advisory - Log4j Vulnerable To Remote Code Execution - CVE-2021-44228 || FAQ for CVE-2021-44228, CVE-2021-45046 and CVE-2021-45105). If Kantega SSO is vulnerable logging through Slf4j, then likely your entire system is prone.
...
The answer is no, not by default. We have looked into our dependencies, and found out that Kantega SSO Enterprise is not affected since Atlassian on-prem runtime systems by default run older versions of Log4j out of scope for the vulnerability in question. Log4j is provided as a transitive dependency to Kantega SSO by the host system and used in a few cases in Kantega SSO Enterprise versions <= 5.1.1 and <=4.14.7. From versions 5.1.2 and 4.14.8, all logging is run through Slf4j.
Certain non-default Data Center / Server Atlassian host configurations may be affected by the vulnerability. You can read more about the incident for Atlassian systems in general in Atlassian’s FAQ: https://confluence.atlassian.com/kb/faq-for-cve-2021-44228-1103069406.html. Update: Bitbucket Server and Data Center instances may be prone to CVE-2021-44228 (information leakage, not RCE) through Elasticsearch. Please read Atlassian’s security advisory for more details.
Update 15.12.2021: Consolidation of log facade in versions 5.1.2 and 4.14.8
...