...
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 2021-12-21: 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
...
2021-12-15: Consolidation of log facade in versions 5.1.2 and 4.14.8
Even though we are not directly vulnerable to Log4Shell, we were running the provided Atlassian-managed fork of Log4j 1.2.17 directly in a few classes instead of the Slf4j facade framework which is most commonly used in the app. The Atlassian-managed version log4j:jar:1.2.17-atlassian-3 is also said to be safe to another vulnerability CVE - CVE-2019-17571 8, as it does not have SocketServer class that is a problem in that old version.
In the patch releases of Kantega SSO Enterprise 5.1.2 (latest), and 4.14.8 (stable backport), we have consolidated our logging to be through the logging facade Slf4j only. This makes transitions to other framworks like Logback (which is run i Bitbucket) easier.
Any weakness in K-SSO logging will now be inherited through Slf4j due to a weakness in your entire Atlassian installation, and will have to be addressed on a system level.
...